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