Mail Archives: djgpp/2001/06/16/11:30:08.1
On Sat, 16 Jun 2001 18:02:02 +0300, "Eli Zaretskii"
<eliz AT is DOT elta DOT co DOT il> sat on a tribble, which squeaked:
>Why did you need to test for NaNs at all? Testing for a NaN is a bit
>tricky, since it is defined to fail any test instruction. My advice
>would be to avoid futzing with NaNs in the first place.
>
>Do you really have NaNs in your computations, and if so, is there a
>way to get rid of them?
They arise from some sort of overflow. It's easier just to let them
accumulate and trap them. In any case, as you said they fail any test
instruction -- even checking what should always be true, namely the
square of a real number is non-negative.
As for why to test for them every so often? The failure will be caught
when the loop fails to converge after a maximal number of iterations,
but a NaN appearing before that allows an earlier bailout, speeding it
up. Also, I haven't determined the exact conditions for it to blow up.
Sometimes the values got very large and overflowed, but I'm not sure
about other times.
Regardless of all of this, the fundamental problem stays unaddressed:
a sequence of instructions is being misplaced by the optimizer.
--
Bill Gates: "No computer will ever need more than 640K of RAM." -- 1980
"There's nobody getting rich writing software that I know of." -- 1980
"This antitrust thing will blow over." -- 1998
Combine neo, an underscore, and one thousand sixty-one to make my hotmail addy.
- Raw text -