Hi,
On Mittwoch, 3. M�rz 2004 19:19, Andy Ross wrote:
> Actually, untrapped division by zero produces a positive or negative
> infinity, not a NaN. The idea of a NaN is that it is never produced
> as the result of an FPU operation involving non-NaN values. This is
> actually a useful feature -- Nasal uses this property to store a
> pointer in a union with a double without fear of confusing the two.
Also inf/inf or 0/0 is NaN I think.
> But I agree -- checking for NaNs after the fact is a little like
> checking for a null pointer. If they're showing up at all, they are a
> the result of a bug. Using isnan() for non-debug situtations is
> probably just going to hide problems.
I agree, at least to some degree.
Sometimes it might be a good idea to check the values you get from a submodule
you are not maintainer of and you propably don't understand completly.
Instead of just have an hanging application because of such a NaN, it will be
better to check, print a message who to bug for that and exit.
BTW: I also think that the isfinite() call might be a an alternative to
consider.
Greetings
Mathias
--
Mathias Fr�hlich, email: [EMAIL PROTECTED]
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
