HP Forums - e^pi - pi + 9/10^4 + 1/(10^4*ln(2) + sqrt(10)/6)^2

Does anyone remember this old xkcd comic strip?

Evaluate the expression in the subject title on the WP 34S. You might want to set double precision on, or check it out at W|A:

http://www.wolframalpha.com/input/?i=e%5Epi+-+pi+%2B+9%2F10%5E4+%2B+1%2F%2810%5E4*ln%282%29+%2B+sqrt%2810%29%2F6%29%5E2

I found it yesterday, when playing with the WP 34S in double precision while waiting for Curiosity to land on Mars. There are no evidence the extra terms have any mathematical meaning though. The closeness to 20 in e^pi - pi is believed to be just a coincidence, by the way.

Well, for the posted expression, I got 20-(10^-8) on my HP-25C.

Edited: 6 Aug 2012, 2:29 p.m.

Hello Matt,

The correct 10, 12 or even 16-digit result would be 20, but one-digit difference in the last position is quite acceptable.

e^pi - pi + 9/10^4 + 1/(10^4*ln(2) + sqrt(10)/6)^2 = 20.000 000 000 000 000 729 511

Regards,

Gerson.

Well, for a Woodstock model, the accuracy is quite impressive. Haven't tried it on my Classics, though.

20.00000001 (15C, 41CV)
20.0000000000 (17BII, 42S, 48GX)

Paulo

19,99999999999999 on an HP200LX (Emulator) ... ;-)

HP Calculator, Version 1.0, 1990,1993 in DOSBox with Win7

Best regards

19,99999999999999, both on the emulator and on the real HP-200LX when solving EXP(PI)-PI+9/1E4+1/(1E4*LN(2)+SQRT(10)/6)^2=X for X.

Solving EXP(X)-X+9/1E4+1/(1E4*LN(2)+SQRT(10)/6)^2=20 for x will return 3,141592653589793, just as we would expect it to.

19,99999999999999 on the WP 34S (DBLOFF)

20,00000000000000072951111858382757 (DBLON)

(both results are accurate within 1 ULP)

Best regards,

Gerson.

Quote:
19,99999999999999 on the WP 34S (DBLOFF)

20,00000000000000072951111858382757 (DBLON)

(both results are accurate within 1 ULP)

This reminds me of Kahan's discussion "How accurate is accurate enough?
" in A Logarithm Too Clever by Half.

Edit:
On the 50g to 250 digits using longfloat v3.93:

20.000000000000000729511118583827559785599660921569

043259840768263504850897172305040683344584755775283

821628948893194895388850532202280827489024706316143

294490892312750265504548655938497110250316118344231

17652430009073789087367246779130257912195960634

Edited: 7 Aug 2012, 8:01 a.m.

Both 50g and 3çgII : 20. exactly

Quote:
19,99999999999999 on the WP 34S (DBLOFF)

20,00000000000000072951111858382757 (DBLON)

(both results are accurate within 1 ULP)

But are they correctly rounded? At least for the single precision result?

- Pauli

Ideally for the single precision it should be rounded to: 20

and for the double precision: 20.00000000000000072951111858382756

However, they are within 1 ulp (to the best of our knowledge (my 250 digit answer agrees with W/A) ).

HP 50G gives 20 exactly
HP 48GX gives 20 exactly
HP 39GS gives 20 exactly
TI-92+ gives 20 exactly
TI Nspire gives 20 exactly
HP 49G gives 20.0000000001.

Edited: 7 Aug 2012, 11:51 a.m.

TI-57: 20, exactly.

Rather than closeness to the actual result, I would like to call the attention to near integers, however. Almost Integer, or Near-Integer, is an interesting topic in Recreational Mathematics. Another example:

2*(e - atan(e)) = 2.9999979 (sticking to the TI-57, for a change :-)

20 on HP 39 GII ;-)

That wasn't what I meant :-(

