weird optimization in sin+cos, x86 backend

[Robert Dewar]

On 2/3/2012 10:55 AM, Vincent Lefevre wrote:
> On 2012-02-03 10:33:58 -0500, Robert Dewar wrote:
>> On 2/3/2012 10:28 AM, Vincent Lefevre wrote:
>>> If the user requested such a computation, there should at least be
>>> some intent. Unless an option like -ffast-math is given, the result
>>> should be accurate.
>>
>> What is the basis for that claim? to me it seems useless to expect
>> anything from such absurd arguments. Can you site a requirement to
>> the contrary (other than your (to me) unrealistic expectations).
>> In particular, such large numbers are of course represented
>> imprecisely.
>
> Actually you don't know.

Yes, I do! The floating-point representation of this number
does NOT represent the number you wrote, but a slightly
different number, whose cos/sin values will be wildly
different from the cos/sin values of the number you wrote,
so what's the point of trying to get that value exact, when
it is not the value you are looking for anyway.

> Of course, the value probably comes from
> somewhere, where it is imprecise. But there are codes that assume
> that their input values should be regarded as exact or they will
> no longer work. Reasons can be that algorithms are designed in such
> a way and/or that consistency is important. A particular field is
> computational geometry. For instance, you have a point and a line
> given by their coordinates, which are in general imprecise.
> Nevertheless, one generally wants to consider that the point is
> always seen as being on one fixed side of the line (or exactly on
> the line). If some parts of the program, because they do not compute
> with high precision enough, behave as if the point were on some side
> and other parts behave as if the point were on the other side, this
> can yield important problems.

But if you write arbitrary floating-point constants, then of
course they are not represented exactly in general.
>
> Another property that one may want is "correct rounding", mainly
> for reproducibility. For instance, this was needed by the LHC@home
> project of CERN (to check results performed on different machines,
> IIRC), even though the results were complete chaos.

Well of course you will get different results for this on different
machines, regardless of "correct rounding", whatever that means!
>