[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ✘gpsd .23.2~rc1
From: |
Gary E. Miller |
Subject: |
Re: ✘gpsd .23.2~rc1 |
Date: |
Thu, 14 Apr 2022 20:41:29 -0700 |
Yo Fred!
On Thu, 14 Apr 2022 20:26:06 -0700 (PDT)
Fred Wright <fw@fwright.net> wrote:
> > Not worried about "accuracy", worried about portability. I changed
> > it because it broke portability.
>
> Empirically, your version changed several values in the .chk file.
Yup. I'm more worried about portability than about 1mm. No way to
preserve the 1mm and be portable. That is because the length of (long
double) is not standardized.
> It's all very nitpicking except for the
> tests, since it's about rounding a value that's nominally exactly
> halfway between two allowable values in the JSON precision, which is
> less than the uBlox precision.
Yeah, one decimal digit is lost in the JSON. When I see a mm precise
GNSS, that will have to change.
> The whole JSON precision issue needs looking into, but not right now.
Been there, done that:
https://gpsd.io/gpsd-numbers-matter.html
> For example, uBlox NAV-PVT reports altitudes with millimeter
> precision, and NAV_HPPOSLLH provides 10-micron precision. The JSON
> has 100-micron precision, so it's overkill in the standard case and
> deficient in the high-precision case. Not that it's very likely to
> matter in real use cases, since a receiver is hard pressed even to
> deliver millimeter accuracy on a single real-time fix, especially in
> the vertical dimension.
I think you mean hard pressed to deliver 0.01 meter accuracy.
> Also, in spite of your attempts to control FLT_EVAL_METHOD, the
> FLT_VOLATILE hack is still needed. Taking it out caused about a
> dozen errors on nmea-fuzzy-cases in 32-bit OpenBSD, so I put it back.
I tested it on FreeBSD, are they really different?
> It's a complete NOP any time FLT_EVAL_METHOD < 2, anyway.
No, valatile has real costs.
> My version now passes all tests on the 22 platforms I tested, which
> wasn't true of yours.
Can you be more specific on the failing case? I know that volatile is
not needed, but the full fix was not needed on my test case.
And your #if broke one of Hal's old test cases. Older cc do
not define FLT_EVAL_METHOD, your code requires it, thus an errorf.
RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@rellim.com Tel:+1 541 382 8588
Veritas liberabit vos. -- Quid est veritas?
"If you can't measure it, you can't improve it." - Lord Kelvin
pgpAzuWbK5BxH.pgp
Description: OpenPGP digital signature
- Re: ✘gpsd .23.2~rc1, (continued)
- Re: ✘gpsd .23.2~rc1, Gary E. Miller, 2022/04/13
- Re: ✘gpsd .23.2~rc1, Gary E. Miller, 2022/04/13
- Re: ✘gpsd .23.2~rc1, Hal Murray, 2022/04/13
- Re: ✘gpsd .23.2~rc1, Gary E. Miller, 2022/04/13
- Re: ✘gpsd .23.2~rc1, Gary E. Miller, 2022/04/13
- Re: ✘gpsd .23.2~rc1, Fred Wright, 2022/04/13
- Re: ✘gpsd .23.2~rc1, Gary E. Miller, 2022/04/13
- Re: ✘gpsd .23.2~rc1, Fred Wright, 2022/04/14
- Re: ✘gpsd .23.2~rc1, Gary E. Miller, 2022/04/14
- Re: ✘gpsd .23.2~rc1, Fred Wright, 2022/04/14
- Re: ✘gpsd .23.2~rc1,
Gary E. Miller <=
- Re: ✘gpsd .23.2~rc1, Gary E. Miller, 2022/04/09
- Re: ✘gpsd .23.2~rc1, James Browning, 2022/04/09
- Re: ✘gpsd .23.2~rc1, Gary E. Miller, 2022/04/09
- Re: ✘gpsd .23.2~rc1, James Browning, 2022/04/09
- Re: ✘gpsd .23.2~rc1, Gary E. Miller, 2022/04/09
- Re: ✘gpsd .23.2~rc1, Gary E. Miller, 2022/04/09
- Re: ✘gpsd .23.2~rc1, Hal Murray, 2022/04/09
- Re: ✘gpsd .23.2~rc1, Gary E. Miller, 2022/04/09
- Re: ✘gpsd .23.2~rc1, Greg Troxel, 2022/04/09
- Re: ✘gpsd .23.2~rc1, Gary E. Miller, 2022/04/09