or indeed, strings, although that makes computation somewhat harder.
...not in PHP.
Topic: mtgox, please fix your rounding bugs - page 2. (Read 6104 times)
...not in PHP.
Financial programming lesson one: never use floats for money!
If there is no built-in fixed-point decimal type in your language it's best to use large integers.... or indeed, strings, although that makes computation somewhat harder.
If there is no built-in fixed-point decimal type in your language it's best to use large integers.... or indeed, strings, although that makes computation somewhat harder.
A bit more complicated in the exchange software because it uses non-integer multipliers.
It is important that the sum of inflows and outflows accurately matched. But the relation between them can be a tad bit inaccurate.
Financial programming lesson one: never use floats for money!
If there is no built-in fixed-point decimal type in your language it's best to use large integers.... or indeed, strings, although that makes computation somewhat harder.
If there is no built-in fixed-point decimal type in your language it's best to use large integers.... or indeed, strings, although that makes computation somewhat harder.
PHP's float precision can be adjusted in the php.ini file too.
+1 on showing actual balances without rounding.
+1 on pre-calculating the fee that would be charged, and showing it to the user to see before submitting an order.
+1 on pre-calculating the fee that would be charged, and showing it to the user to see before submitting an order.
It's awful. On the set of small transactions rounding error can reach substantial quantities! Trading robots resent!
I agree with all of these suggestions.
Trading should be done with (almost ?) absolute rounding precision, if possible.
Also *never* use float column sql data types, when storing money values decimal is the way to go.
Precisely, i believe that in PHP it may be best to store floats as pure strings, and convert them when necessary. There were some nasty bugs in float-to-float comparisons in PHP, i don't remember if they fixed them all.
You have it wrong, floats are not supposed to be used to store exact values, decimal types are designed for that purpose
No, you have it wrong, because You are talking about databases, not PHP. PHP does not have something like "decimal types" as far as i know.
But PHP has the strings, which can store almost anything with any precision you need.
Click on "Account History".
Thanks! I see three decimal places for all the calculated values. are you ready to see the numbers like this:
12.3234453404553525454656
12.3234453404553525454656
No. MtGox already calculates the transactions to a certain level of precision (I think it might be 4).
It's awful. On the set of small transactions rounding error can reach substantial quantities! Trading robots resent!
Without that, we can't withdraw our entire balance. If it says 80 bitcoins, but rejects our request to withdraw 80 bitcoins, how are we to know that we really need to ask for 79.9775?
Click on "Account History".
are you ready to see the numbers like this:
12.3234453404553525454656
12.3234453404553525454656
No. MtGox already calculates the transactions to a certain level of precision (I think it might be 4). All we want is for our real MtGox balance to be exposed through the interface.
Without that, we can't withdraw our entire balance. If it says 80 bitcoins, but rejects our request to withdraw 80 bitcoins, how are we to know that we really need to ask for 79.9775?
you could limit all prices to 4..6 decimal places.
+1 on showing actual balances without rounding.
are you ready to see the numbers like this:
12.3234453404553525454656
?
In a system that can trade fractional offerings such numbers are always presented. Simple rounding on sending and receiving sides negate it to the fixed-precise and beautiful numbers.
By the way, btcex.com do not use the decimal rounding. We rounding to the smallest possible size of the quantum of currency. Usually it is 0.01 but not always, it can be exotic such as 0.001 or 0.025.
+1 on showing actual balances without rounding.
+1 on pre-calculating the fee that would be charged, and showing it to the user to see before submitting an order.
+1 on pre-calculating the fee that would be charged, and showing it to the user to see before submitting an order.
Also, can you please automatically calculate the fee?
I suppose I should just floor the amount displayed.
No, you should display the actual balance. If the real balance has three digits after the decimal, you should show three digits.
davout: It is just a display issue. You really have something like $11.487 in your account. So just withdraw one penny less. I'm not using floats to store the account balances. I suppose I should just floor the amount displayed.
Also *never* use float column sql data types, when storing money values decimal is the way to go.
Precisely, i believe that in PHP it may be best to store floats as pure strings, and convert them when necessary. There were some nasty bugs in float-to-float comparisons in PHP, i don't remember if they fixed them all.
You have it wrong, floats are not supposed to be used to store exact values, decimal types are designed for that purpose
PHP is inelegant, but it's capable and ubiquitous. A good software engineer can implement great systems with PHP if they need to.
Just as a good math student can compute a block's hash with a pencil and some paper if he needs to.
Anyway, that's absolutely not the point, I respect PHP for what it is, a performant language that's really easy to learn. Personnally I switched for Rails years ago.
Anyway, I think the rounding issues probably would have been the same if coded in RoR without careful design and knowledge of the exact values handling good practices.
Also *never* use float column sql data types, when storing money values decimal is the way to go.
Precisely, i believe that in PHP it may be best to store floats as pure strings, and convert them when necessary. There were some nasty bugs in float-to-float comparisons in PHP, i don't remember if they fixed them all.
Indeed that's a troll. PHP offers all the tools you need to program sound decimal arithmetic.
PHP is inelegant, but it's capable and ubiquitous. A good software engineer can implement great systems with PHP if they need to.
Also *never* use float column sql data types, when storing money values decimal is the way to go.
Edit :Also never use PHP
Edit :
Jump to: