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: increased float rounding precision for CRF parser #1369
Fix: increased float rounding precision for CRF parser #1369
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.
LGTM. I added two test cases and fixed the failing tests since I have CRF++ installed on my computer.
Could you just double check the validator I added on the Pydantic model and make sure I'm not missing anything obvious? If I didn't do anything stupid, I'll go ahead and merge after that.
TestIngredient("⅔ cup unsweetened flaked coconut", 0.667, "cup", "coconut", "unsweetened flaked"), | ||
TestIngredient("⅓ cup panko bread crumbs", 0.333, "cup", "panko bread crumbs", ""), | ||
# Small Fraction Tests - PR #1369 | ||
# Reported error is was for 1/8 - new lowest expected threshold is 1/32 | ||
TestIngredient("1/8 cup all-purpose flour", 0.125, "cup", "all-purpose flour", ""), | ||
TestIngredient("1/32 cup all-purpose flour", 0.03125, "cup", "all-purpose flour", ""), |
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.
I've added two test cases that pass on my machine and update the other two to work with the new significant digits we're using now.
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.
Yeah that looks good to me, and the tests make sense so if they're passing I don't see anything wrong with it!
Thanks for the sanity check! 🚀 |
Issue raised in #1358: the CRF parser rounds the float value to the nearest 1/10; this causes issues for smaller fractions. I increased the precision to 3, which is accurate down to increments of 1/32.
I also limited the denominator to a max of 32 to prevent float precision artifacts like 5980780305148019/72057594037927936 (which is really just 1/12).
Full disclosure: I'm having trouble getting the CRF parser running in dev, so I instead emulated the process locally. Since it's all built-in decimal handling it shouldn't matter, but it's worth checking a few test cases in dev before merging (such as the one mentioned in #1358).