Integer or float used in Bitcoin?

[2112]

Wouldn't a simpler system be to keep it as a 64bit unsigned integer value, increase the number of digits to 12 and put in place a limitation that no tx (or block can involve more than 10.5M BTC (50% of the money supply)?

2^64 = 1.84467E+19

10.5M BTC * 1E12 satoshis of precision per BTC = 1.05E19

You keep everything in bigint math, no need to go to a larger datatype (and thus larger tx size), no implementation issues with floats or decimals.  Simple & easy with the very minor limitation that a valid transaction can't have outputs or inputs valued at more than 10.5M BTC.  The limit is highly unlikely to be anything more than academic because Bitcoin is likely horribly flawed if a single entity has >50% of the money supply.

What I was trying to convey is that it is pretty much immaterial what any cryptocoin does internally. What matters is that such *coin implementation can be integrated into a general financial workflow.

In order to satisfy above it has to be easily representable in various SQL variants, Javascript, Ruby, Microsoft ASPs and .NETs, PHP, etc. Therefore the "just barely fits in a double" is actually a very good choice and a lifesaver for those who program in PHP.

Check out BitFinEx: they had Ruby code & database using binary floating point. When somebody pointed this on the forum they converted to decimal floating point in few days. This was a definite win for them.

The worst that could happen would be that the Bitcoin overtakes all other currencies but is impossible to represent easily and correctly in COBOL. Or maybe that would be the best that could happen?  

[maaku]

Clearly we must be talking about different arithmetic types. I'm talking about arbitrary-precision rational arithmetic of the type provided by mpq_t in the GNU multi-precision library, for which "2/1" + "2/1" = "2/1" * "2/1" = "4/1" (exact rationals with no concept of uncertainty).

It's already needed in Freicoin due to the presence of demurrage--decayed inputs may have sub-satoshi amounts which accumulate and need to be tracked to enable claiming the accumulated satoshis. Take a transaction which has two separate 3-satoshi inputs that have decayed to each be 2.6 satoshis in value and has a 5-satoshi output. A mp-aware implementation would correctly validate the transaction and pass on the remaining 0.2 satoshi to the miner as a fee.

Software implementation is advisable because many details of hardware floating point is implementation-dependent, which will inevitably lead to distinguishing implementations based on what transactions they validate and which they do not (due to differences in rounding, usable precision, bugs, etc.) and hard-forks. If you're doing software math anyway, you might as well do exact arithmetic since it's actually less complicated and efficient libraries exist.

That, and I've already done all the hard work for you in Freicoin (which handles amounts internally as mpq values with infinite precision instead of int64).

BID is trivially simple. It's basically a sign bit, a binary integer exponent, and a binary integer mantissa (value). Serialization is as simple as a few shifts and bitwise operations.

[DeathAndTaxes]

What I was trying to convey is that it is pretty much immaterial what any cryptocoin does internally. What matters is that such *coin implementation can be integrated into a general financial workflow.

Well I agree that it is important that it have high availability and access but I wouldn't go as far as to say "how it is implemented internally is pretty much immaterial".  A larger datatype is going to mean larger tx (and memory, bandwidth, and lifetime storage costs).  Decimal is easy to screw up.  Even if computers don't have a problem with it, in my experience humans make all kinds of subtle bugs dealing with decimal and floating datatypes.   Integer is clean and simple.  

Personally I think this is somewhat academic.  Lets step back and say what is the smallest discrete pricing unit which matters today.  One could say $0.01 USD but honestly I doubt $0.01 is material anymore (more like just inertia carrying it onward).   I think worse case scenario a crypto-coin would be fine even if pricing was limited to a precision of $0.05 USD in value.  Note I am not saying optimal but it wouldn't hinder adoption in any significant manner. If a satoshi is worth even 1/100th of a US cent (2012 purchasing power) then BTC has exploded in popularity and usage.   If 1 satoshi is worth $0.05 USD  then 1 BTC = $5M and th emoney supply is worth $105T USD.  That is more than the combined money supplies of all countries on earth. 

