Torture tests: what do they mean?

[Gerald H]

I find consistently most accurate & precise the 32kb Sharp memory card OZ or IQ-8B03 in a Sharp IQ organizer, small enough for my jacket pocket.

[jebem]

(05-17-2014 06:53 AM)Joe Horn Wrote:  

(05-16-2014 08:52 AM)jebem Wrote:  HP-Prime in CAS mode result: 400
HP-Prime Home mode: 0
Correct mathematical result: 720.

Please note that this wasn't really done in "Exact/CAS mode" as requested. The decimal point in the 7.2 forces Prime to evaluate the whole thing in approximate mode, not exact mode. If you really want to evaluate that expression in Exact/CAS mode, you must use 72/10 (or any other exact equivalent of 7.2, e.g. 7+1/5) instead of 7.2 with a decimal point in it. If you do that, you'll get the correct answer of 720 in Exact/CAS mode.

Hi Joe, Thanks a lot for your input on this theme.
Yes, I still believe in my beloved HP-Prime. as Dieter and others pointed out, the tool is not guilty per se, so one need to understand it first before taking full advantage of the machine.
It is always a pleasure to read your posts, despite that I can't always follow your mathematical expertize due to my lack of math theory background. But I'm learning... And this is not intended to worship you, it is just what I feel about it.

[jebem]

(05-17-2014 08:20 AM)Tugdual Wrote:  Hi Jebem,
please note that the 34s has a "double" precision mode.
I do get -7497258.185325587112905071814481370
Wolfram Alpha says that the result shall be
-7.497258185325587112905071831891248663417267943785263161571223470151837884956238​9571281869682281839570540842373435... × 10^6

So the 34s could achieve 26 digits.
Quite impressive but I will not congratulate Walter or he will think I worship him...

Bonjour, Tugdual!
But why not? A little worship here and there is good to keep good mood in this glorious Saturday morning (well, at least it is here in southern Europe)

[Paul Dale]

(05-17-2014 08:20 AM)Tugdual Wrote:  I do get -7497258.185325587112905071814481370
Wolfram Alpha says that the result shall be
-7.497258185325587112905071831891248663417267943785263161571223470151837884956238​9571281869682281839570540842373435... × 10^6

So the 34s could achieve 26 digits.

Internally, this is computed using 39 digits so thirteen digits are wrong. Converting back to 34 digit double precision numbers isn't introducing more than a rounding error in the 34th digit which is already incorrect.

Quote:Quite impressive but I will not congratulate Walter or he will think I worship him...

It wouldn't go to Walter's head. I wrote the vast majority of the mathematical functions


- Pauli

[walter b]

(05-17-2014 10:17 AM)Paul Dale Wrote:  

Tugdual Wrote:Quite impressive but I will not congratulate Walter or he will think I worship him...

It wouldn't go to Walter's head. I wrote the vast majority of the mathematical functions

So true! And Remy, unless you address us using "oh Lord" again we won't think of worshipping.

d:-)

[Dieter]

(05-17-2014 08:20 AM)Tugdual Wrote:  please note that the 34s has a "double" precision mode.
I do get -7497258.185325587112905071814481370
Wolfram Alpha says that the result shall be
-7.497258185325587112905071831891248663417267943785263161571223470151837884956238​9571281869682281839570540842373435... × 10^6

So the 34s could achieve 26 digits.

As shown earlier, you generally cannot trust the last 8 digits. So 34–8 = 26 digits is the expected accuracy here. Likewise, the 32-digit Windows calculator returns -7497258,1853255871129050827752131, which is +1 unit in the 24th digit. Again, the last eight digits are off.

Now try Wolfram Alpha with the tangent of 355/226 rounded to 34-digits. This is what the 34s actually evaluates. You'll get tan(1,570796460176991150442477876106195) = -7497258,185325587112905071814481418... This agrees with the 34s result in 32 out of 34 digits.

Dieter

[Tugdual]

(05-17-2014 10:17 AM)Paul Dale Wrote:  

(05-17-2014 08:20 AM)Tugdual Wrote:  I do get -7497258.185325587112905071814481370
Wolfram Alpha says that the result shall be
-7.497258185325587112905071831891248663417267943785263161571223470151837884956238​9571281869682281839570540842373435... × 10^6

So the 34s could achieve 26 digits.

