-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
use f64
(double) over f32
precision in the Parser
#67
Comments
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:
Some datasheets for products on sparkfun.com are showing examples with single precision however (here or here), so 🤷♂️ To handle both |
Good research. Also to be embedded friendly, we can just use |
Ahh right, they mention But if the format is respected, those values should instead be |
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 😅 I do know that rust automagically compiles any programs with f64 numbers on 32bit OS and it works but not sure about embedded systems. |
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. |
f32
over f64
(double) in the Parserf64
(double) over f32
precision in the Parser
Research whether:
f64
accuracy for any of the fields? - Yes, complexity will be lower by just using double precision.f32
andf64
in the parser (a choice that will be given to the user of the crate)? - No, it is not neededTODOs:
Replace all places to use
f64
(double) precision rather than complicating the source code.The text was updated successfully, but these errors were encountered: