This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: weird optimization in sin+cos, x86 backend


On 2/4/2012 9:09 AM, Andreas Schwab wrote:
Robert Dewar<dewar@adacore.com> writes:

But if you write a literal that can be represented exactly, then it is
perfectly reasonable to expect trig functions to give the proper
result, which is unambiguous in this case.

How do you know that the number is exact?

Sorry, what are you asking? Are you asking how do I know 1e22 is exact? That's an odd question, anyone who knows the IEEE format knows this.

Are you asking how a programmer in general knows this? Well
that's a question. As Vincent points out, if we write

x = some-fpt-constant;

it's hard to distinguish between

a) I know this can be represented exactly and I expect
the compiler to represent it exactly.

b) I know it cannot be represented exactly and I expect
the compiler to choose the nearest machine number using
round to nearest.

c) I don't have the slightest idea if this can be
represented exactly or not, but I expect the compiler
to come up with some close approximation.

If you don't have additional information, you really
can't distinguish these three cases. In the case where
we apply cos or sin to 1e22, we don't know if we have
case a) or case c). If we have case a), then it is
reasonable to expect sin (1e22) to be exactly the
right value for the sin function applied to this
exact number.

If you have case c), then taking the sin is a bit
senseless, since the level of approximation implied
by such a large number means that the sin function
iss essentially undefined in practice, since as someone
pointed out, it could reasonably range over a huge range
of values.

Andreas.




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]