▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
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 WA:
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.
▼
Posts: 980
Threads: 239
Joined: Aug 2006
Well, for the posted expression, I got 20(10^8) on my HP25C.
Edited: 6 Aug 2012, 2:29 p.m.
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
Hello Matt,
The correct 10, 12 or even 16digit result would be 20, but onedigit 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.
▼
Posts: 980
Threads: 239
Joined: Aug 2006
Well, for a Woodstock model, the accuracy is quite impressive. Haven't tried it on my Classics, though.
▼
Posts: 76
Threads: 6
Joined: Sep 2011
20.00000001 (15C, 41CV)
20.0000000000 (17BII, 42S, 48GX)
Paulo
▼
Posts: 174
Threads: 20
Joined: Sep 2006
19,99999999999999 on an HP200LX (Emulator) ... ;)
HP Calculator, Version 1.0, 1990,1993 in DOSBox with Win7
Best regards
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
19,99999999999999, both on the emulator and on the real HP200LX 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.
▼
Posts: 850
Threads: 10
Joined: Mar 2009
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.
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
▼
Posts: 850
Threads: 10
Joined: Mar 2009
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) ).
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
oops, forgot to round PI off to sixteen digits there. Oh well, the idea is the important bit.
 Pauli
Posts: 850
Threads: 10
Joined: Mar 2009
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 :).
Posts: 653
Threads: 26
Joined: Aug 2010
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 ndigit 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
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
Posts: 4,587
Threads: 105
Joined: Jul 2005
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.
Posts: 858
Threads: 80
Joined: Feb 2009
waitwaitwait!! An HP200LX emulator?!? Realy an emulator?? Or the Connectivity Pack, I assume.
Ciao.....Mike
▼
Posts: 174
Threads: 20
Joined: Sep 2006
Mike,
the Connectivity Pack was used.
But isn't it an emulator?
Best regards
▼
Posts: 858
Threads: 80
Joined: Feb 2009
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
Posts: 468
Threads: 17
Joined: May 2011
Both 50g and 3çgII : 20. exactly
▼
Posts: 253
Threads: 20
Joined: Jun 2012
HP 50G gives 20 exactly
HP 48GX gives 20 exactly
HP 39GS gives 20 exactly
TI92+ gives 20 exactly
TI Nspire gives 20 exactly
HP 49G gives 20.0000000001.
Edited: 7 Aug 2012, 11:51 a.m.
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
TI57: 20, exactly.
Rather than closeness to the actual result, I would like to call the attention to near integers, however. Almost Integer, or NearInteger, is an interesting topic in Recreational Mathematics. Another example:
2*(e  atan(e)) = 2.9999979 (sticking to the TI57, for a change :)
▼
Posts: 59
Threads: 5
Joined: Jul 2011
Posts: 653
Threads: 26
Joined: Aug 2010
Quote:
TI57: 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 ndigit machine, and this result is not neccessarily 20. But I think you will know this. :)
As far as I know, the TI57 displays 8 digits, but internally it works with 10 digit precision. For a 10digit machine, the perfect result is 20.00000001. So if the TI57 returns exactly 20, it simply is 1 ULP off. BTW the perfect 8digit 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 1E8?
Just curious, ;)
Dieter
▼
Posts: 468
Threads: 17
Joined: May 2011
Dieter wrote :
Quote:
For a 10digit 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
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
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/cgisys/cgiwrap/hpmuseum/archv016.cgi?read=103151
Regards,
Gerson.
Posts: 653
Threads: 26
Joined: Aug 2010
Gilles, the "perfect result" is the one you get from a perfect calculator. Let's suppose you got a 10digit 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 realworld 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, errorfree calculator) of this wellknown "Forensic test" is not 9, but 9,000417403 for 10digit 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
▼
Posts: 468
Threads: 17
Joined: May 2011
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*31 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 8E10)
Edited: 9 Aug 2012, 7:03 a.m.
▼
Posts: 653
Threads: 26
Joined: Aug 2010
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 8E10)
If after this you get 8E10, 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 12digit precision the perfect result is exactly 20.
Dieter
▼
Posts: 468
Threads: 17
Joined: May 2011
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 + 123E12 = (Display .123456789)