Is each operation correctly rounded? As opposed to the final result (which you wouldn't expect to be correct given the number of operations involved).

e.g. e^pi = 23.1406926327792690057290863679485473802661....
rounded to sixteen digits this is: 23.14069263277927

23.14069263277927 - pi = 19.9990999791894767615373566167204971158....
which in turn rounds to: 19.99909997918948

etc.

The fact that the final result of so many operations is out by 1 ULP is luck mostly :-)

- Pauli

oops, forgot to round PI off to sixteen digits there. Oh well, the idea is the important bit.

- Pauli

Quote:

HP 50G gives 20 exactly
.
.
.
HP 49G gives 20.0000000001.

Interesting. Why the difference? I tried my 49g+ and that gives 20 as the 50g does.

Quote:
HP 49G gives 20.0000000001.

It' strange ... If found 20 with my 49G

But both 49 / 50G if you are in exact mode and do EVAL ->NUM you get 20.0000000001

The EVAL cas does a curious thing with the initial formula :

'((3600000000000*LN(2)^2+120000000*sqrt(10)*LN(2)+10000)*EXP(PI)-((3600000000000*PI-3240000000)*LN(2)^2+(120000000*sqrt(10)*PI-108000*sqrt(10))*LN(2)+(10000*PI-36009)))/(3600000000000*LN(2)^2+120000000*sqrt(10)*LN(2)+10000)'

(??)

I was wondering why you were concerned about the rounding of the answer instead of being happy with a good result. I should have known better :-).

I think we can safely assume that the 34s, set to 34 digit precision, will get the first 16 right. ;-)

So using the wonderful RSD command of this device you can determine the correct n-digit result with this little routine:

001 LBL A

002 DBLON

003 STO 00

004 # [pi]

005 RSD[->]00

006 e[^]x

007 RSD[->]00

008 # [pi]

009 RSD[->]00

010 -

011 RSD[->]00

012 # 009

013 SDR 004

014 +

015 RSD[->]00

016 # 002

017 LN

018 RSD[->]00

019 SDL 004

020 # 010

021 [sqrt]

022 RSD[->]00

023 # 006

024 /

025 RSD[->]00

026 +

027 RSD[->]00

028 x[^]2

029 RSD[->]00

030 1/x

031 RSD[->]00

032 +

033 RSD[->]00

034 END

Now let's see what the correct result for n digits working precision should look like:

16 [A] 19,99999999999999

15 [A] 19,9999999999999

12 [A] 20

10 [A] 20,00000001

Does this answer your question ?-)

Dieter

Quote:
I think we can safely assume that the 34s, set to 34 digit precision, will get the first 16 right. ;-)

Some of us have less faith :-) There most likely will be pathological values where correct rounding won't be achieved but they will be unusual.

Quote:
Now let's see what the correct result for n digits working precision should look like:
16 [A] 19,99999999999999

15 [A] 19,9999999999999

12 [A] 20

10 [A] 20,00000001
Does this answer your question ?-)

For the sixteen digit result, yes :-)

- Pauli

20 on TI 36X Pro

Quote:
TI-57: 20, exactly.

Hmhmhmhmhmhmhmmmm.... ;-)

First of all the obvious: a result of exactly 20 does not mean that the calculator is working perfectly. On the contrary, there is a perfect result for every n-digit machine, and this result is not neccessarily 20. But I think you will know this. :-)

As far as I know, the TI-57 displays 8 digits, but internally it works with 10 digit precision. For a 10-digit machine, the perfect result is 20.00000001. So if the TI-57 returns exactly 20, it simply is 1 ULP off. BTW the perfect 8-digit result is 20.000001.

Are you sure you get a plain 20, and not 20.00000001? What do you see in the display if you subtract 20 from the final result? Zero or 1E-8?

Just curious, ;-)

Dieter

Dieter wrote :

Quote:
For a 10-digit machine, the perfect result is 20.00000001

