2112
Legendary
Offline
Activity: 2128
Merit: 1038


December 22, 2012, 11:54:36 PM 

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?







Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.



maaku
Legendary
Offline
Activity: 905
Merit: 1003


December 23, 2012, 01:21:45 AM 

Clearly we must be talking about different arithmetic types. I'm talking about arbitraryprecision rational arithmetic of the type provided by mpq_t in the GNU multiprecision 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 demurragedecayed inputs may have subsatoshi amounts which accumulate and need to be tracked to enable claiming the accumulated satoshis. Take a transaction which has two separate 3satoshi inputs that have decayed to each be 2.6 satoshis in value and has a 5satoshi output. A mpaware 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 implementationdependent, 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 hardforks. 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.

I'm an independent developer working on bitcoincore, making my living off community donations. If you like my work, please consider donating yourself: 13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP



DeathAndTaxes
Donator
Legendary
Offline
Activity: 1218
Merit: 1007
Gerald Davis


December 23, 2012, 01:22:22 AM 

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 cryptocoin 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
Donator
Legendary
Offline
Activity: 1218
Merit: 1007
Gerald Davis


December 23, 2012, 01:25:12 AM 

Clearly we must be talking about different arithmetic types. I'm talking about arbitraryprecision rational arithmetic of the type provided by mpq_t in the GNU multiprecision 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 demurragedecayed inputs may have subsatoshi amounts which accumulate and need to be tracked to enable claiming the accumulated satoshis. Take a transaction which has two separate 3satoshi inputs that have decayed to each be 2.6 satoshis in value and has a 5satoshi output. A mpaware 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 implementationdependent, 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 hardforks. 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
Legendary
Offline
Activity: 905
Merit: 1003


December 23, 2012, 01:29:42 AM 

This is all hypothetical, the sort of thing that might be on the hardfork wish list: As others have mentioned though, there's not really a need until subsatoshi amounts have any realworld value.
There may be other valid altchain uses however (such as colored coins).

I'm an independent developer working on bitcoincore, making my living off community donations. If you like my work, please consider donating yourself: 13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP



2112
Legendary
Offline
Activity: 2128
Merit: 1038


December 23, 2012, 03:18:26 AM Last edit: December 23, 2012, 04:18:29 AM by 2112 

Clearly we must be talking about different arithmetic types. I'm talking about arbitraryprecision rational arithmetic of the type provided by mpq_t in the GNU multiprecision 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 HP12c. 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 closedform solutions and require iterative approximations. If your software is going to disagree with the HP12c, your software is going to lose, not the HP12c. Does GNU gmp support all the rounding modes routinely used in accounting? I couldn't quickly find them in the documentation. IEEE754 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
Legendary
Offline
Activity: 2128
Merit: 1038


December 23, 2012, 04:08:29 AM 

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 cryptocoin 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
Legendary
Offline
Activity: 1904
Merit: 1001


December 23, 2012, 08:29:17 PM 

Clearly we must be talking about different arithmetic types. I'm talking about arbitraryprecision rational arithmetic of the type provided by mpq_t in the GNU multiprecision 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 HP12c. 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 closedform solutions and require iterative approximations. If your software is going to disagree with the HP12c, your software is going to lose, not the HP12c. Does GNU gmp support all the rounding modes routinely used in accounting? I couldn't quickly find them in the documentation. IEEE754 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
Legendary
Offline
Activity: 2128
Merit: 1038


December 23, 2012, 11:13:41 PM 

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 userfriendliness. 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 nonobviously 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 humanmade 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.




