-
Notifications
You must be signed in to change notification settings - Fork 2
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
fix!: don't round abundance #276
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Simple fix, I wonder though, with my mind in the parameterisation state, whether we should set significant digits to be an option to functions that is configurable (both via a default configuration file and via the WebUI)?
Something to consider for subsequent work.
@ns-rse Don't know how this ended up as a draft PR the first time, but things are ready to merge now! Then I just need to remember to make that changelog and 1.2.0 release! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will four decimal places for the percentages and other numbers be sufficient?
I often think its better to give people really precise numbers and let them then round up as they see fit rather than having to go round in circles giving greater precision each time its requested (ties in with making it configurable).
Aside from that question, good to go.
@ns-rse I asked the same of @smesnage , if we should just not round anything (so there is never information lost) but he seems keen on keeping the 1 digit for ppm and 2 for retention time at the moment. It's probably a nice thing to put in any issue regarding the rounding. I think the "best solution" would be being able to pick between CSV of Excel output — then we could apply formatting (like visual rounding, but behind the scenes all digits are kept) to these columns, and the CSV could remain all raw, unrounded data. But that's a lot of code changes to be made, and it's probably lower priority than the integration of the fragmenter / mass-calc via WASM (as I understand)! |
Closes #274