Re: [gpsd-dev] [PATCH 3/3] Print offset in ntpshmmon instead of reference time

[Gary E. Miller]

Yo Miroslav!

On Wed, 13 May 2015 10:47:55 +0200
Miroslav Lichvar <address@hidden> wrote:

> On Thu, May 07, 2015 at 03:02:03PM -0700, Gary E. Miller wrote:
> > My mistake, Python floats are only 52 bits of precision:
> > 
> > http://stackoverflow.com/questions/8216088/how-to-check-the-size-of-a-float-in-python
> 
> That probably prints the number of bits stored in memory, without the
> implicit leading bit. It should be the same format as double in C.

Yes it is the same as a C double.

> > Run this program:
> > 
> > d = float("1431035819.123456789");
> > print("{0:.9f}".format(d))
> > 
> > 
> > And you get:
> > 
> > 1431035819.123456717
> > 
> > Not acceptable.
> 
> Why not? I'd prefer a solution where no information is lost too, but
> in this case I don't think it really matters.

But it does matter.  Those last bits of precision had real information
in them.  

If you prefer better, why do you argue for less, when better is so easy?

> When the clock is
> synchronized, the offset should be close to zero. When the clock is 45
> years off as in your example, I don't really care about nanoseconds,
> I'm wondering why is it off by 45 years. :)

Think RasPi that has no battery backed clock.  The faster we get ultimate
precision the faster the clock can converge.  Think PTP where the
nanoSec clock in the ethernet card is based on power on time, not UTC.

Once again, if better is so easy, why fight it?

> Also, pystripchart seems to handle the data internally as floats, so
> even if the offset was parsed in a wider format, there would likely be
> no difference in the output. The precision would be just lost slightly
> later in the processing.

NA.  I already fixed pystripchart.

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