[DeathAndTaxes]

Clearly we must be talking about different arithmetic types. I'm talking about arbitrary-precision rational arithmetic of the type provided by mpq_t in the GNU multi-precision library, for which "2/1" + "2/1" = "2/1" * "2/1" = "4/1" (exact rationals with no concept of uncertainty).

It's already needed in Freicoin due to the presence of demurrage--decayed inputs may have sub-satoshi amounts which accumulate and need to be tracked to enable claiming the accumulated satoshis. Take a transaction which has two separate 3-satoshi inputs that have decayed to each be 2.6 satoshis in value and has a 5-satoshi output. A mp-aware implementation would correctly validate the transaction and pass on the remaining 0.2 satoshi to the miner as a fee.

Software implementation is advisable because many details of hardware floating point is implementation-dependent, which will inevitably lead to distinguishing implementations based on what transactions they validate and which they do not (due to differences in rounding, usable precision, bugs, etc.) and hard-forks. If you're doing software math anyway, you might as well do exact arithmetic since it's actually less complicated and efficient libraries exist.

That, and I've already done all the hard work for you in Freicoin (which handles amounts internally as mpq values with infinite precision instead of int64).

BID is trivially simple. It's basically a sign bit, a binary integer exponent, and a binary integer mantissa (value). Serialization is as simple as a few shifts and bitwise operations.

But in bitcoin's case what is gained by that complexity.  Absolutely nothing.  Could Satoshi have implemented it that way?  Sure although integers are far cleaner and less prone to as you point out hardware implementation issues which could cause a break or fork in the protocol.

So unless we are just doing it for the sake of doing it I don't see BID being used.

[maaku]

This is all hypothetical, the sort of thing that might be on the hard-fork wish list:

As others have mentioned though, there's not really a need until sub-satoshi amounts have any real-world value.

There may be other valid alt-chain uses however (such as colored coins).

[2112]

Clearly we must be talking about different arithmetic types. I'm talking about arbitrary-precision rational arithmetic of the type provided by mpq_t in the GNU multi-precision library, for which "2/1" + "2/1" = "2/1" * "2/1" = "4/1" (exact rationals with no concept of uncertainty).

No, we've been talking about the same thing. You just spent so much time amongst scientists and engineers that you've forgotten how the average folks (e.g. bookkeepers, tradesmen, etc.) do arithmetic.

What I wrote was: 200/100 + 200/100 = 400/100 and 200/100 *  200/100 = 40000/10000. The concept of "un/certainity" is know to most of the people as "in/significant digits". You may have saved yourself some time right now, but you'll pay it all back (and more) when the users will start showing you examples where your mathematically correct arithmetic simply doesn't agree with their textbooks or with the results from the HP-12c.

What is the value of your "exact" arithmetic if it cannot exactly represent many of the solutions to the time value of money problems, e.g. APR is 5%, how much is this per month or per week or per day? Lots of TVM math requires irrational numbers, quite few commonly used calculations (e.g. IRR) don't have closed-form solutions and require iterative approximations. If your software is going to disagree with the HP-12c, your software is going to lose, not the HP-12c.

Does GNU gmp support all the rounding modes routinely used in accounting? I couldn't quickly find them in the documentation. IEEE-754 folks support at least the basic 5.

Edit: Anyway, the advanced quantitative trading software that I've seen used continuous compounding for the TVM calculations. I can't recall the minimum fixed precision that was required; it was either 6 or 8 digits after the decimal point.

Edit2: To avoid any further miscommunication: please try correctly implementing http://speleotrove.com/decimal/telco.html using your chosen representation.

[2112]

Decimal is easy to screw up.  Even if computers don't have a problem with it, in my experience humans make all kinds of subtle bugs dealing with decimal and floating datatypes.   Integer is clean and simple.  

