Re: Win32: 0.0 / 0.0 = -NAN ? Win64: 0.0 / 0.0 = -1, #IND ?From: R Kym HorsellNewsgroups:
Mon, 2 May 2022 02:48 UTC
References: 1 2
View all headers
Skybuck Flying <firstname.lastname@example.org> wrote:
I discovered another dangerous one while trying to compute overlap of interval (basically ranges) and/or trying to clip/cap line segments:
0 * +infinity = -NAN
This happens as the ray is on the edge of a boundary/box... cause tMinX will become -NAN.
Leading to weird situations depending on how the code was written, either the wrong point will be taken or it will not clip at all.
If you are using someone else's compiled code then you have to pray
they were merciful.
There was an hacker's rule of thumb in numerical s/w -- about 2/3 of
the code deals with overflow and underflow.
One proposed solution was to abandon regular FP numbers and use a kind
of number that had a bigger range using interated logarithms.
(I.e. the exponent doesnt represent a binary exponent but the number of
times the original number was put through log2(x)).
But -- hard to believe :) -- the idea didnt catch on and the IEEE won!
Sometimes it can also be a matter of changing your "x86" hardware from
AMD to intel or vice-versa. What with pipelines and gpus not being
very well standardised some wintox exe "works" on one kind of HW and
randomly gives garbage answers on another kind.