+- HP Forums (https://www.hpmuseum.org/forum)
+-- Forum: HP Calculators (and very old HP Computers) (/forum-3.html)
+--- Forum: HP Prime (/forum-5.html)
+--- Thread: PROBLEM WITH PI π (/thread-21060.html)
PROBLEM WITH PI π - yagomestre64 - 12-26-2023 07:14 PM
Hi, i've bought a HP prime calculator and im having some problems with it, when i make sen(π) in CAS mode, it works correctly and gives me 0 as an answer, but when i compute it out of CAS mode, it returns to me -2E-13, a pretty small number, close to 0 but no 0, the problem is that , out of CAS mode, the calculator makes an approximation of π to the 11th decimal digit, so the value of the sin(π) is not exactly 0, how couls i fix this? thanks in advance
RE: PROBLEM WITH PI π - Wes Loewer - 12-28-2023 09:54 AM
Short Answer:
If your firmware version is not too old (2020-05-11 or later), go to the Home Settings and turn on Intelligent Math. With the latest firmware (2023-04-13) the result you want is the default behavior even without Intelligent Math turned on.
Longer Answer:
The Prime is essentially two calculators in one. The CAS is a symbolic calculator which can perform exact calculations, while Home is a numeric calculator which gives decimal approximations. In CAS, sin(π)=0 because π is exactly π. In Home, however, π is approximated as 3.14159265359. Since sin(3.14159265359) = −2.06761537357ᴇ−13, this is the "correct" answer. (If you enter =sin(PI()) in a spreadsheet and you will also get a non-zero answer, although you might have to set the format to Scientific in order to see it.)
Calculator manufacturers have to choose between two philosophies. Do you tell the truth and give the actual calculated value? Or do you lie and give people what they expect? Traditionally, HP calculators have given the actual calculated value while TI and Casio calculators have given people what they expect. On the TI and Casio numeric calculators, π is approximated as 3.1415926535898. The actual value of sin(3.1415926535898) is -6.98ᴇ-15, but these calculators typically give 0.
Computer scientist and engineers who concern themselves with numerical methods and error analysis would typically prefer to see the actual calculated value while math students typically prefer the expected answer. As the latter group is now the target customer, it makes sense that hp branded calculators have made the switch to giving the "expected" value.
Basically, people prefer to be lied to. People can't handle the truth. :-)
RE: PROBLEM WITH PI π - Steve Simpkin - 12-28-2023 01:03 PM
"Basically, people prefer to be lied to. People can't handle the truth. :-)"
William Kahan had a bit to say about the apparent "increased accuracy" of TI models when he worked as a consultant for HP. His philosophy was also show the truth rather than a lie with a nice coat of paint.
https://www.hpmuseum.org/forum/thread-15234-post-178478.html#pid178478
RE: PROBLEM WITH PI π - bxparks - 12-29-2023 03:25 AM
The first time I used a TI graphing calculator was a few months ago, and I typed the following the TI-84+SE:
Code:
1 / 3 ENTER # shows .3333333333, 10 digits
* 3 ENTER # shows 1
- 1 ENTER # shows 0I was shocked, because getting a "0" is impossible for a finite precision calculator (using base-2 or base-10) so I thought the calculator was broken. The TI calculator, I learned later, uses a BCD floating point representation that holds 14 significant digits. It is apparently doing some internal rounding and error truncation that I don't fully understand, and it actually makes me slightly *less* trusting of the results shown on these calculators.
RE: PROBLEM WITH PI π - Steve Simpkin - 12-29-2023 05:04 AM
(12-29-2023 03:25 AM)bxparks Wrote: The first time I used a TI graphing calculator was a few months ago, and I typed the following the TI-84+SE:
Code:
1 / 3 ENTER # shows .3333333333, 10 digits
* 3 ENTER # shows 1
- 1 ENTER # shows 0
I was shocked, because getting a "0" is impossible for a finite precision calculator (using base-2 or base-10) so I thought the calculator was broken. The TI calculator, I learned later, uses a BCD floating point representation that holds 14 significant digits. It is apparently doing some internal rounding and error truncation that I don't fully understand, and it actually makes me slightly *less* trusting of the results shown on these calculators.
Don't think too hard about it. Everything will be fine. Buy that TI-84 the teacher told you to buy. TI is great! Obey!
Conform...Obey...Buy TI...
RE: PROBLEM WITH PI π - Albert Chan - 12-29-2023 02:39 PM
(12-29-2023 03:25 AM)bxparks Wrote: I was shocked, because getting a "0" is impossible for a finite precision calculator (using base-2 or base-10)
Base 2, 1/3*3 - 1 = 0
float(1/3) = 1/3 ± ULP(1/3)/3 // sign depends on parity of bits
float(1/3)*3 = 1 ± ULP(1/3) = 1 ± ULP(1)/4 --> rounded back to 1
lua> 1/3*3 - 1
0
Base 10, we get non-zero result.
float(1/3) = 1/3 - ULP(1/3)/3
float(1/3)*3 = 1 - ULP(1/3) = 1 - ULP(1)/10 --> rounded below 1
HP71-B
>1/3*3 - 1
-.000000000001 // = -1e-12 = -ULP(0.1)
TI is getting 0 because of its flush-to-zero "feature".
RE: PROBLEM WITH PI π - bxparks - 12-29-2023 03:19 PM
(12-29-2023 02:39 PM)Albert Chan Wrote: float(1/3)*3 = 1 ± ULP(1/3) = 1 ± ULP(1)/4 --> rounded back to 1
[...]
float(1/3)*3 = 1 - ULP(1/3) = 1 - ULP(1)/10 --> rounded below 1
Interesting. I'm not familiar with ULP analysis. I know that it stands for "unit in last place", but how does the second equality happen? The "ULP(1/3) = ULP(1)/4" and the "ULP(1/3) = ULP(1)/10".
My reasoning was that 1/3 = 0.0101_0101 (base-2, to 8 bits in this example). Multiply that by 11 (base-2) to get 0.1111_1111 (base-2). Subtract 1 to get -0.0000_0001 (base-2), which cannot equal 0.
(12-29-2023 02:39 PM)Albert Chan Wrote: TI is getting 0 because of its flush-to-zero "feature".
That's a good explanation for what's happening, thank you.
RE: PROBLEM WITH PI π - Albert Chan - 12-29-2023 04:05 PM
(12-29-2023 03:19 PM)bxparks Wrote: how does the second equality happen? The "ULP(1/3) = ULP(1)/4" and the "ULP(1/3) = ULP(1)/10".
Base 2, IEEE double as example:
hexfloat(1/3) = 0x1.5555555555555p-2
hexfloat(1/4) = 0x1.0000000000000p-2 // exponents matched → same sized ULP
ULP(1/3) = ULP(1/4) = ULP(1/2)/2 = ULP(1)/4
Base 10, 12-digits precision as example, in SCI format
float(1/3) = 3.33333333333E-1
float(1/10) = 1.00000000000E-1 // exponents matched → same sized ULP
ULP(1/3) = ULP(1/10) = ULP(1)/10
In general, for base b, integer n: ULP(1/b^n) = ULP(1)/b^n
RE: PROBLEM WITH PI π - Albert Chan - 12-29-2023 04:56 PM
(12-29-2023 03:19 PM)bxparks Wrote: My reasoning was that 1/3 = 0.0101_0101 (base-2, to 8 bits in this example). Multiply that by 11 (base-2) to get 0.1111_1111 (base-2). Subtract 1 to get -0.0000_0001 (base-2), which cannot equal 0.
No, intermediate calculation crossed 2^n boundary, size of ULP changed.
0.01010101 // 1/3, 7 bits precision
0.11111111 // 1/3*3
1.000000 // 7 bits precision (half-way rounded-to-even)
0.0101011 // 1/3, 6 bits precision
1.0000001 // 1/3*3
1.00000 // 6 bits precision (rounded-down)
This matched previous analysis
(12-29-2023 02:39 PM)Albert Chan Wrote: Base 2, 1/3*3 - 1 = 0
float(1/3) = 1/3 ± ULP(1/3)/3 // sign depends on parity of bits
float(1/3)*3 = 1 ± ULP(1/3) = 1 ± ULP(1)/4 --> rounded back to 1