PROBLEM WITH PI π

[yagomestre64]

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

[Wes Loewer]

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. :-)

[Steve Simpkin]

"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-15...#pid178478

[bxparks]

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.

[Steve Simpkin]

(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...

[Albert Chan]

(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".

[bxparks]

(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.

[Albert Chan]

(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

[Albert Chan]

(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