Your experience is very atypical. Of the two problems: keeping track of the scale factor (for binary integer) and keeping track of decimal point; the first is always more error prone. This has been proven statistically over many significant code bases, repeatedly, and in many programming languages.

Personally I think this is somewhat academic.  Lets step back and say what is the smallest discrete pricing unit which matters today.  One could say $0.01 USD but honestly I doubt $0.01 is material anymore (more like just inertia carrying it onward).   I think worse case scenario a crypto-coin would be fine even if pricing was limited to a precision of $0.05 USD in value.  Note I am not saying optimal but it wouldn't hinder adoption in any significant manner. If a satoshi is worth even 1/100th of a US cent (2012 purchasing power) then BTC has exploded in popularity and usage.   If 1 satoshi is worth $0.05 USD  then 1 BTC = $5M and th emoney supply is worth $105T USD.  That is more than the combined money supplies of all countries on earth. 

I don't really disagree with the above; but I know of a different point of view. Many financial trades routinely quote prices with more than 2 fractional digits: 3 - bond prices; 4 - OTC stock prices, wholesale electronic component prices. There is quite a bit of research that more decimal digits makes markets more efficient and collusion more difficult. Advanced trading software pretty much always uses many more than 2.

[notme]

Clearly we must be talking about different arithmetic types. I'm talking about arbitrary-precision rational arithmetic of the type provided by mpq_t in the GNU multi-precision library, for which "2/1" + "2/1" = "2/1" * "2/1" = "4/1" (exact rationals with no concept of uncertainty).

No, we've been talking about the same thing. You just spent so much time amongst scientists and engineers that you've forgotten how the average folks (e.g. bookkeepers, tradesmen, etc.) do arithmetic.

What I wrote was: 200/100 + 200/100 = 400/100 and 200/100 *  200/100 = 40000/10000. The concept of "un/certainity" is know to most of the people as "in/significant digits". You may have saved yourself some time right now, but you'll pay it all back (and more) when the users will start showing you examples where your mathematically correct arithmetic simply doesn't agree with their textbooks or with the results from the HP-12c.

What is the value of your "exact" arithmetic if it cannot exactly represent many of the solutions to the time value of money problems, e.g. APR is 5%, how much is this per month or per week or per day? Lots of TVM math requires irrational numbers, quite few commonly used calculations (e.g. IRR) don't have closed-form solutions and require iterative approximations. If your software is going to disagree with the HP-12c, your software is going to lose, not the HP-12c.

Does GNU gmp support all the rounding modes routinely used in accounting? I couldn't quickly find them in the documentation. IEEE-754 folks support at least the basic 5.

Edit: Anyway, the advanced quantitative trading software that I've seen used continuous compounding for the TVM calculations. I can't recall the minimum fixed precision that was required; it was either 6 or 8 digits after the decimal point.

Edit2: To avoid any further miscommunication: please try correctly implementing http://speleotrove.com/decimal/telco.html using your chosen representation.

In rational math 400/100 = 40000/10000, but nice try.

Also, why the hell would bitcoin need to worry about TVM calculations?  You just take the bitcoin amount, convert it to whatever format you want, and then do your calculations.

[2112]

In rational math 400/100 = 40000/10000, but nice try.

Yeah, I wasn't clear. I was trying to make a distinction between mathematical correctness and ergonomical user-friendliness.

Obviously mathematically all of 2*2 or 2.0*2.00 or 2.00*2.00 (as well as their rational equivalents) are equal. Perhaphs non-obviously to some, but ergonomically there is a great difference. If one represents the results from above as 4, 4.000 & 4.0000; then the number of human-made mistakes or bugs dimishes greatly.

Also, why the hell would bitcoin need to worry about TVM calculations?  You just take the bitcoin amount, convert it to whatever format you want, and then do your calculations.

I kinda agree. The Freicon, rational math and TVM discussion should move to the Alternative Coins subforum.