Approximate pi to 24 digits via keyboard

[Rick314]

This works with several HP calculators I've tried it on, but not on other scientific calculators like a TI-83+ for example. In radians, for eps << 1, sin(pi - eps) = sin(pi)*cos(eps) - cos(pi)*sin(eps) = 0 - (-1)*sin(eps) = sin(eps) ~= eps. So:

sin(3.14159265358) * 1e12 = 9.79323846264, the next 12 digits of pi (3.14159265358979323846264...).

Notice this requires entering the first 12 *truncated* digits of pi (3.1415926535*8*) to be sure the value is slightly less than pi, not the 12-digit calculator *rounded approximation* to pi of 3.1415926535*9* that is actually a little larger than pi. This can be known without knowing the value of pi to begin with, because sin(<calculator approximation to pi>) is a small *negative* number. So the calculator approximation is larger than pi and the 12th truncated digit must be an 8, not a 9.

[PANAMATIK]

(01-30-2015 06:35 PM)Rick314 Wrote:  This works with several HP calculators I've tried it on, but not on other scientific calculators like a TI-83+ for example. In radians, for eps << 1, sin(pi - eps) = sin(pi)*cos(eps) - cos(pi)*sin(eps) = 0 - (-1)*sin(eps) = sin(eps) ~= eps. So:

sin(3.14159265358) * 1e12 = 9.79323846264, the next 12 digits of pi (3.14159265358979323846264...).

This does not work on any classic HP-35, HP-45 ... or woodstock calculators HP-21,HP-25,HP-27 ... with 56-bit BCD arithmetik.

Bernhard

[Rick314]

(01-30-2015 07:22 PM)PANAMATIK Wrote:  This does not work on any classic HP-35, HP-45 ... or woodstock calculators HP-21,HP-25,HP-27 ... with 56-bit BCD arithmetik.

Interesting, so I checked several HP calculators I have available. It works on the HP-22S, HP-28S, HP-32SII and HP-35S. It doesn't work on the HP-67 or HP-41CX.

[Gilles]

It works with the 48SX - 49 -50.

Don't work with the 15C LE

I noticed that the CASIO FX-602P and 603P returns exactly 0. for the SIN with the predefine PI constant. Both 602P and 603P have some curious rounding process (ex : sqrt(2) * sqrt (2) returns exactly 2)

[Dieter]

(01-30-2015 06:35 PM)Rick314 Wrote:  This works with several HP calculators I've tried it on, but not on other scientific calculators like a TI-83+ for example.

It works on calculators with a sufficient number of internal digits of pi. For instance, HP's classic 10-digit machines (at least since the mid-Seventies) only use 13 digits, so sin 3,141592653 will not return more than 5,90 E–10. Newer 12-digit calculators work differently – I do not know how many digits of pi are stored internally – and so you get 12 additional digits.

BTW, instead of the sine you can also use the tangent – just with a negative sign. Actually the number of digits roughly doubles with each step. Using the tangent finally is nothing but a Newton iteration for solving sin x = 0: the quotient of the function and its derivative is sin(x)/cos(x) = tan(x). ;-)

FWIW, the WP34s in double precision mode (34 digits) returns 17 additional correct digits (both with sin and tan). So I assume the internal representation of pi has about 50 digits – or the sine/tangent algorithms may have somewhat limited accuracy for border cases like these.

Dieter

[Dieter]

(01-30-2015 08:38 PM)Gilles Wrote:  It works with the 48SX - 49 -50.
Don't work with the 15C LE

Right, the 15C should return three additional digits, as mentioned in my other post. Since the third digit is zero, you'll see only two (5,9 E–10). ;-)

(01-30-2015 08:38 PM)Gilles Wrote:  I noticed that the CASIO FX-602P and 603P returns exactly 0. for the SIN with the predefine PI constant. Both 602P and 603P have some curious rounding process (ex : sqrt(2) * sqrt (2) returns exactly 2)

