Re: [gpsd-dev] test_nmea2000 fail on some AIS frames

[Greg Troxel]

"address@hidden" <address@hidden> writes:

> 1.) I only see the problen on Intel 32 bit machine, i do not see it on
> ARM (i have only 32 bit machines) and PowerPC 64 or 32 bit machines.

Intel is typical for having extended precision relative to IEE754
requirements (but this is not wrong).

> 2.) The "wrong" values have an offset of 1 bit, so this is a rounding
> problem.

Or the test is overly picky.  Can you really say that the result is
wrong?  I don't know how to interpret ' "wrong" '.

> 3.) I can fix it by forcing the constant, that i use to scale the
> integer taken from nmea2000 datastream, to be a double (use .06L
> instead of .06)
>
> I prefer to do this, but ask: Is the minimal increase in precision on
> one platform worth the performance penalty?

How much floating point is in use anyway?   If gpsd is already using
doubles all over the place, it wouldn't seem to hurt.

It might be nice to have helper functions to check if floats/whatever
are close to the expected value in regression tests; in general
expecting an exact bit pattern makes tests a bit twitchy.

In addition, it's theoretically possible that gpsd would run on a
POSIX/C99 system with other than IEEE754 floating point, if someone
dusts off their VAX.  But that's most theoretic and of interest to
retrocomputing types.

pgpGUbe221SpI.pgp
Description: PGP signature