|Low-order uncertainty in 87 math processing firstname.lastname@example.org (1997-09-24)|
|Re: Low-order uncertainty in 87 math processing email@example.com (David L Moore) (1997-09-24)|
|Re: Low-order uncertainty in 87 math processing firstname.lastname@example.org (William D Clinger) (1997-09-27)|
|From:||David L Moore <email@example.com>|
|Date:||24 Sep 1997 22:27:29 -0400|
Stephen Schumacher wrote:
> [code not changing x or y]
> [ why is q not zero]
John's suggestions (esp about NAN) are good. As you say it only happens
occasionally, without seeing all the code and knowing the input values,
I would have to rate this the most likely explanation.
Here is another. Unfortunately, you did not give the disassembly, so
I cannot check if this is happening.
If x is getting stored and y is being retained in a floating register,
you lose some precision of x but not y, and the difference in q is the
round-off between the values. (Of course, it might be y that is stored
instead of x, too)
MNF (Minnesota University Fortran) used to print out a warning message
on all attempts to compare floating point numbers for equality.
It went along the lines of "Can this really be expected to compare
and was delivered with a stern wagging of fingers.
[Given that the wierd behavior is repeatable but goes away sometimes until
a reboot, I'd still be looking at those persistent x87 control flags. -John]
Return to the
Search the comp.compilers archives again.