use `f64` (double) over `f32` precision in the Parser

[elpiel]

Research whether:

• We need f64 accuracy for any of the fields? - Yes, complexity will be lower by just using double precision.
• If it's really needed, then how we can allow both f32 and f64 in the parser (a choice that will be given to the user of the crate)? - No, it is not needed

TODOs:

Replace all places to use f64 (double) precision rather than complicating the source code.

[clemarescx]

From the first results I could find with a quick DuckDuckGo for "nmea gpgll", both Trimble (don't know them) and Arduino (I know them!) are using double precision in their examples:

• Trimble - NMEA-0183 message: GLL
• GPS NMEA 0183 Messaging Protocol 101
  So I guess that f64 is required, at least for lossless parsing.

Some datasheets for products on sparkfun.com are showing examples with single precision however (here or here), so 🤷‍♂️

To handle both f32 and f64, perhaps other crates like nalgebra or bevy can be an inspiration.

[elpiel]

Good research.
I didn't quite understand where Trimble and Arduino use double precision.
For Trimble they mention mm,mmmm (0-7 digits) for lat/long, so f32 should be sufficient?

Also to be embedded friendly, we can just use f32 exclusively and only if the necessity arises to think of a way to allow a double (f64) precision.

[clemarescx]

For Trimble they mention mm,mmmm (0-7 digits) for lat/long, so f32 should be sufficient?

Ahh right, they mention mm.mmmm in the field meanings, but I referred myself to their example for the latitude and longitude (3953.88008971 and 10506.75318910 respectively), which are bigger than that format.
I copied them in VSCode and tried to assign them to an f32, and clippy immediately gave me the excessive_precision warning.

But if the format is respected, those values should instead be 53.8801 and 06.7532 (if we just keep the minutes), and indeed, both can fit as f32.
As for hardware limitations for embedded systems, I'm afraid I know very little in that domain so I don't know how much precision loss is acceptable.

[elpiel]

Yes, you are right. It does give an error and somehow I thought that these values should fit in a f32 with 7 numbers after the decimal point.

It is 7 digits after the decimal point so f64 should be used. As far as the embedded limitations, people have told me that there is a way to store and use 2 memory addresses and for f64 on 32bit systems. Sadly this is where my experience ends with that solution 😅
This needs more research on how this could be used on embedded systems. When I get back home I can try to run it on my nrf board which has a 32bit microcontroller and see what it does.

I do know that rust automagically compiles any programs with f64 numbers on 32bit OS and it works but not sure about embedded systems.

[elpiel]

Based on the research I did, double (f64) will work on 32bit systems with some performance penalty (probably not that large).

Nonetheless, I will run it on the nrf board I have just to confirm it before updating this issue.
The lat/long makes sense to be double, but we have to double check the other floating numbers in the parsers.

[Owez]

It looks like lat/long are now f64 in main and I can't find anything more for very high precision nmea.

I've checked each thrimble document and they all have varying examples for lat/long; the specification tables with the datatypes they should be typically shows up to 7, but some examples show up to 8 which is odd. There are no other examples with mysterious datatypes going >7.

Other references online seem to typically say nmea is 5 decimal points, with x-blox allowing modifications to up to 7; though I'm a beginner with nmea so there could be more out there.