Re: [gpsd-dev] Print offset in ntpshmmon?

[Gary E. Miller]

Yo Miroslav!

On Mon, 4 May 2015 09:52:05 +0200
Miroslav Lichvar <address@hidden> wrote:

> On Thu, Apr 30, 2015 at 11:08:31AM -0700, Gary E. Miller wrote:
> > On Thu, 30 Apr 2015 17:27:40 +0200
> > Miroslav Lichvar <address@hidden> wrote:
> > > On Tue, Apr 28, 2015 at 11:59:06AM -0700, Gary E. Miller wrote:
> > > > > > > > -                    offset = (float(record[3]) -
> > > > > > > > float(record[4]))
> > > > > > > > +                    offset = float(record[4])
> > > > > > > 
> > > > > > > Both are pretty bad....
> 
> > > But would be pystripchart able to display the data without losing
> > > precision?
> > 
> > Sure, the offset is the residue of the preccision.
> 
> I meant the precision that would be gained for large offsets by not
> parsing the value as a float. If pystripchart uses floats internally,
> it won't matter if the offset is printed by ntpshmmon and parsed by
> ntpshmviz as a pair of integers.

Which is fine when python upgrades the integers to longs.
 
> > > Offset is normally close to zero. I think printing the offset in
> > > ntpshmmon as a double and parsing it as a float in ntpshmviz
> > > would be fine.
> > 
> > Nope.  The calcuation is being done in double and the nanoSec are
> > lost.
> 
> The change I proposed only prints the offset as a double, the
> substraction of the two timestamps is done with integers.

Are we talking about the same code?  At the top of the thread I see
two floats.

How about you resubmit the patch now that we know more about Python
precisions.

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