Re: [gpsd-dev] several messages

[Fred Wright]

On Fri, 22 Jul 2016, Greg Troxel wrote:
> "Gary E. Miller" <address@hidden> writes:
>
> > We aim to have gpsd run on 32 bit and 64 bit systems.  RasPi's, Odroid's
> > and BBB's currently are 32 bit only.
>
> That really shouldn't be an issue.    32-bit CPUs of various kinds have
> implemented both uint64_t and double (the longer of the two normal
> IEEE754 types) for a long time.   The thing to be careful about is to

Yes, as long as it's C99 or later.

> use uint64_t if you want a 64-bit type, and not to assume that that int,

Mostly yes, except that the 64-bit fixed types tend to be "long" on a
64-bit platform and "long long" on a 32-bit platform, so if you want to
use *printf you need a bitness-dependent format string.  I sometimes use
"long long" directly to avoid that.

> long, or any of the basic C types are particular sizes.  This may well
> interact badly with python that tends to provide the native int.

If interacting with Python in binary, anyway.

On Fri, 22 Jul 2016, Gary E. Miller wrote:

> But that is way off in the weeds.  The immediate problem is solely
> in Python.

No, it's not.  In C you may have long double, but it may be no better than
double, anyway.  In Python you only get double, but that's no worse in
terms of what you can count on.  Numpy lets you get long double, but that
still may be no better.

The bottom line is that you need calculations that work properly with
doubles, whether it's C, C++, or Python.

On Fri, 22 Jul 2016, Hal Murray wrote:

>
> address@hidden said:
> > Spherical distances are tricky, and ISTR that GPSD switched distance
> > algorithms at one point.  You almost certainly don't want the simple
> > spherical law-of-cosines formula, since that has awful numerical
> > sensitivities for short distances.
>
> I'd expect distances for nearby points would be simple.
>
> I'm assuming you start with LAT/LON.  Subtract LAT and LON.  LAT converts to
> feet/meters by diameter of the Earth.  LON is similar but gets scaled by cos
> of LAT.

Yes, for *really* short distances you can just use "scaled Pythagoras".
It's not mathematically correct, but the discrepancy approaches zero as
the distance approaches zero.

The spherical law of cosines is mathematically correct (for a sphere,
anyway), but performs terribly for small distances.  This is because
floating point is designed to have good relative accuracy for numbers near
zero, but not when the "information" is contained in small differences
from one (as in cosines of small angles).

The Haversine formula solves this by using an inverted version of the
cosine ("versed sine") which is near zero (and hence plays nicely with
floating point) for small angles.  It's mathematically correct and works
accurately for small angles, but may get bad for certain *large* angle
cases.  See:

        https://en.wikipedia.org/wiki/Haversine_formula

All of the above assume a sphere.  The more complicated Vincenty formula
handles ellipsoidality, but at the expense of being iterative as well as
complicated.  See:

        https://en.wikipedia.org/wiki/Vincenty%27s_formulae

At some point, gpsutils.c switched from Haversine to Vincenty.  And it
doesn't require anything better than doubles.

There's a way to compromise on just the ellipsoidality issue by using a
spherical formula to get the "distance angle" but then using the actual
ellipsoidal radius (which has a non-iterative formula) at the location in
question rather than a constant for the angle to distance conversion.
Very roughly speaking, the error in this approach is proportional to the
product of the distance and the eccentricity.

Fred Wright