From: <lutz.euler@fr...>  20120529 18:36:35

Hi Paul, > 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 x8664 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 limitedprecision > > 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 outofrange 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 > directly). I understand. > 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, x8664, 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 x8664 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 be sensible?". > >  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 as "failing". Maybe we should just make the expected test results dependent on whether the platform is x86 or not. With a bit of multiprecision arithmetic I can build a reducer modulo 2 pi with sufficient precision to replicate the results of the libm rangereduction 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 x86only again? Greetings, Lutz 