Topic: consistent number of dp and rounding (Read 887 times)
I use decimal in any calculation involving bitcoins. It should have enough precision to store every bitcoin that will ever exist in nano-satoshis... Hopefully someday we'll need nano-satoshis
For reference, the correct way is to use long-integers to store the number of satoshis, which is 1e-8. That is the smallest "atom" of a Bitcoin, limited artificially by the original design of the network. There should be no rounding unless you're talking about rounding the 9th decimal place as the result of a calculation.
In Armory, my coin2str() function truncates zeros from the right side so that users who only only deal with >= 0.01 BTC units and higher aren't overwhelmed with zero digits. It is my policy that if there is precision down to 8 decimal places, I show it.
It should never be stored as a float or double. Set a constant ONE_BTC=100000000 and then when you want to specify something in Bitcoins, say long(2.5*ONE_BTC). And a coin2str() function to convert from Satoshis back to a pleasant string representation.
In Armory, my coin2str() function truncates zeros from the right side so that users who only only deal with >= 0.01 BTC units and higher aren't overwhelmed with zero digits. It is my policy that if there is precision down to 8 decimal places, I show it.
It should never be stored as a float or double. Set a constant ONE_BTC=100000000 and then when you want to specify something in Bitcoins, say long(2.5*ONE_BTC). And a coin2str() function to convert from Satoshis back to a pleasant string representation.
https://en.bitcoin.it/wiki/Proper_Money_Handling_(JSON-RPC)
tl;dr: standard practice is 8 decimal places, rounded.
tl;dr: standard practice is 8 decimal places, rounded.
I've noticed that various applications use various number of decimal places in their implementations.
The bitcoin-qt client uses eight, which is what I've been following in my development, however some use less. Also, some clients use rounding, some use floor. This lack of consistency makes it difficult to implement a correct check of the expected balance of an address, because sometimes amounts may be slightly off. If I'm requesting to be paid to eight decimal places and a client only pays accurate to two because that's what their client supports, and my value gets rounded down, the customer will be missing .00XXXXXX bitcoin so they technically 'haven't paid'. I know it's only by small amounts, but if I end up using the 'lowest common decimal place' then the rounding errors could get really pathetic.
Can the community please pick a standard and go with it? Have your say here.
I think we should be using eight decimal places, rounded...
The bitcoin-qt client uses eight, which is what I've been following in my development, however some use less. Also, some clients use rounding, some use floor. This lack of consistency makes it difficult to implement a correct check of the expected balance of an address, because sometimes amounts may be slightly off. If I'm requesting to be paid to eight decimal places and a client only pays accurate to two because that's what their client supports, and my value gets rounded down, the customer will be missing .00XXXXXX bitcoin so they technically 'haven't paid'. I know it's only by small amounts, but if I end up using the 'lowest common decimal place' then the rounding errors could get really pathetic.
Can the community please pick a standard and go with it? Have your say here.
I think we should be using eight decimal places, rounded...
Jump to: