> On Mon, May 28, 2012 at 5:36 PM, Lutz Euler <lutz.euler@...> wrote:
> > The test is about range reduction for trigonometric functions on large
> > float arguments, like (sin (expt 2d0 70)). It was introduced with commit
> > ad9090dc91fc922a with a fix for lp#327192 where Gabor had noticed that
> > on x86 the above expression returns 0d0 and Paul committed a change
> > introducing range reduction into the relevant VOPs on x86.
> > In short: The test is bogus. Even on x86 it only doesn't fail due to an
> > (un)lucky choice of test values. Trigonometric functions on large float
> > arguments on x86 still deliver completely wrong results. The x86-64 port
> > gets everything right but the test punishes that.
> > Basically, x86 gets things wrong because it does range reduction (even
> > for arguments below (expt 2 63), it seems) modulo some limited-precision
> > approximation of 2 pi.
> The thing is, branching on C2 and going through FPREM/2Pi is exactly
> what Intel recommends in their ISA reference: "It is up to the program
> to check the C2 flag for out-of-range conditions. Source values
> outside the range -263 to +263 can be reduced to the range of the
> instruction by subtracting an appropriate integer multiple of 2π or by
> using the FPREM instruction with a divisor of 2π." (I can't tell what
> section 8.3.8 of volume 1 means when we use FLDPI's 66 bit constant
> If it's good enough for the official docs, I believe that's
> good enough for SBCL as well.
That is fine with me. Unfortunately, x86-64, using libm, calculates
completely different results for large inputs, which have IMO at least
the same right to be considered good enough as what x87 calculates.
(I might even say: Unfortunately, time has passed, the restrictions
necessary when x87 was conceived no longer apply (like wanting to use
only a coarse approximation to pi), so libm takes a much improved
approach and yields correct results even where x87 is completely off.)
I started this thread saying that I am annoyed. That I am only about the
fact that x86-64 fails this test. I don't mind so much what x86 does.
> > - Completely revert the fix for lp#327192 on the account that delivering
> > 0 or some random value are both equally bad (the bug that "tan"
> > crashes can be fixed independently; there is only an "fldz" missing).
> Disagree. There's a lot of quibbling to be had wrt whether a FP value
> denotes a point or a range, but it's pretty clear to me that I should
> be able to depend on sin^2 + cos^2 = 1.
Fine with me. The list of possible changes I sent was not meant to mean
"I want all this changed" but more "Which subset of these changes would
> > - Change the test to test for correct results and mark x86 as failing.
> It's a different test than what was originally intended, but sure.
In light of what you wrote I don't insist on regarding x86's behaviour
Maybe we should just make the expected test results dependent on whether
the platform is x86 or not. With a bit of multi-precision arithmetic I
can build a reducer modulo 2 pi with sufficient precision to replicate
the results of the libm range-reduction and thus test that.
Just now I see that you enabled the test originally only for x86.
So another solution would be just to make the test x86-only again?