Skip to content
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: round ingredient amounts when not using fractions #4470

Merged
merged 2 commits into from
Oct 30, 2024

Conversation

Kuchenpirat
Copy link
Collaborator

@Kuchenpirat Kuchenpirat commented Oct 30, 2024

What type of PR is this?

  • bug

What this PR does / why we need it:

Ingredient amounts were not rounded when Fractions were turned of for that specific unit. This leads to unnecessairy precision described in #4465. This rounds the number to three significant digits.

Resulting in the following output for the 400 / 160 scaled from 6 to 7 in the issue linked above.

467 Testingredient
187 Testingredient

Happy to tune the precision if somebody sees a case where this would not be enough. Couldn't think of one.

Which issue(s) this PR fixes:

Special notes for your reviewer:

I had to do some back and forth casting to between Numbers and Strings to:

  • remove e.g. 1.33e^5 representation returned by toPrecision
  • remove trailing 0 after the comma returned by toPrecision
  • to allow for numbers that are greater than 3 digits after scaling (e.g. 1600ml of Water)

If there is a better method please let me know.

Testing

Manual testing with the example described in #4465

@michael-genson michael-genson merged commit 985b563 into mealie-next Oct 30, 2024
13 checks passed
@michael-genson michael-genson deleted the round-numbers-when-not-using-fractions branch October 30, 2024 15:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[BUG] - Grossly excessive precission with decimal unit scaling
2 participants