Sounds a bit like "don't confuse the student and return what he expects". #-)
Do the Casios also return a plain 2 if you calculate 1,414213562 * 1,414213562 manually, i.e. without using the sqrt-key?
Or a plain zero for sin 3,141592653 resp. ...54?

Dieter

[Gilles]

(01-31-2015 07:11 AM)Dieter Wrote:  Sounds a bit like "don't confuse the student and return what he expects". #-)
Do the Casios also return a plain 2 if you calculate 1,414213562 * 1,414213562 manually, i.e. without using the sqrt-key?

602/603P

1,414213562 x² -> 1.999999999 (-1.99999999= -> 8.94E-9)
1,414213562 + 3.7E-10 = x² ->2. (exactly - 2 -> 0)

After some test I think there is a rounding process with the 12th (no displayed) digit :

1.999999999 + 9.6E-10 -> is 2. (exactly because -2 = -> 0)
1.999999999 + 9E-10 -> display 2. (but -2 = -> -1E-10)

3,141592653 SIN -> 6E-10
3,141592653 + 6E-10 = SIN -> 0

PS : In fact, this is described in a user guide that I found online (but not in my old french user guide):

602/603P :


It looks curious but explains why sqrt(7)*sqrt(7) returns exactly 7 on my old Casio602P

[Dieter]

(01-31-2015 11:25 AM)Gilles Wrote:  After some test I think there is a rounding process with the 12th (no displayed) digit :
[ image ]
It looks curious but explains why sqrt(7)*sqrt(7) returns exactly 7 on my old Casio602P

Hmmm... calculate a result with 12 digits, and if this result matches an exact 10-digit result within +7/–8 ULP, simply return this rounded 10-digit result. Sounds like a typical example for cosmetic rounding. ;-)

Dieter

[Rick314]

(01-31-2015 07:06 AM)Dieter Wrote:  It works on calculators with a sufficient number of internal digits of pi... Newer 12-digit calculators work differently – I do not know how many digits of pi are stored internally – and so you get 12 additional digits.

Hi Dieter. I think what you said here is incorrect. The "newer 12-digit calculators" store the value of pi internally to 12 digits. The point of this post is that calculators vary in their sin(x) algorithm for values of x very close to pi. Just speaking pure math, not calculators or rounding errors or related, if x = 3.14159265358 (exactly) then sin(x) = 9.793238462643383...e-12.

Update: By the way, eventually the "9.793238462643383..." digits in the previous sentence will deviate from the digits of pi, because sin(pi - eps) only approximately equals eps. In this case eps is about 1 count in the 11th decimal place, or 1e-11. Since sin(x) for small x equals approximately x - x^3/3! the digits will start deviating around (1e-11)^3 or the 33rd decimal place. Sure enough, 1e11 * sin(3.14159265358) = 0.
979323846264338327950272... and pi = 3.14159265358
979323846264338327950288... with deviation at the 34th decimal place of pi.

[J-F Garnier]

This behavior is well known and has been discussed in the past, see for instance here.

And as an evidence of the double-precision pi value in Saturn machines, here is an extract of the HP-71B source code (the first Saturn machine, and the only one with public source files):



In the same Math routine module, there are double-precision arithmetic functions to do the argument reduction.

J-F

[Thomas Klemm]

(02-01-2015 08:41 AM)J-F Garnier Wrote:  the first Saturn machine, and the only one with public source files

Could you provide a link where we could access them?

Many thanks in advance
Thomas

[J-F Garnier]

(02-01-2015 11:07 AM)Thomas Klemm Wrote:  

(02-01-2015 08:41 AM)J-F Garnier Wrote:  the first Saturn machine, and the only one with public source files

Could you provide a link where we could access them?

The HP-71B IDS documents are available on the MoHPC DVD (or USB drive now).

[Dieter]

(02-01-2015 12:21 AM)Rick314 Wrote:  Hi Dieter. I think what you said here is incorrect. The "newer 12-digit calculators" store the value of pi internally to 12 digits.

