Cheaper In Bitcoins | Explaination of the 0.01 Bitcent anomoly

[Xenland]

Just for the record, I realize that some product pages(usually that include shipping, tax, or sometimes additional options) might come out to 0.01 Bitcent more then what they should looking at initial values; I assure you this is not me trying to swipe 0.01BTC per order, no there is need for that and I assure you this is not a math miscalculation issue either. In fact this is a "rounding anomaly". my websites back-end processes transaction prices using USD units which would cause some rounding anomalies with the decimal limit in comparisons to Bitcoins 8 decimal precision.

Hope this makes sense to anybody whom was wondering about such issues like this......
Thanks

[1713549470]

1713549470

[1713549470]

1713549470

[DeathAndTaxes]

People actually get worried when converted prices are off by 0.01 BTC = 3 pennies?

[Xenland]

Youd be suprised from the other rediculas requests and odd messages i get.... Somedays its entertaining other days its hard to stay professional when your constantly wondering if the person your talking to will start spouting off random sayings. Its comes with running a biz.... I suppose....

[genjix]

It is because you are using floating point numbers.

There are a number of different ways to fix it if you're using PHP.

https://bitcointalk.org/index.php?topic=4086.0

[Xenland]

Thanks for the input but I'm very aware of floating point precision flaws and I think it more has to do with rounding Bitcoins' 8 decimals and compressing them into a common format for everyone which is usually 2 decimals(also aimed at USA so I picked the 2 decimal precision)

Also on top of that all my prices are linked to USD costs not BTC so they are converted on the fly for each display for example

Product "A" costs around $250 so to show the customer the price in BTC value I gotta divide which at the current rate $3.1

$250/$3.1 = 80.645161290323 BTC
(12 decimal precision)

Obviously displaying a 12 decimal precision number will look un-attractive to buyers so I compress it to a common format of 2 decimal places which PHP outputs as

80.65

How ever a "sub-total" is never the "total" cost I have to include shippingcosts and once in a while "tax" so lets look at this example (remember my prices in my database are link in USD format)

Subtotal: $250/$3.1 = 80.645161290323 BTC
Shipping: $20/$3.1 = 6.4516129032258

Subtotal + shipping = $270
Subtotal + shipping = 87.096774193549 BTC

Check

87.096774193549 BTC * $3.1 = 270;
$270 / $3.1 = 87.096774193548 BTC

Compare Values

87.096774193549
87.096774193548

Round 87.096774193548 BTC

87.1 BTC

Notice the extra Bitcent?
even though customers are Paying the same thing as they would be.... it just "looks" more.

[Xenland]

I just noticed that PHP will correctly round my example to 87.1 BTC along with the other one... however this was just an example of what I have found I can't find which product is showing these anomalies to use correct values for the example.. but basically my example should show you wants going on...

[genjix]

I just noticed that PHP will correctly round my example to 87.1 BTC along with the other one... however this was just an example of what I have found I can't find which product is showing these anomalies to use correct values for the example.. but basically my example should show you wants going on...

If you want to clip decimals, a good method to use is:

$foo = "8.91232323234223";
echo bcadd($foo, '0', 5);  // truncates to 5 decimal places

hope that helps.

Also, you should *always* round down and absorb the cost yourself.

[Xenland]

I just noticed that PHP will correctly round my example to 87.1 BTC along with the other one... however this was just an example of what I have found I can't find which product is showing these anomalies to use correct values for the example.. but basically my example should show you wants going on...

If you want to clip decimals, a good method to use is:

$foo = "8.91232323234223";
echo bcadd($foo, '0', 5);  // truncates to 5 decimal places

hope that helps.

Also, you should *always* round down and absorb the cost yourself.

Well there is technically "no cost" |  transactions ultimately do math in USD format then convert to BTC for the total cost to prevent any possible problems with floats that I'm not aware of its just when you compare it to the invoice it looks like things don't add up.

Thanks for suggesting the bcadd() I'll look into that and see if it helps