Internally, this is computed using 39 digits so thirteen digits are wrong. Converting back to 34 digit double precision numbers isn't introducing more than a rounding error in the 34th digit which is already incorrect.

Quote:Quite impressive but I will not congratulate Walter or he will think I worship him...

It wouldn't go to Walter's head. I wrote the vast majority of the mathematical functions


- Pauli

Paul, this is definitely an achievement, the 34s is an amazing tool, I use it on a regular base. I started some little programming on it recently and I love it.
Not sure I ever formally spent time to thank the team for that, not forgetting Marcus who also actively and very kindly helped me to flash it.

Note: Oh and BTW Paul, wish list item: I prefer complex numbers on the 15C with a dual stack ;-) ... for next time, may be on the 43s iteration?

[walter b]

(05-17-2014 09:17 PM)Tugdual Wrote:  I prefer complex numbers on the 15C with a dual stack ;-) ... for next time, may be on the 43s iteration?

The 43S is going to feature a special complex data type. Just plain RPN, no dual stack gymnastics. Sorry But you'll get 8 stack levels for calculating.

d:-)

[Tugdual]

(05-17-2014 09:30 PM)walter b Wrote:  

(05-17-2014 09:17 PM)Tugdual Wrote:  I prefer complex numbers on the 15C with a dual stack ;-) ... for next time, may be on the 43s iteration?

The 43S is going to feature a special complex data type. Just plain RPN, no dual stack gymnastics. Sorry But you'll get 8 stack levels for calculating.

d:-)

Nice! I guess I can cope with 8 stack registers (damned you remember all the details of our former discussions, this is scary Walter). And for the complex numbers simplification, I will invest the saved money for my brain expansion on a pre-order for the 43s. Where is your kickstarter?

[Paul Dale]

(05-17-2014 08:29 PM)Dieter Wrote:  As shown earlier, you generally cannot trust the last 8 digits. So 34–8 = 26 digits is the expected accuracy here.

Except that TAN is coded in C and uses the 39 digit internal representation during the entire evaluation. I'm losing 13 digits which is a concern.

I think I've traced this to the COS series expansion losing the last five or six digits for a reason I cannot yet fathom. I'll keep poking around.


- Pauli

[Paul Dale]

Figure it out. Two problems. The series for COS was terminating when the series for SIN converged a term earlier. The second is a cancellation due to the way I sum the series


- Pauli

[Paul Dale]

And the next 34S build will have this fixed

TAN should return the correctly rounded result for 355/266 without losing the eight digits
Likewise, COS very close to pi/2 won't have the problem either.


- Pauli

[DavidM]

(05-18-2014 01:12 AM)Paul Dale Wrote:  And the next 34S build will have this fixed

TAN should return the correctly rounded result without losing the eight digits
Likewise, COS very close to pi/2 won't have the problem either.
- Pauli

Although I really can't imagine ever needing those deep digits for anything, I'm glad you found it and were able to apply a fix.

This has been a great example of a curious inquiry (Jose's original) leading to eventual discovery and subsequent corrective action for a useful tool that impacts a much wider audience.

One of the "happy accidents" of life... we need more of these, don't we?

[HP67]

(05-16-2014 10:22 PM)jebem Wrote:  Hi David,
Agree of course.
Since my days from electrical engineering school that we just needed 2 or 3 decimal places in our calculations, so it was common to use fix 2 on my hp-25. Rounding and knowing the error margin did the trick in common electronic circuits.

Still works for money

[walter b]

(05-18-2014 10:15 AM)HP67 Wrote:  

(05-16-2014 10:22 PM)jebem Wrote:  Since my days from electrical engineering school that we just needed 2 or 3 decimal places in our calculations, so it was common to use fix 2 on my hp-25. Rounding and knowing the error margin did the trick in common electronic circuits.

Still works for money

Watch it: few people work as precisely as fincial controllers.

d;-)

[jebem]

(05-18-2014 01:12 AM)Paul Dale Wrote:  And the next 34S build will have this fixed

TAN should return the correctly rounded result for 355/266 without losing the eight digits
Likewise, COS very close to pi/2 won't have the problem either.
- Pauli

Thank you for sharing your work with us!
This is a real dedication to science and to the WP-34S project.
Well done, Pauli.

[Dieter]

