-
Notifications
You must be signed in to change notification settings - Fork 9.4k
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
Switch to BCMath #555
Comments
At present our Tax/Price architect does not believe it's worthwhile to switch to BCMath. We use a small delta to prevent the rare occurrence that BCMath protects against. It seems our more significant challenge is identifying where we should round. We spent almost a year working on just that aspect addressing tax rounding issues ( check out the tax engine differences between 1.12 and 1.13.1 ). There's still work to do there but all we're seeing is where to round as the challenge not decimal value representation. Any help on improving our tax/price engine to accommodate rounding for B2B complexities or bulk sales ( typically sold as per lbs or per kg where more than 2 digits of precision is common in pricing ) would be appreciated. |
@choukalos Are you sure BCMath wouldn't solve the issues you're talking about? Because the way you describe them, I think it would. If you calculate all prices and taxes with arbitrary decimal precision and don't even have to think about the errors accumulated in the process (because there are none), there should be no need to round anything anywhere except when displaying the final price. |
[GoInc] GitHub and Merchant Beta issues fixes
I have an issue when implementing a finance extension which would normally require precision floats as the 3rd party system is very picky about it. As BCMath is not a Magento dependency, we can't use it and we have float conversion issues. Now, we are converting to strings, which is not the best solution and bad for my sleep. This works as expected for rounding down to 2 digits:
This not for certain values:
|
[Dragons] MAGETWO-60348: Remove api annotation - 2.1
ACPT-1480: Implement _resetState for classes found by GraphQlB2BStateTest
Currently, Magento uses floats to represent prices internally. This is a very bad design decision, as binary floating point numbers cannot accurately represent decimal values, which means you have to manually correct the resulting loss of precision after complex calculations. This process is error-prone. Fortunately, the BCMath extension, which is enabled by default, provides arbitrary-precision decimal math.
I'd suggest that Magento moves from floating point calculations to BCMath calculations in the long term. Since PHP converts numeric strings to floats automatically when necessary, the code can be slowly migrated on a module-per-module basis.
The text was updated successfully, but these errors were encountered: