davout (OP)
Legendary
Offline
Activity: 1372
Merit: 1007
1davout
|
|
November 19, 2010, 02:41:35 PM |
|
See screenshot, this kind of stuff happens a lot.
|
|
|
|
ShadowOfHarbringer
Legendary
Offline
Activity: 1470
Merit: 1006
Bringing Legendary Har® to you since 1952
|
|
November 19, 2010, 02:52:59 PM |
|
I don't know if mtgox knows or uses this, but PHP has special set of functions for this kind of things - it's called BC_MATH. http://www.php.net/manual/en/book.bc.phpWith it, it is possible to count any number with any needed precision.
|
|
|
|
davout (OP)
Legendary
Offline
Activity: 1372
Merit: 1007
1davout
|
|
November 19, 2010, 02:59:56 PM |
|
Also *never* use float column sql data types, when storing money values decimal is the way to go. Edit : <troll>Also never use PHP</troll>
|
|
|
|
ribuck
Donator
Hero Member
Offline
Activity: 826
Merit: 1060
|
|
November 19, 2010, 03:06:13 PM |
|
<troll>Also never use PHP</troll>
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.
|
|
|
|
ShadowOfHarbringer
Legendary
Offline
Activity: 1470
Merit: 1006
Bringing Legendary Har® to you since 1952
|
|
November 19, 2010, 03:12:35 PM |
|
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.
|
|
|
|
davout (OP)
Legendary
Offline
Activity: 1372
Merit: 1007
1davout
|
|
November 19, 2010, 03:59:06 PM |
|
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 <troll>Also never use PHP</troll>
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. 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.
|
|
|
|
mtgox
|
|
November 19, 2010, 06:07:12 PM |
|
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.
|
|
|
|
ribuck
Donator
Hero Member
Offline
Activity: 826
Merit: 1060
|
|
November 19, 2010, 06:14:08 PM |
|
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.
|
|
|
|
kiba
Legendary
Offline
Activity: 980
Merit: 1020
|
|
November 19, 2010, 06:18:02 PM |
|
Also, can you please automatically calculate the fee?
|
|
|
|
nanotube
|
|
November 19, 2010, 07:47:31 PM |
|
+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.
|
|
|
|
bitcoinex
|
|
November 19, 2010, 09:07:52 PM |
|
+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.
|
New bitcoin lottery: probiwon.com- Moжeт, ты eщё и в Heвидимyю Pyкy Pынкa вepyeшь? - Зaчeм жe вepoвaть в тo, чтo мoжнo нaблюдaть нeпocpeдcтвeннo?
|
|
|
tcatm
|
|
November 19, 2010, 09:13:01 PM |
|
you could limit all prices to 4..6 decimal places.
|
|
|
|
ribuck
Donator
Hero Member
Offline
Activity: 826
Merit: 1060
|
|
November 19, 2010, 09:13:43 PM |
|
are you ready to see the numbers like this:
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?
|
|
|
|
tcatm
|
|
November 19, 2010, 09:18:45 PM |
|
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".
|
|
|
|
bitcoinex
|
|
November 19, 2010, 09:19:45 PM |
|
are you ready to see the numbers like this:
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!
|
New bitcoin lottery: probiwon.com- Moжeт, ты eщё и в Heвидимyю Pyкy Pынкa вepyeшь? - Зaчeм жe вepoвaть в тo, чтo мoжнo нaблюдaть нeпocpeдcтвeннo?
|
|
|
ribuck
Donator
Hero Member
Offline
Activity: 826
Merit: 1060
|
|
November 19, 2010, 10:46:05 PM |
|
Click on "Account History".
Thanks! I see three decimal places for all the calculated values.
|
|
|
|
ShadowOfHarbringer
Legendary
Offline
Activity: 1470
Merit: 1006
Bringing Legendary Har® to you since 1952
|
|
November 20, 2010, 03:51:29 PM |
|
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.
|
|
|
|
ShadowOfHarbringer
Legendary
Offline
Activity: 1470
Merit: 1006
Bringing Legendary Har® to you since 1952
|
|
November 20, 2010, 03:54:07 PM |
|
+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.
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.
|
|
|
|
The Madhatter
|
|
November 20, 2010, 04:25:42 PM |
|
PHP's float precision can be adjusted in the php.ini file too.
|
|
|
|
wumpus
|
|
November 20, 2010, 04:39:11 PM |
|
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.
|
Bitcoin Core developer [PGP] Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through File → Backup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
|
|
|
|