(05-18-2014 12:04 AM)Paul Dale Wrote:  

(05-17-2014 08:29 PM)Dieter Wrote:  As shown earlier, you generally cannot trust the last 8 digits. So 34–8 = 26 digits is the expected accuracy here.

Except that TAN is coded in C and uses the 39 digit internal representation during the entire evaluation. I'm losing 13 digits which is a concern.

The argument of the tangent can be given to at most 34 digits. This (!) is the reason why eight digits are lost. There may be a bug in the tangent routine but I do not think it's the cause of what we're seeing here.

Here are some results from Wolfram Alpha:

tan(1.570796460176991150442477876106194) = -7497 258.1 8532 5587 1129 0507 1870 6902 99
tan(1.570796460176991150442477876106195) = -7497 258.1 8532 5587 1129 0507 1814 4814 18
tan(1.570796460176991150442477876106196) = -7497 258.1 8532 5587 1129 0507 1758 2725 38

As shown earlier, the result changes by 0,562 units of the 26th digit if the 34th digit of the argument changes by 1 unit.
So all we know is that the tangent of 355/226 is -7497 258.1 8532 5587 1129 0507 18...

If (!) the user was able to provide a 39-digit representation of 355/226 (for instance with a dedicated TAN_Y/X function) the 34s might get 31 digits right. Otherwise just 26 correct digits can be expected here. That's why I wonder why the 34s returns 31-32 correct digits. ;-)

Dieter

[Manolo Sobrino]

(05-18-2014 03:09 PM)Dieter Wrote:  If (!) the user was able to provide a 39-digit representation of 355/226 (for instance with a dedicated TAN_Y/X function) the 34s might get 31 digits right. Otherwise just 26 correct digits can be expected here. That's why I wonder why the 34s returns 31-32 correct digits. ;-)

With a 39-digit 255/226 you get:

Tan[1.570796460176991150442477876106194690265486725663716814159`39] = -7.4972581853255871129050718318912*10^6

a 32-digit result, and as you point out and I've been hopelessly trying to convey to readers indoctrinated with the fallacy that x significant digits in the input grant x significant digits in the output, no matter what, there's nothing you can do about it in order to get 39... because that would mean that you can work with 46 (in this particular case).

Why, oh why should all the functions be isometries?

[Dieter]

(05-18-2014 07:42 PM)Manolo Sobrino Wrote:  With a 39-digit 255/226 you get:
...
a 32-digit result

This is also possible using a standard 34s an brain 1.0:

0 cos^–1 (first 34 digits of pi/2, rounded down)
355 ENTER 226 / – (last seven digits are lost by cancellation)
4,420985847 E–34 + (add back next digits of pi/2)
tan 1/x => –7497258,185325587112905071814481421

Or, if the tangent of 355/226 (unrounded) is required:

pi ENTER 2 / (first 34 digits of pi/2, rounded up)
355 ENTER 226 / – (last seven digits are lost by cancellation)
2,481669 E–34 – (next digits of pi/2 – 355/226)
tan 1/x => –7497258,185325587112905071831891251

Close to perfect – both cases are just 2...3 ULP off. ;-)

Dieter

[Paul Dale]

(05-18-2014 03:09 PM)Dieter Wrote:  If (!) the user was able to provide a 39-digit representation of 355/226 (for instance with a dedicated TAN_Y/X function) the 34s might get 31 digits right. Otherwise just 26 correct digits can be expected here. That's why I wonder why the 34s returns 31-32 correct digits. ;-)

With the old code, the 34S is attempting to calculate the tangent of a thirty four digit number:

Code:

TAN(1.570796460176991150442477876106195) =
    -7497258.18532558711290507181448136970156

    -7497258.185325587112905071814481418482796577296176634279

Which is 31 digits as you mentioned. Eight digits are being lost which is what I thought was expected.

With the new code, it would get all 39 digits for the same input. I added some extra digits for the computation of the TAN function. The sledgehammer approach to numerical analysis. For an input of PI/2 (rounded to 34 digits), TAN isn't anything like as good, it gets seventeen digits correct. I could fix this by adding more digits to the intermediate computations but I'm not sure of the memory ramifications -- I know we're pretty close to the stack limit for the path that goes through the incomplete beta function, to lngamma, to sincos.


- Pauli