Aleksandar Donev wrote:
> I see--I have never used these switches before. NAG has a float-store
option
> and the manual says it helps "avoid problems with excess precision".
How can
> extra precision be a problem?
Having had to explain this to many customers over the years, it can be a
problem when you get different answers from what you saw elsewhere (or
perhaps without optimization.) Users complain that the optimized
answers are "wrong", when in fact they're often more accurate than the
non-optimized results.
Every time I encounter this, I am reminded of a customer back in my DEC
days who stood up at a DECUS presentation and proclaimed "I don't want
'better' - I want 'same'!" People who are not very familiar with how
floating point works naturally expect that the same computation will
give the same results everywhere. But there are many things that can
contribute to differences in results - different rounding caused by use
of extra precision registers or different order of operations, improved
math libraries, unstable algorithms which diverge rapidly given very
small differences in intermediate results, and more. (I once spent a
day at an engineering company analyzing why their bridge design program
came up with a significantly different result on a VAX than on their IBM
system. It came down to a difference in how the processor rounds (VAX
rounds away from zero), combined with an iterative algorithm that used
NINT in each step.)
This can be an especially difficult problem when there are "accepted as
correct" results that in fact aren't as good as they could be! The
"perils of floating point" are the bane of a compiler support engineer's
life.
Steve Lionel
Intel Corporation
|