Sorry if I was not clear about that. Of course these calculators return a 12-digit-value if you press the pi key, but I referred to the internal trig algorithms that contain a value for pi in much higher precision.

(02-01-2015 12:21 AM)Rick314 Wrote:  The point of this post is that calculators vary in their sin(x) algorithm for values of x very close to pi. Just speaking pure math, not calculators or rounding errors or related, if x = 3.14159265358 (exactly) then sin(x) = 9.793238462643383...e-12.

Right. And that's where the internal pi value (as used in the trig algorithms) comes in. While some algorithms use just 13 digits (most HP 10 digit machines) others may use a much higher precision value. Maybe someone knows the number of pi digits for different HP CPUs and algorithms. The assembler listing shown in this thread states 31 digits for pi/4.

Dieter

[Thomas Klemm]

Isn't the result given by the HP-41C or HP-15C more appropriate than returning 12 digits like the HP-48G? Since we can't enter more than 12 digits why should the calculator assume that next 12 digits are all 0? But that's exactly what happens:

Code:

  3.14159265358979323846264
- 3.14159265358000000000000

  0.00000000000979323846264

In the worst case the next 12 digits are all 9 thus we're very close to \(3.14159265359\) and end up with \(-2.06761537357 × 10^{-13}\) instead.

It's interesting that they did this but honestly I don't see an application where these additional digits are useful.

Cheers
Thomas

[Dieter]

(02-01-2015 04:27 PM)Thomas Klemm Wrote:  Isn't the result given by the HP-41C or HP-15C more appropriate than returning 12 digits like the HP-48G? Since we can't enter more than 12 digits why should the calculator assume that next 12 digits are all 0? But that's exactly what happens:

Yes, that's right. But in all other cases the calculator also assumes that the input is an exact 10 or 12 digit value. The only other option is returning an interval, i.e. the result for x–0,5 ULP and x+0,5 ULP.

Consider this:

Code:

1003          e^x   =>    3,95699361019 E+435

1003,00000001 e^x   =>    3,95699364976 E+435

1002,99999999 e^x   =>    3,95699357062 E+435

So should the calculator drop the last four digits and return 3,9569936 E+435 for e¹⁰⁰³ instead?

Dieter

[Rick314]

(02-01-2015 08:41 AM)J-F Garnier Wrote:  This behavior is well known and has been discussed in the past, see for instance here.

Thanks, and possibly they learned it from my post to Usenet group alt.math.recreational about 10 months earlier here. I don't know if I was the first person to discover it, but did come up with it on my own. I was just recently looking at another thread in this forum and thought to share it here. I would be interested in related postings before 10/27/03 that you can find.

I see now we mean the same thing by "internal value of pi" and "the sin(x) algorithm". The algorithm uses an extended precision approximation to pi. I think most important is that the firmware designers recognized the need of doing something special to provide a full calculator precision answer to sin(x) when x is close to pi. I think others just missed the whole issue.

Thanks to all those following up. Math is fun!

[Thomas Klemm]

(02-01-2015 05:34 PM)Dieter Wrote:  So should the calculator drop the last four digits and return 3,9569936 E+435 for e¹⁰⁰³ instead?

After all you should take the result with a grain of salt. The relative error is multiplied by 1003 thus the last 3-4 digits are indeed meaningless. But at least the first 8 digits are significant.

The difference I see between these two examples is that with \(\sin(x)\) for \(x\) close to \(\pi\) we experience cancellation.

Cheers
Thomas

[EdS2]

(01-31-2015 07:06 AM)Dieter Wrote:  It works on calculators with a sufficient number of internal digits of pi.

To be pedantic, it works on calculators with sufficiently accurate trig calculations - although probably all calculators do range reduction, and use some approximation to pi in doing so, in fact it's possible to calculate sin(x) without doing range reduction: in which case you need no information about the value of pi. Here are the first few partial sums for sin(3.1415):

Code:

