Jim Wilson wrote:
FWIW that doesn't sound like a "good programming practices" sort of function. A quick test before executing division isn't very expensive (no worse than an isnan).
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.
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.
The problem occurs in gc_calc_course_dist() when you have two points that are far enough apart to be significant, but close enough together that the routine has precision problems. I believe the nan get's spit out of a trig function. I'm going to probably have to wait until both kids are sleeping through the night before I've regained enough mental capacity to tackle that one.
Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Cities curt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org
_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