.123456789
returns
1.23E10
It seems that the 602P has a curious algorithm about rounding the 12th digits.
1(0.333333333+33E11)*3 > 1E11
1(0.333333333+333E12)*3 > 0 (and (1/3)*31 > 0)
1(0.333333333+333E12)0.666666666 > 667E12
1  0.333333333  333E12  0.666666666  666E12 > 1E12
But
0.333333333 + 333E12 + 0.666666666 + 666E12  1 > 0
Edited: 9 Aug 2012, 8:38 a.m.
Posts: 2,761
Threads: 100
Joined: Jul 2005
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 ndigit 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/cgisys/cgiwrap/hpmuseum/archv016.cgi?read=103151
Quote:
As far as I know, the TI57 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 1E8?
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 11digit 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.
▼
Posts: 653
Threads: 26
Joined: Aug 2010
If the TI57 actually uses 11 internal digits the result is fine: Both for 11 and 12digit 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,081052496e8
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,0810524962e8
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,08105249622e8
20
Just in case, if you want to compare this with what you get from the 57. ;)
Dieter
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
Quote:
Just in case, if you want to compare this with what you get from the 57. ;)
TI57
3,1415926536
23,140692633
19,999099981
19,999099980
0,69314718100
3,1622776600
0,52704627666
6.931,9988562
48.052.608,141
2,0810524937e8
20
Whenever the TI57 gets a perfect result, this is due to coincidence only. But we already knew that :)
Gerson.
Posts: 850
Threads: 10
Joined: Mar 2009
Quote:
23.14069264
I would expect a 10digit 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.081052496e8
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".
▼
Posts: 653
Threads: 26
Joined: Aug 2010
Quote:
I would expect a 10digit 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 tendigit value of e to the xth 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
▼
Posts: 850
Threads: 10
Joined: Mar 2009
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.
Posts: 850
Threads: 10
Joined: Mar 2009
Quote:
For a 10digit 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 E08
9E4 + : 9.000208105 E04
PI : 3.141592654
 : 3.140692633
e : 2.718281828
PI : 3.141592654
y^x : 23.14069263
+ : 20
▼
Posts: 653
Threads: 26
Joined: Aug 2010
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
▼
Posts: 850
Threads: 10
Joined: Mar 2009
No, see my answer to your post above.
Posts: 455
Threads: 39
Joined: Jan 2011
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.
Posts: 468
Threads: 17
Joined: May 2011
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*PI3240000000)*LN(2)^2+(120000000*sqrt(10)*PI108000*sqrt(10))*LN(2)+(10000*PI36009)))/(3600000000000*LN(2)^2+120000000*sqrt(10)*LN(2)+10000)'
(??)
▼
Posts: 59
Threads: 5
Joined: Jul 2011
Posts: 253
Threads: 20
Joined: Jun 2012
Good old Windows Calculator in scientific mode :)
20.000000000000000729511118583828
▼
Posts: 253
Threads: 20
Joined: Jun 2012
Google calculator gives 20 exactly.
Posts: 253
Threads: 20
Joined: Jun 2012
Multi Precision RPN Calculator, precision set to 200 decimal places..
19.999200000000000729511118583827559785599660921569043259840768263504850897172305040683344584755775283821628948893194895388850532202280827489024706316143294490892312750265504548655938497110250316118344
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
I fear somehow the third term has been evaluated as 1/10^4, instead of 9/10^4.
▼
Posts: 253
Threads: 20
Joined: Jun 2012
You know, I do believe you are exactly right!
Posts: 253
Threads: 20
Joined: Jun 2012
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.