Why ?

20.000000000000000729511118583827559785599660921569....

12 345678901234567890... 

                 ^

I think that the 'perfect' result must be exactly 20 until 16 digits and 20.000000000000001 for 17 digits

Quote:
First of all the obvious: a result of exactly 20 does not mean that the calculator is working perfectly. On the contrary, there is a perfect result for every n-digit machine, and this result is not neccessarily 20. But I think you will know this. :-)

Yes, I am aware of that. I still remember one of Roger Rosenbaum's lessons on this topic :-)

http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv016.cgi?read=103151

Quote:
As far as I know, the TI-57 displays 8 digits, but internally it works with 10 digit precision.

11 digits, actually:

7 1/x * 10000  =   -->   1428.5714

- 1428 =           -->      0.5714285

Quote:
Are you sure you get a plain 20, and not 20.00000001? What do you see in the display if you subtract 20 from the final result? Zero or 1E-8?

Yes, I am. The first three terms suffice for displaying 20 on the display, and sqrt(10)/6 is not necessary for the exact 20 result. By the way, what is the perfect 11-digit result for the complete expression? Just curious (but not curious enough to check it on your nice WP 34S program above :-)

Cheers,

Gerson.

_{Edited to fix a typo}

Edited: 8 Aug 2012, 4:14 p.m.

Gilles,

By 'perfect result' he means the result we obtain when all intermediate calculations are properly rounded. Please take a look at this old thread:

http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv016.cgi?read=103151

Regards,

Gerson.

If the TI-57 actually uses 11 internal digits the result is fine: Both for 11- and 12-digit machines the perfect result is a plain 20.

However, the last (11th) digit on the -57 seems to be truncated instead of rounded. Take a look at your example: you get 0.5714285 while, correctly rounded, it should be 0.5714286. ;-)

BTW, I took that 34s program and inserted some print commands. Here are the intermediate results for 10, 11 and 12 digits:

10 digits
3,141592654
23,14069264
19,99909999
19,99999999
0,6931471806
3,16227766
0,5270462767
6.931,998852
48.052.608,08
2,081052496e-8
20,00000001

11 digits
3,1415926536
23,140692633
19,999099979
19,999999979
0,69314718056
3,1622776602
0,5270462767
6.931,9988519
48.052.608,083
2,0810524962e-8
20

12 digits
3,14159265359
23,1406926328
19,9990999792
19,9999999792
0,69314718056
3,16227766017
0,5270462767
6.931,99885188
48.052.608,0825
2,08105249622e-8
20

Just in case, if you want to compare this with what you get from the -57. ;-)

Dieter

Gilles, the "perfect result" is the one you get from a perfect calculator. Let's suppose you got a 10-digit calculator and you want to evaluate 1/3 x 3. What is the perfect result?

First step:   1 / 3  =  0.3333333333

Second step:  0.3333333333 x 3  =  0.9999999999

If the calculator returns 1 it obviously does something wrong.

The point is, that real-world calculators work with limited precision, be it 10, 30 or 50 digits. This means that, for instance, you will never evaluate sqrt(pi), but sqrt(3,141592654). You will never work with 1/3 - the best you can get is 0.33333333...

For the same reason, the perfect result (i.e. the result from a perfect, error-free calculator) of this well-known "Forensic test" is not 9, but 9,000417403 for 10-digit machines and 8,99999864267 for those with 12 digits. Now guess which calculators get exactly these results... :-)

All this is the reason why there are calculators than can do symbolic math. ;-)

Dieter

I keyed in your wonderful little program and get from my WP 34S in ALL 00:

34 [A] 20. [<] 20.000 000 000 000 00 [>] 0 729 511 118 583 827 57

33 [A] 20. [<] 20.                   [>] 0 729 511 118 583 827 5

32 [A] 20. [<] 20.                   [>] 0 729 511 118 583 827

31 [A] 20. [<] 20.                   [>] 0 729 511 118 583 84

