HHC 2015 - Savage benchmark curiosity

[Claudio L.]

(10-08-2015 07:11 PM)Dieter Wrote:  The difference after an tan(arctan x) for x=1,57... here is 1 ULP of x = 1E–11 divided by the first arctan derivative, i.e. 1/(x²+1). Which yields ~ 1E–11*(1470²+1) = 2,161E–5 resp. 1E–11*(1648²+1) = 2,716E–5. Which is what you get. This also shows that a very, very slight error in x (merely one single ULP due to an even lesser error in the 15-digit result) will cause large errors in the next step. And these errors are very similar for x=1469, 1470 or 1471. So if one result is 1 ULP high and one of the next is 1 ULP low this yields very similar errors that may compensate each other.

You are getting close, and I think you understood perfectly well what I mean.
So for 1469 there's +2161e-5, then no more errors until 1648, where you have other +2716e-5, then who knows where there are more errors like this, from there all the way up to 2499.
From 1 to 1469 there are no errors, then from there on there's only errors in a few numbers, their magnitudes are not the same, as you correctly estimated 1/(x²+1), so how in the world the value goes back to the same result?
[/quote]

(10-08-2015 07:11 PM)Dieter Wrote:  But maybe I did not understand your surprise correctly. In this case please provide a step-by-step analysis.

I think you did, but here's the step-by-step:

The standard Savage Benchmark:
<< 1. 1. 2499. START SQ √ LN EXP ATAN TAN 1 + NEXT >>

Doing SQ √ in that order causes all results to be exact, so it has no effect for this analysis (it does for the speed benchmark of course).
The simplified loop is:
<< 1. 1. 2499. START LN EXP ATAN TAN 1 + DUP NEXT >>

in which I added a DUP at the end to keep all results in the stack.

The last value is 2499.99948647 (remember this one).

Now if you do:
1025 DROPN you'll see on your stack where the first problem happens.
1469.99992223, doing the loop by hand:
LN EXP gives you an exact result, back 1469.99992223
ATAN TAN 1 + gives the next value (incorrect): 1470.99993303

So, let's compute the correct value:
1469.99992223 ATAN 1E-11 - TAN 1 +
which gives 1470.99991143.

Let's now run the loop, but starting from the correct value and going up to 2499:

<< 1470.99991143 1471. 2499. START LN EXP ATAN TAN 1 + DUP NEXT >>

The only change is the initial value, and we start from iteration number 1471 going up to 2499.

Now look at the final value... 2499.99948647 (why the same?)

Here's another take: side by side computation of both sequences
<< { 1470.99991143 1470.99993303 } 1471. 2499. START LN EXP ATAN TAN 1 ADD DUP NEXT >>

The only change is that the initial value is now a list, and + was changed to ADD (on the 50g, those trying this on newRPL must keep the +).

I discovered that the lists get "in sync" again exactly at 1647, where the next error occurs.

The reduced loop:
<< { 1470.99991143 1470.99993303 } 1471. 1650. START LN EXP ATAN TAN 1 ADD DUP NEXT >>

shows exactly this: the first few values are identical, and then they are different.

Question still remains: why does it self-correct?