Nedcim Posted October 15, 2019 Posted October 15, 2019 I found that my hand held calculator makes a computation error. I entered the expression (4sin80°)/sin40° and my calculator returned a value of ~ 5.13. I had previously entered the expression (4sin60°)/sin40° and my calculator returned a value of ~ 5.39 so I knew there was an error. I found the expression in error. I wanted to find where this error originated. I tried several iterations but still got the the same value. I approximated the the value of the numerator and denominator and that gave a correct approximation. I continued 3.93/0.640 gave a correct approximation of 6.13, but 3.93/0.641 returned a value of ~ 5.13 with same error as above. I never had a calculator make a computational error. I'm curious if anyone has experienced this issue and if this is a way to possibly correct it?
Endy0816 Posted October 15, 2019 Posted October 15, 2019 (edited) Probably due to the fact that the calculator has limited memory to handle an infinitely long repeating decimal with as long a period as 3.93/0.64 has. More memory would help in this case for a more accurate answer, but all calculators have a point where they reach the limits of available memory. Pi is another case where you logically know the number should keep going, but instead it stops and/or is rounded. 3.93/0.641= 6.131045241809672386895475819032761310452418096723868954758... https://www.wolframalpha.com/input/?i=3.93%2F0.641 Edited October 16, 2019 by Endy0816
Nedcim Posted October 16, 2019 Author Posted October 16, 2019 It's not an issue with memory. When the thousandths digit of the denominator is changed from 0 to 1, to approach sin40° the answer changes from the correct approximation of 6.14 to 5.13.
swansont Posted October 16, 2019 Posted October 16, 2019 The display of a 5 vs. 6 on an 8-segment display is different by just one element. It is possible (though not certain) this is a display problem and not a computational error. Though if it is consistently wrong, that points away from that being the issue. One would expect this to be intermittent if it were a display problem.
Endy0816 Posted October 16, 2019 Posted October 16, 2019 6 hours ago, Nedcim said: It's not an issue with memory. When the thousandths digit of the denominator is changed from 0 to 1, to approach sin40° the answer changes from the correct approximation of 6.14 to 5.13. Memory can also required as the calculator is trying to solve the problem, though Swansont's suggestion is a good one to check.
Sensei Posted October 17, 2019 Posted October 17, 2019 12 hours ago, swansont said: The display of a 5 vs. 6 on an 8-segment display is different by just one element. It is possible (though not certain) this is a display problem and not a computational error. Though if it is consistently wrong, that points away from that being the issue. One would expect this to be intermittent if it were a display problem. Yeah. Good idea. Simply check if number 8888888888(8) will have some parts missed.. LCD display problems are the most common way how calculators (and electronic multimeters in fact) are ending up their life being useless.
Nedcim Posted October 18, 2019 Author Posted October 18, 2019 On 10/16/2019 at 1:07 PM, swansont said: The display of a 5 vs. 6 on an 8-segment display is different by just one element. It is possible (though not certain) this is a display problem and not a computational error. Though if it is consistently wrong, that points away from that being the issue. One would expect this to be intermittent if it were a display problem. The calculator is consistently wrong with certain expressions. 5.75/0.555 has the same issue where the leading digit is off by one. Yet the issue is not present with 5.38/0.343, 75.3/0.235 Or 47.83/82.94.
Nedcim Posted October 18, 2019 Author Posted October 18, 2019 On 10/17/2019 at 1:58 AM, Sensei said: Yeah. Good idea. Simply check if number 8888888888(8) will have some parts missed.. LCD display problems are the most common way how calculators (and electronic multimeters in fact) are ending up their life being useless. That's the issue. The pixels are missing from a portion of the output with the leading digit when 10 digits are displayed. That explains the discrepancy of the error showing in one expression and not another. Thanks to all who gave input.
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now