3.1415
-2.0257555664
0.524032441414
-0.0751083819636
0.00701570299194
-0.000352337205218
0.000113786850196
9.18811898433e-05
9.26759966426e-05
9.26530610696e-05

[Rick314]

(02-01-2015 07:24 PM)Thomas Klemm Wrote:  

(02-01-2015 05:34 PM)Dieter Wrote:  So should the calculator drop the last four digits and return 3,9569936 E+435 for e¹⁰⁰³ instead?

After all you should take the result with a grain of salt. The relative error is multiplied by 1003 thus the last 3-4 digits are indeed meaningless. But at least the first 8 digits are significant.

Hello Thomas. I'm with Dieter here, and yes absolutely non-entered input digits should be considered to be 0. e^1003, e^(1003 + 1e-8) and e^(1003 - 1e-8) are distinct different recognizable inputs to a 12-digit calculator and each has a different unique 12-digit approximation to the exact correct answer. (I checked with extended-precision software and Dieter's 3 answers are indeed the best 12-digit answers possible. They are also what my HP-35S returns, so kudos to the HP-35S same as for its sin(x) algorithm.) I don't think there is any "relative error" on the 3 different inputs, and the 3 different answers are the correct 12-digit answers.

[Dieter]

(02-01-2015 09:17 PM)Rick314 Wrote:  Hello Thomas. I'm with Dieter here, and yes absolutely non-entered input digits should be considered to be 0. e^1003, e^(1003 + 1e-8) and e^(1003 - 1e-8) are distinct different recognizable inputs to a 12-digit calculator and each has a different unique 12-digit approximation to the exact correct answer.

Thank you, Rick. But in the end I think we will all come together with something we all can agree with. ;-) If I understand Thomas correctly, his point is that a 12-digit approximation for pi (e.g. 3,14159265358 or ...59) may be anything within this interval, but the sine of such a random argument can vary substantially. So taking all results magno cum grano salis is advised – as usual.

I chose this example with the exponential function because here the relative error can be estimated very easily: since e^x approximately equals 1+x if x is sufficiently small, the three values differ by a relative difference of quite exactly 1E–8. So the results agree in not more than 8 out of 12 digits. Now if you assume that "1003" is just an approximation of a random value within 0,5 ULP, i.e. something between 1002,999999995 and 1003,000000005, where e^x agrees only in its first 8 digits: how much sense is then in a 12-digit result?

So there are simply two different assumptions: either 3,14159265358 is considered exact, i.e. 3,1415926535800000000000000.... (that's what I prefer, and obviously you do as well), or one may think of it as "anything between 3,141592653575 and 3,141592653585" (which would mean that any returned value for the sine of this is meaningless).

(02-01-2015 09:17 PM)Rick314 Wrote:  (I checked with extended-precision software and Dieter's 3 answers are indeed the best 12-digit answers possible. They are also what my HP-35S returns, so kudos to the HP-35S same as for its sin(x) algorithm.) I don't think there is any "relative error" on the 3 different inputs, and the 3 different answers are the correct 12-digit answers.

Yes, the 35s does return these three results – actually that's the calculator I used for the calculation. But you should not be too generous with your kudos: take a look at these results by the 35s and probably also other HPs:

Code:

3,1           [SIN]  4,15806624333 E-2    exact
3,14          [SIN]  1,59265291648 E-3    last digit off (-1 ULP)
3,141         [SIN]  5,92653555096 E-4    last digit off (-3 ULP)
3,1415        [SIN]  9,26535896582 E-5    last 2 digits off (-25 ULP)
3,14159       [SIN]  2,65358979 E-6       last 3 digits lost
3,141592      [SIN]  6,5358979 E-7        last 4 digits lost
3,1415926     [SIN]  5,358979 E-8         last 5 digits lost
3,14159265    [SIN]  3,58979 E-9          last 6 digits lost
3,141592653   [SIN]  5,89793238463 E-10   exact
3,1415926535  [SIN]  8,97932384626 E-11   exact
3,14159265358 [SIN]  9,79323846264 E-12   exact

;-)

Dieter