Re: Sine and Cosine Accuracy

[Paul Koning <pkoning at equallogic dot com>]

>>>>> "Uros" == Uros Bizjak <uros@kss-loka.si> writes:

 Uros> Hello!
 >> Fair enough, so with 64 bit floats you have no right to expect an
 >> accurate answer for sin(2^90).  However, you DO have a right to
 >> expect an answer in the range [-1,+1] rather than the 1.2e+27 that
 >> Richard quoted.  I see no words in the description of
 >> -funsafe-math-optimizations to lead me to expect such a result.
 >> 
 Uros> The source operand to fsin, fcos and fsincos x87 insns must be
 Uros> within the range of +-2^63, otherwise a C2 flag is set in FP
 Uros> status word that marks insufficient operand reduction. Limited
 Uros> operand range is the reason, why fsin & friends are enabled
 Uros> only with -funsafe-math-optimizations.

 Uros> However, the argument to fsin can be reduced to an acceptable
 Uros> range by using fmod builtin. Internally, this builtin is
 Uros> implemented as a very tight loop that check for insufficient
 Uros> reduction, and could reduce whatever finite value one wishes.

 Uros> Out of curiosity, where could sin(2^90) be needed? It looks
 Uros> rather big angle to me.

It looks that way to me too, but it's a perfectly valid argument to
the function as has been explained by several people.

Unless -funsafe-math-optimizations is *explicitly* documented to say
"trig function arguments must be in the range x..y for meaningful
results" I believe it is a bug to translate sin(x) to a call to the
x87 fsin primitive.  It needs to be wrapped with fmod (perhaps after a
range check for efficiency), otherwise you've drastically changed the
semantics of the function.

Personally I don't expect sin(2^90) to yield 1.2e27.  Yes, you can
argue that, pedantically, clause (b) in the doc for
-funsafe-math-optimizations permits this.  Then again, I could argue
that it also permits sin(x) to return 0 for all x.

     paul