I have a project that stores money as bigint column in a database (storing in cents). I'm planning to rewrite this thing to use BCMATH instead. I don't mind integers, but they give me some terrible rounding errors event stored in cents and I suspect I might have the same rounding errors in BCMATH. The problem arises in situations, like in this pseudocode:
$price = $some_price_in_cents * $store_price_increase; // second value is a float for final price calculation, so the result might have fractions of a cent
$price_total = $price * $qty;
$discount = // some discount in cents (might have fractions of a cent)
$discount *= $qty;
$discounted_price = $price_total - $discount;
When inserting into a database, I do round() on all values in cents. And now I have a record which says:
total price = 12134
discount = 460
discounted price = 11675
Now if I do 12134 - 460 ... I obviously get 11674 and not 11675.
I also suspect that if I changed the way things are calculated (eg. multiply everything by the QTY at the end), I'd get even different results.
Would I get this kind of behaviour using BCMATH? Would the result depend on the order of math operations? How would I properly calculate the above using BCMATH and store it in DB (assuming 2 decimal places are required)?
I believe this is what you need. Note that bcmath requires strings. The number 2 is to specify how many decimals you need.
$price = bcmul($some_price_in_cents, $store_price_increase, 2);
$price_total = bcmul($price, $qty, 2);
$discount = bcmul($qty, "discount amount", 2);
$discounted_price = bcsub($price_total, $discount, 2);
Related
In Woocommerce settings, I have set 6 decimals in order to get more accurate tax calculation. However, I need all prices and amounts to be displayed with only 2 decimals in frontend, emails etc. I found two functions
add_filter('wc_price_args', 'custom_decimals_price_args', 10, 1);
function custom_decimals_price_args($args) {
$args['decimals'] = 2;
return $args;
}
add_filter( 'wc_get_price_decimals', 'change_prices_decimals', 20, 1 );
function change_prices_decimals( $decimals ){
$decimals = 2;
return $decimals;
}
What is the difference between these and which one should I use?
Note that WC_ROUNDING_PRECISION constant is set to 6 in WC_Woocommerce define_constants() method.
That means that WooCommerce Tax calculation precision is already set on 6 decimals.
Tax calculation precision are based on wc_get_rounding_precision() core function used in WC_Tax Class:
function wc_get_rounding_precision() {
$precision = wc_get_price_decimals() + 2;
if ( absint( WC_ROUNDING_PRECISION ) > $precision ) {
$precision = absint( WC_ROUNDING_PRECISION );
}
return $precision;
}
As you can see WC_ROUNDING_PRECISION constant is prioritized if the displayed price decimal value + 2 is smaller than WC_ROUNDING_PRECISION constant. But as you want to keep displayed prices with 2 decimals, this requires something else.
So you should not increase displayed price decimals and not use wc_price_args or/and wc_get_price_decimals hooks, to increase precision in tax calculation.
If precision of 6 decimals is not enough and you want to get more precision:
How to get more precision on Tax calculations?
The best way to get more precision on tax calculations and keep displayed prices with 2 decimals is to edit WordPress wp_config.php file and add the following lines (where you can increase WC_ROUNDING_PRECISION constant value as you like, here the value is set to 8 for example):
// Change WooCommerce rounding precision
define('WC_ROUNDING_PRECISION', 8);
This will change WC_ROUNDING_PRECISION constant without affecting displayed price decimals.
wc_price_args is used to add extra arguments to the price - it takes in raw price and it can add other stuff to it like for example a currency symbol. When get_price is called it will include this currency symbol in the front end.
https://wp-kama.com/plugin/woocommerce/hook/wc_price_args
wc_get_price_decimals it sets a number of decimals after the 'point' - eg. if you set it to 5, the price will look like 0.00000
https://wp-kama.com/plugin/woocommerce/function/wc_get_price_decimals
I didn't test this but it should do the job.
add_filter('wc_price_args', 'custom_decimals_price_args', 10, 1);
function custom_decimals_price_args($price, $args) {
return number_format((float)$price, 2, '.', '');
}
Alternatively, you can edit the template where your products are and format the get_price with the number_format above.
Let me know if this worked for you.
I have a nasty bug with payments in Magento, Paybox and SOAP web services, the idea is the following:
Payment is made in cents $36.37 = 3637cents (Paybox - API)
What I am trying to do is to transform my order price in cents in the following way:
$cents = $order->getBaseGrandTotal() * 100;
Also I have a web service SOAP (strict types) that respond this $cents amount but it concerts it to (int), then the magic happens sometimes the converted amount is not the expected one, the converted result is less than an cent, in my case it could be 3736.
$prices = array(39.8699, 12.3299, 11.3211);
foreach ($prices as $price) {
$stuff = round($price, 2) * 100;
echo $stuff . PHP_EOL;
}
echo "After int conversion" . PHP_EOL;
foreach ($prices as $price) {
$stuff = (int) (round($price, 2) * 100);
echo $stuff . PHP_EOL;
}
The result is the following:
3987
1233
1132
After int conversion
3986
1233
1132
Question
Is there a way to fix this bug, it seems to be a php bug ?
Your algorithm summarises as this:
$price = 39.8699; // 39.869900000000001228
round($price, 2) * 100; // 3986.9999999999995453
(int)3986.9999999999995453; // 3986
You're rounding properly everywhere, except in the last step, where your (int) casting truncates. Rounding would be more appropriate:
round($price * 100)
Said that, the root problem is that computers use binary logic and normally store numbers as base 2, while us humans use fuzzy logic and prefer base 10. There isn't much problem with "small" integers because there's a 1 to 1 correspondence but storing arbitrary base 10 floating points numbers in a fixed-sized base 2 representation is normally just an approximation. A classical example is 1.1 which has two digits in base 10 but is periodic in base 2:
1.0001100110011001100110011001100110011001100110011001100110011001101...
That's why common advice includes using exact data types when available (DECIMAL in your relational database, integers in your client code).
I've got a significant problem in working out the percentage tax applied to a product, due to the rounding.
For example:
If you have a product which is £1.00 including 20% tax the break down would be:
0.83 ex tax
0.17 tax
1.00 total
However, if you work out the percentage increase:
round( (( ( 1 - 0.83 ) / 0.83 ) * 100), 2);
The answer is 20.48, because the actual price ex VAT is 0.8333333333
Therefore if you calculate:
round( (( ( 1 - 0.8333333333 ) /0.8333333333 ) * 100), 2);
You get the correct answer of 20.
In this case it would obviously work to round the 20.48 down to 20, but thats not a solution because some tax rates are to 2 decimal places so the assumption can't be made that you can just round the tax rate.
Am I missing something or is this impossible without knowing the original tax percentage?
0.17 is not 20% of 0.83, so your basic assumption is inaccurate( is rounded :P ).
Don't round money, calculate it without all that rounding and display rounded if need be. That avoids having to loose the precision in calculations.
A simple test will demonstrate
$price=0.8333333333;
$taxRate=21.25;
$tax=$price*$taxRate/100;
$total=$price+$tax;
$calculatedTaxRate=(($total-$price)/$price)*100; // 21.25
Since we didn't round anywhere, we can reverse engineer the tax rate always down to the dot.
Try with 20%
$price=0.8333333333;
$taxRate=20;
$tax=$price*$taxRate/100;
$total=$price+$tax;
$calculatedTaxRate=(($total-$price)/$price)*100; // 20
Wouldn't it something like:
17% VAT
85.47 taxless
85.47x0.17 = 14.53
Total: 100
So 100/1.17 = 85.47
My little-and-dirty version:
$taxrate=22; // 22%
$price=100;
$priceMinusTax=($price/(($taxrate/100)+1));
As long as you are dealing with low precision numbers, you will get a low precision answer. If you must show low precision numbers, you can round them when you show them to the user in the view, but save them as high precision numbers in the database.
Assuming your total price is £1 and tax rate is 20%:
$vatDecimal = (float) 1 + (20 / 100);
$priceExclVAT = round((1.00 / $vatDecimal), 2);
$priceDisplay = number_format($priceExclVAT, 2, ',', '.');
echo $priceDisplay;
The user enters the total amount and tax. Sometime its come form database, we can also use this code.
$actualPrice = "";
$total = 1000;//User Entry Total Amount
$gst = 18;//User Entry GST Tax %
$calculateTax = 100+$gst;
$calculateAmount = $total*100;
$actualPrice = $calculateAmount/$calculateTax;
echo $actualPrice = round($actualPrice,2);
echo $gstAmount = round($total-$actualPrice,2);
Not sure if I'm being stupid here. Probably something obvious but when you've been staring at the same issue for hours on end it starts to drive you crazy.
I'm doing a few calcuations using PHP, all fairly straight forward.
I have a table called sales, say:
total, costs
424.53, 125
853.91, 125
To get the data I need...
gross = total - cost
vat = gross - ( gross / 1.2 )
profit = gross - vat
I need to generate a report, so for each row in the sales database I need to loop over and run the above calculations to get the data I need.
If I add the sum of total and the sum of costs, and then work out the gross, vat and profit above, and round vat and profit to 2 decimal plates the values are as expected.
The problem I'm having is where I'm looping over each row and calculating gross, vat and profit. If I don't round vat and profit on each row, but round the final totals, they match the values where I add sum(total) and sum(costs).
But then in the report I generate, if I don't round vat and profit then they don't show to two decimal places, which I need.
Actual code is below, pretty sure it's more of a logic issue than code.
$sum = 0; // Test variable
foreach( .. as ... )
{
// Assigning $total and $cost
$gross = $total - $cost;
$data['profit'] = $gross;
// If I round this VAT so vat shows to two decimal points, $sum becomes off by some pence.
// If I don't round it but then round $sum after the loop, it matches the echo statement value which is the correct amount
$vat = $this->vat( $gross );
$data['vat'] = $vat;
$profit = $gross - $vat;
$data['net_profit'] = $profit;
$sum += $profit;
$array[] = $data;
}
echo "131547.82<br><br>";
echo $sum;
die;
It's an accuracy problem caused by using floats.
When you do calculations with pure PHP you need to be careful.
You may run into glitches, when comparing two floats.
I would suggest to use some helper function or a currency / money object in order to work with them. It might be better to use a PHP Extension for math stuff, like the PHP Extensions BCMath, which has for instance the function bcadd(). Anyway, here are some helpers, which you might use in your calculation loop.
/**
* turn "string float" into "rounded float with precision 2"
* (string) 123,19124124 = (float) 123.19
*
* #param type $string
*/
function formatNumber($string, $precision = 2)
{
return round((float) str_replace(',', '.', $string), $precision);
}
There is also sprintf: echo sprintf("%.2f", $a);.
These two are based on PHP's NumberFormatter from the Intl Extension.
// 123,19 EUR = 123.19
function parseNumber($string_number)
{
$fmt = numfmt_create('de_DE', \NumberFormatter::DECIMAL);
return numfmt_parse($fmt, $string_number);
}
// 123.19 = 123,19 EUR
function numberFormat($value)
{
$f = \NumberFormatter::create("de_DE", \NumberFormatter::CURRENCY);
return $f->formatCurrency($value, 'EUR');
}
For comparing two floats:
/**
* Do not check, that the numbers are exactly the same,
* but check that their difference is very small!
* A really small rounding error margin (epsilon) is expected.
* It's an equals check within defined precision.
*/
function compareFloats($a, $b)
{
return (abs(($a - $b) / $b) < 0.000001) ? true : false;
}
What I do
I am making graph of fictitious stock options.
The price is updated each second, with this function
function stockVariation($price,$max_up,$max_down)
{
// Price > 1
if($price > 1)
{
// Calculate
$ratio=(mt_rand(0,$max_up/2)-mt_rand(0,$max_down/2))/1000;
$price+=$ratio;
}
// Price <=1 (we don't want 0 or negative price...)
else
$price+=mt_rand(1,$max_up)/1000;
return round($price,3);
}
I use a max_up and max_down values (from 10 to 100) to make the price change progressively and simulate some volatility.
For example, with max_up : 40 and max_down : 45, the price will progressively go down.
My question
But the problem, is that prices generated are too much volatile, even if max_up = max_down.
The result is "non-natural". (for example +10 points in one day for a base price of 15,000).
Result of price evolution per hour in 24 hour
Perhaps making round($price,4) and divisions by 10 000 instead of 1 000, will be better ?
If anyone have an idea or an advice to generate "natural" prices evolution, thanks in advance.
There are 86400 seconds in a day, so you'll need to divide by a much larger number. And rather than adding and subtracting, you may want to multiply the current price by a factor that's slightly larger or smaller than 1. That would simulate a percentage increase or decrease, rather than an absolute gain or loss.
function stockVariation($price, $max_up, $max_down)
{
// Convert up/down to fractions of the current price.
// These will be very small positive numbers.
$random_up = mt_rand(0, $max_up) / $price;
$random_down = mt_rand(0, $max_down) / $price;
// Increase the price based on $max_up and decrease based on $max_down.
// This calculates the daily change that would result, which is slightly
// larger or smaller than 1.
$daily_change = (1 + $random_up) / (1 + $random_down);
// Since we're calling this function every second, we need to convert
// from change-per-day to change-per-second. This will make only a
// tiny change to $price.
$price = $price * $daily_change / 86400;
return round($price, 3);
}
Building upon the idea, you could use an actual volatility number. If you want e.g. a volatility of 35%/year, you can find the volatility per second. In pseudocode:
vol_yr = 0.35
vol_month = vol_yr * sqrt(1.0/12)
vol_second = vol_yr * sqrt(1.0/(252 * 86400)) # or 365 * 86400
Then, every second, you "flip a coin" and either multiply or divide current stock price by (1 + vol_second). This is the principle of how binomial trees are created to evaluate exotic stock options.