Re: [gpsd-dev] ✘CEP(50) 0.285 metersMime-Version: 1.0

[Gary E. Miller]

Yo Fred!

On Fri, 22 Jul 2016 15:59:35 -0700 (PDT)
Fred Wright <address@hidden> wrote:

> On Fri, 22 Jul 2016, Gary E. Miller wrote:
> > On Fri, 22 Jul 2016 15:11:37 -0700 (PDT)
> > Fred Wright <address@hidden> wrote:
> >  
> > > On Fri, 22 Jul 2016, Hal Murray wrote:  
> > > > address@hidden said:  
> > > > > Yeah, been there done that, not what I need.  I need to FORCE
> > > > > what I need, not just hope for "usually".  
> > > >
> > > > If you are working with LAT/LON, they have a known range.  You
> > > > can convert to long/bignum with manual scaling.  
> > >
> > > And note that long double is the same as double on ARM.  
> >
> > Gack...  So much for standards.  
> 
> Well, there is no real "standard" for long double,

IETF Standard 754-2008 "quad precision" : 128 bits

Wikipedia says of C99:

    https://en.wikipedia.org/wiki/C99#IEEE.C2.A0754_floating_point_support

    "long double is defined as IEEE 754 extended precision (e.g., Intel
    80-bit double extended precision on x86 or x86-64 platforms), or
    some form of quad precision where available; otherwise, it is double
    precision."

Look in C99 Annex F.

Not relevant, since gpsprof is in Python, which has no standards...

> But note that the circumference of the Earth is ~4E7m, or ~4E10mm,
> which is still comfortable in the 52-bit mantissa of a double.

Yeah, but then gpsprof calculates spherical distances.  Lot's of
squaring and square rooting.  So, double is probably good enough, but
somewhere I'm losing enough precision to mess up my plots.

The numbers seems to come and go.  One plot almost looks right and the
next gives me all zeros. Until I nail down the problem I'm suspecting
everything.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  Tel:+1 541 382 8588

pgpMVeyznNkZm.pgp
Description: OpenPGP digital signature