Re: ✘gpsd .23.2~rc1

[Fred Wright]

On Wed, 13 Apr 2022, Gary E. Miller wrote:

> That log is your HPPOSLLH issue.  I have a working fix for that too, but
> not tonight.

Thatt collides with what I was doing, as well as being slightly wrong, and 
now I have to do more work to sort it out.

The general concept is the same as my change, i.e. combining the two 
pieces as integers before a single conversion to FP.  But:

1) You're defining the multiplier as 100L, when it should be 100LL.  With 
100L on a 32-bit platform, it will compute the combined integer in 32 bits 
and potentially overflow it.  100LL forces 64 bits in all cases, which is 
guaranteed to accommodate any value the receiver can report.  It's of 
course a don't-care on 64-bit platforms.

2) I'm not sure whether casting the constant to double actually matters in 
this context, but it certainly doesn't hurt, so it might as well be there.

3) Changing the scaling from multiplication to division simply slows it 
down without improving the accuracy.  It's tempting to think that the 
division approach is more accurate since the constant can be represented 
exactly, but ultimately there needs to be a division by a power of 10 at 
some point either way, with the only difference being whether it does that 
at compile time in computing the constant, or at run time.  The latter is 
more expensive, and not likely to be more accurate unless the compiler is 
screwing up computing the constant in the former case.


I already created a macro for the computation instead of repeating the 
same thing a zillion times.  Now I think I'll pull the scale factor into 
it for the cast.

Fred Wright