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

Switch to BCMath #555

Closed
CodeMonkey90 opened this issue Apr 19, 2014 · 3 comments
Closed

Switch to BCMath #555

CodeMonkey90 opened this issue Apr 19, 2014 · 3 comments
Assignees

Comments

@CodeMonkey90
Copy link

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.

@choukalos
Copy link

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.

@CodeMonkey90
Copy link
Author

@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.

This was referenced Dec 24, 2014
magento-team pushed a commit that referenced this issue Aug 28, 2015
[GoInc] GitHub and Merchant Beta issues fixes
magento-team pushed a commit that referenced this issue Apr 20, 2016
@czettnersandor
Copy link

czettnersandor commented Dec 7, 2016

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:

$amount += intval((string) ($price * 100)) / 100;

This not for certain values:

floor($price * 100) / 100;

okorshenko pushed a commit that referenced this issue Dec 14, 2016
[Dragons] MAGETWO-60348: Remove api annotation - 2.1
magento-devops-reposync-svc pushed a commit that referenced this issue Sep 8, 2023
ACPT-1480: Implement _resetState for classes found by GraphQlB2BStateTest
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants