On 2006-12-21, at 22:19, David Nicol wrote:
It has always seemed to me that floating point comparison could
be standardized to regularize the exponent and ignore the least
significant
few bits and doing so would save a lot of headaches.
This would be a real nuisance. This myth that you should
never compare fpt numbers for absolute equality is nonsense.
There are lots of algorithms where it is legitimate to
compare for absolute equality (various kinds of iterations
that converge reliably to a single bit pattern for example).
It *is* a problem to have the 80-bit stuff intefering (in fact
Kahan pronounced this a bug in a Fortran compiler. Ada gets
around this by providing the 'Machine attribute that forces
a fpt number to a canonical machine representation in its type,
but it's a bit cumbersome. Note that the use of SSE on the x86
eliminates this problem.
> Marcin Dalecki:
Well actually it wouldn't "save the world". However adding an
op-code implementing: x eqeps y <=> |x - y| < epsilion, would be
indeed helpful.
Maybe some m-f has already patented it, and that's the reason we
don't see it
already done. But that's of course only me speculating.
There would be nothing wrong in having such an operation, but
it is not equality!
> David Nicol wrote:
I have argued for "precision" to be included in numeric types in
other forae
and have been stunned that all except people with a background in
Chemistry
find the suggestion bizarre and unnecessary;
if you are stunned by this, you need to study more about
computer arithmetic (btw I have a PhD in chemistry :-))
I realize that GCC is
not really
a good place to try to shift norms;
especially if the attempt is misguided. Floating-point semantics
in languages have been studied by a lot of experts, they are not
accidental!
Marcin Dalecki:
No that's not sufficient. And a few bit's of precision are really not
the
center-point of numerical stability of the overall calculation.
Please look up
as an example a numerical phenomenon which is usually called
"cancelation" to see
immediately why.
indeed!