On Wed, 2009-04-22 at 19:57 -0400, Patrice Poly wrote:
> Le Wednesday 22 April 2009 19:20:54 Martin Spott, vous avez écrit :
> > Curtis Olson wrote:
> > > I'm seeing a ton of these nan's when I start at KHAF ... it's just one or
> > > two or three per frame, but that ends up spewing an awful lot of extra
> > > text to my console.
> >
> > That's weird, at least using the ASK 21 I don't see a single one - on
> > Linux/AMD64 with GCC-4.3.2,
> >
> > Martin.
>
> Here on OpenSuse 11.0, 64 bits , core2quad, and GCC 4.3.1, I don't have a
> single one, with any plane, anywhere.
I don't have nans here, either. Debian stable, GCC 4.2.3 (Debian
4.2.3-5). Only tried a couple of airplanes (c172p and DA20) and a
couple of airports (KHAF, KHIF)
> I suspect the Nans to have the following probable origins:
>
> **get_elevation_m doesn't hit the ground at all, ( but then its said to
> return
> the sea level )
>
> **a division by zero occurs somewhere here:
The calls to asin() look pretty scary to me. Could we move all the math
outside the call and make sure the math never adds up to more than +/-1?
asin returns NaN if the input isn't in the valid range for a sine.
We could also check for a NaN out of the asin calls and do something
creative if it returns NaN...
> for (int i = 0; i <= 4; i++)
> {
> probe_lat_rad[i] =
> asin(sin(deg2rad*user_latitude_deg)*cos(dist_probe_m[i]/earth_rad_m)
> +cos(deg2rad*user_latitude_deg)*sin(dist_probe_m[i]/earth_rad_m)*cos(ground_wind_from_rad));
The formula above, I believe, is theoretically capable of only reaching
+/- 1.0. So it is probably safe.
> if (probe_lat_rad[i] == 0.0) {
> probe_lon_rad[i] = (deg2rad*user_latitude_deg); //
> probe on a pole
> }
> else {
> probe_lon_rad[i] =
> fmod((deg2rad*user_longitude_deg+asin(sin(ground_wind_from_rad)
>
> *sin(dist_probe_m[i]/earth_rad_m)/cos(probe_lon_rad[i]))+PI)
> ,(2.0*PI))-PI;
Anytime sin(ground_wind_from_rad)*sin(dist_probe_m[i]/earth_rad_m) is
greater than cos(probe_lon_rad[i]) the line above will return a NaN.
Can this condition happen?
> }
> probe_lat_deg[i]= rad2deg*probe_lat_rad[i];
> probe_lon_deg[i]= rad2deg*probe_lon_rad[i];
> }
>
> but I thought checking for poles would prevent this ?
>
> ** divisions by zero here ?
>
> slope[0] = (probe_elev_m[0] - probe_elev_m[1]) / dist_probe_m[1];
> slope[1] = (probe_elev_m[1] - probe_elev_m[2]) / dist_probe_m[2];
> slope[2] = (probe_elev_m[2] - probe_elev_m[3]) / dist_probe_m[3];
> slope[3] = (probe_elev_m[4] - probe_elev_m[0]) / -dist_probe_m[4];
>
> unlikely, as these are initialized with good, positive values
>
> ** division by zero again ?
>
> else
> {
> agl_factor = exp(-(2 + 2 * probe_elev_m[0] / 4000) *
> (user_altitude_agl_m - BOUNDARY2_m) /
> max(probe_elev_m[0],200.0));
> }
>
> I'm a bit at lost for now, as I really don't see any NaN anymore here, and
> don't have another platform to test on.
>
> I would be interested to see on which platforms / configuration this happens,
> maybe when more feedback comes in ??
------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