30 [A] 20. [<] 20.                   [>] 0 729 511 118 583 9

...

24 [A] 20. [<] 20.000 000 000 000 00 [>] 0 729 511 1

23 [A] 20. [<] 20.                   [>] 0 729 510

22 [A] 20. [<] 20.                   [>] 0 729 52

21 [A] 20. [<] 20.                   [>] 0 729 4

20 [A] 20. [<] 20.                   [>] 0 730

19 [A] 20. [<] 20.                   [>] 0 72

18 [A] 20. [<] 20.                   [>] 0 8

17 [A] 20. [<] 20.

16 [A] 20. [<] 19.999 999 999 999 99

15 [A] 20. [<] 19.999 999 999 999 9

14 [A] 20. [<] 20.

13 [A] 20. [<] 20.

12 [A] 20. [<] 20.

11 [A] 20. [<] 20.

10 [A] 20.000 000 01 

 9 [A] 19.999 999 8

 8 [A] 20.000 001

FWIW

Edited: 9 Aug 2012, 7:25 a.m.

Good old Windows Calculator in scientific mode :)

20.000000000000000729511118583828

Google calculator gives 20 exactly.

Quote:
Just in case, if you want to compare this with what you get from the -57. ;-)

TI-57
3,1415926536
23,140692633
19,999099981
19,999099980
0,69314718100
3,1622776600
0,52704627666
6.931,9988562
48.052.608,141
2,0810524937e-8
20

Whenever the TI-57 gets a perfect result, this is due to coincidence only. But we already knew that :-)

Gerson.

Multi Precision RPN Calculator, precision set to 200 decimal places..

19.999200000000000729511118583827559785599660921569043259840768263504850897172305040683344584755775283821628948893194895388850532202280827489024706316143294490892312750265504548655938497110250316118344

I fear somehow the third term has been evaluated as 1/10^4, instead of 9/10^4.

You know, I do believe you are exactly right!

OK, if I didn't make another bone headed mistake, the answer to 200 places is

20.000000000000000729511118583827559785599660921569043259840768263504850897172305040683344584755775283821628948893194895388850532202280827489024706316143294490892312750265504548655938497110250316118344, same as a lot of the others through 20 or so digits after the decimal point. Thanks Gerson.

Quote:
For a 10-digit machine, the perfect result is 20.00000001

I get 20.

RPN style:

10 SQRT : 3.16227766

6 / : 0.5270462767

2 LN : 0.6931471806

1E4 * : 6931.471806

+ : 6931.998852

1/x : 2.081052496 E-08

9E-4 + : 9.000208105 E-04

PI : 3.141592654

- : -3.140692633

e : 2.718281828

PI : 3.141592654

y^x : 23.14069263

+ : 20

Quote:
23.14069264

I would expect a 10-digit machine to get 23.14069263 for e^pi:

e to 10 digits: 2.718281828
pi to 10 digits: 3.141592654

2.718281828^3.141592654 = 23.14069263 to 10 digits.

Thus:

10 digits

            3.141592654

            23.14069263

            19.99909997

            19.99999997

           0.6931471806

             3.16227766

           0.5270462767

           6,931.998852

          48,052,608.08

         2.081052496e-8

            19.99999999

This disagrees slightly with my answer (in anoher post) as I choose to do it in a different order.

More digits to the last result here would be: 19.99999999081052496

More digits to the last result of my other post would be: 19.999999997

So this once again highlights the fallacy of claiming a "perfect" result to "n digits".

I understand ...

On my CASIO FX 602P

1 / 3 = * 3 returns _exactly_ 3 wich is not the 'perfect' result ;). The number is not rounding to 1 before display, it's 1 in memory.
1/3*3-1 is 0

1/7*7 -> 1 exactly etc...

It is 10 digits display (or 9 as a . takes the place of one digit) and 12 digits calculation but there is a rounding process in some calculations (I dont know exactly what it does )

