[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] PPS and doubles

From: Gary E. Miller
Subject: Re: [gpsd-dev] PPS and doubles
Date: Mon, 2 Feb 2015 15:03:19 -0800

Yo Miroslav!

On Mon, 2 Feb 2015 08:34:33 +0100
Miroslav Lichvar <address@hidden> wrote:

> On Sun, Feb 01, 2015 at 03:01:11PM -0800, Gary E. Miller wrote:
> > +           delay = (drift.clock.tv_sec + drift.clock.tv_nsec /
> > 1e9) - last_fixtime_clock;
> > +           if (0.0 > delay || 1.0 < delay) {
> > 
> > Delay is 53 bits of precision.
> > tv_sec is 32, soon to be 33 bits of precision
> > tv_nsec = 20 bits of precision
> > 
> > So (tv_sec + tv_nsec / 1e9) is 63 bits of precision.
> > 63 bits of precision does not fit in 53 bits of double!
> > 
> > This is why we do not use doubles in PPS land.
> Just curious, what problem exactly did it cause? The delay value is
> used only for the (0.0, 1.0) interval check,

Floating point math is notorious for reporting things like zero as
-0.000000000001.  Skipping a PPS report or two would not have been
fatal, but certainly misleading.  The worst effect is that gpsd_report
goes on to report the result as %.9f which was clearly over specifying
the result by several orders of magnitude.

If we print a result to nanoSec it better really be nanoSec.  Someone
is always checking the PPS math and they get cranky when things do not
add up.

The real problem is when someone sees the imprecise calculation and then
cuts/pastes the code somewhere that it really does matter.  Clearly
that has happened many other places and I am slowly cleaning up other
cases where it matters more.  For example, I just found, and fixed, a json
PPS report that thinking it was reporting nanoSec when it was only a
double (microSec-ish).

It is just too hard for people to decide case by case what precision is
needed.  Worse yet the result of an imprecise computation is then used
later by someone else in a precise computation.

An example is timestamp() which pretends to be nanoSec precise, but then
converts to a double (losing 10 bits of precision) and then used later
in nanoSec computations.

Best to have the simple rule that if PPS is involved always use nanoSec

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]