e^pi - pi + 9/10^4 + 1/(10^4*ln(2) + sqrt(10)/6)^2

display 20 but is 20.0000000002 (result - 20 returns 8E-10)

Edited: 9 Aug 2012, 7:03 a.m.

Quote:
1 / 3 = * 3 returns _exactly_ 3 wich is not the 'perfect' result ;)

First of all I hope I does not return 3, maybe exactly 1. ;-) And yes, there is something going on in you FX602P. In this case this probably is caused by the fact that it uses 11 digits internally, so that it actually evaluates 0,333 333 333 33 x 3 = 0,999 999 999 99 which then is rounded for the display to a plain 1. What do you get after a final - 1 = ?

Quote:
display 20 but is 20.0000000002 (result - 20 returns 8E-10)

If after this you get 8E-10, the actual result was 20,0 000 000 008 which means the result has 12 (!) digits. Are you really sure? BTW, both for 11 and 12-digit precision the perfect result is exactly 20.

Dieter

Quote:
I would expect a 10-digit machine to get 23.14069263 for e^pi
e to 10 digits: 2.718281828

pi to 10 digits: 3.141592654
2.718281828^3.141592654 = 23.14069263 to 10 digits

Sure, but that's not what any (reasonable) calculator calculates. ;-)

The exponential function is not (!) evaluated by raising a ten-digit value of e to the x-th power. The internal e^x function is different from 2,718281828^x. That's why there is such a special function. It's essentially the same as in virtually all programming languages: there is pow(a,x) or a power operator for powers of two arbitrary arguments, and there is exp(x) for the special case of the exponential function e^x. In this case the constant e does not show up anywhere.

So the calculator determines the value of exp(3,141592654) which is 23,14069264227... which here is returned as 23,14069264.

Dieter

Hi Bart,

Quote:

...

- :  -3.140692633

e :   2.718281828

PI :  3.141592654

y^x : 23.14069263

+ :   20

As explained in my other post:

...

- :   -3.140692633

PI :   3.141592654

e^x :  23.14069264

+ :    20.00000001

q.e.d.

Dieter

Oups ! Sorry for the mistakes ! yes it is 20,0 000 000 008

Yes i'm sure that the 602P uses 12 digits in memories and X Y registers. I used this in some programs to memorize 12 digits in only one memory (12 memories 0..9 in one) and it works fine...

.123456789 + 123E-12 = (Display .123456789)
-
.123456789
returns
1.23E-10

It seems that the 602P has a curious algorithm about rounding the 12th digits.

1-(0.333333333+33E-11)*3 -> 1E-11

1-(0.333333333+333E-12)*3 -> 0 (and (1/3)*3-1 -> 0)

1-(0.333333333+333E-12)-0.666666666 -> 667E-12

1 - 0.333333333 - 333E-12 - 0.666666666 - 666E-12 -> 1E-12

But

0.333333333 + 333E-12 + 0.666666666 + 666E-12 - 1 -> 0

Edited: 9 Aug 2012, 8:38 a.m.

The original formula states e^pi, not exp(pi).

For that matter, if you talk about a calculator, some scientifics I have, have the constant e, not the function exp(), and any reasonable calculator that has exp() usually also has more digit accuracy (and i'm not just talking about dispayed digits).

Edited: 9 Aug 2012, 8:36 a.m.

No, see my answer to your post above.

wait-wait-wait!! An HP200LX emulator?!? Realy an emulator?? Or the Connectivity Pack, I assume.

Ciao.....Mike

Mike,

the Connectivity Pack was used.

But isn't it an emulator?

Best regards

Well, the Connectivity Pack is compiled from the same sources like the SW running on the real HW. But an emulation would emulate the 200LX HW and would allow the 'switching' of applications. Alas this is not possible in the Connectivity Pack where you have tho close an application before you can start an other one.

Ciao.....Mike