Bitcoin Forum
December 06, 2016, 04:05:29 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2]  All
  Print  
Author Topic: 21million BTC is just over 51 bits of precision...  (Read 4075 times)
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
January 30, 2011, 07:04:49 PM
 #21

Problem is, "TBC" is your own invention, no matter how many times you repeat it.
No problem at all. TBC is an adaptation of the BitCoin currency to the Tonal number system, in the same way as a port of software is an adaptation to a new platform. The only problem is when people work against innovation and progress.

Every time a block is mined, a certain amount of BTC (called the subsidy) is created out of thin air and given to the miner. The subsidy halves every four years and will reach 0 in about 130 years.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
0x6763
Guest

February 07, 2011, 08:00:16 PM
 #22

Floating point is not good for dealing with money.

Subtracting two Doubles on the JVM:
Code:
user> (- 0.8846 0.8524)
0.032200000000000006

Subtracting two Floats on the JVM:
Code:
user> (- (float 0.8846) (float 0.8524))
0.03219998

Neither operation got the accurate answer of 0.0322.

Why floating point is being considered at all is a mystery to me.
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
February 07, 2011, 08:40:11 PM
 #23

Why floating point is being considered at all is a mystery to me.

Huh?  Nobody is suggesting that any math be done with floating-point coins.

But even if we were, your first example gives the correct result to the 8-places-of-precision that Bitcoin deals with:
 (round 0.032200000000000006  to 8 places and you get 0.03220000)

How often do you get the chance to work on a potentially world-changing project?
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
February 07, 2011, 11:20:57 PM
 #24

Floating point is not good for dealing with money.

Subtracting two Doubles on the JVM:
Code:
user> (- 0.8846 0.8524)
0.032200000000000006

Subtracting two Floats on the JVM:
Code:
user> (- (float 0.8846) (float 0.8524))
0.03219998

Neither operation got the accurate answer of 0.0322.

Why floating point is being considered at all is a mystery to me.
Those are problems with decimal fractions in floats. Tonal fractions have no such problem, nor do integer values (which I was recommending). A floating-point implementation that cannot handle all possible BitCoin values as integers, is a buggy implementation. Wink

0x6763
Guest

February 08, 2011, 03:18:11 AM
 #25

Perhaps my examples are not the best, and admittedly this is outside of my area of expertise, but my main concern is that I think it goes against best practices to use floating point numbers for money.  Perhaps this is not an issue with the bitcoin client, I don't know.  Using floating point numbers still doesn't sound like a good idea to me, though.
genjix
Legendary
*
expert
Offline Offline

Activity: 1232


View Profile
February 08, 2011, 10:31:38 PM
 #26

If it's just the JSON api then why not fix it when it becomes a problem? Upgrading an API to a new one is not a problem as much as upgrading a protocol.

The real question is whether the precision should be made larger from int64 to int128

I'm sure the inventors of the internet didn't guess that ipv4 addresses would become exhausted. It's not a big deal to double the precision and much easier to change now than in the future.
jon_smark
Member
**
Offline Offline

Activity: 90


View Profile
February 08, 2011, 11:20:24 PM
 #27

Why does this discussion have to made over and over again?  Over the ages countless people have been burned by the practice of storing currency values in floating point, which is why nowadays it is conventional wisdom that any application handling money should never, ever use floating point types to store currency. You may think you are saving some space, or being more "efficient", or that you have enough precision, or whatever.  Resist the temptation, seriously. Just say NO!  If you don't, sooner or later that decision will come back to bite you in the ass.

Ever wonder why DBMSs have these awkward looking "numeric" types (sometimes also called "decimal"), where you explicitly specify the precision and the number of decimal places?  It's not because the DBMS people don't know of floating point.  Quite on the contrary.  They know floating point all too well, which is why they don't use it for currency.
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
February 09, 2011, 02:24:25 AM
 #28

If it's just the JSON api then why not fix it when it becomes a problem? Upgrading an API to a new one is not a problem as much as upgrading a protocol.
It is a problem now.

The real question is whether the precision should be made larger from int64 to int128
It is technically impossible for more than 21 million bitcoins to ever exist. int64 holds the entire quantity of base units. int128 makes no sense on a technical level. Besides, JSON only has "numbers", not int-sizes or floats. Buggy JSON implementations might try to read number-without-a-decimal-point as an int32, which is why the JSON API should require a ".0" after every number. Base units should be used because 1) valid JSON implementations might try making an imprecise float (all are, for 0.1) even when precision is needed, 2) human-readable values should be kept on the GUI, not in low-level internals like APIs, and 3) Not all Bitcoin users want to use the Decimal BitCoin (BTC) divisions.

casascius
Mike Caldwell
VIP
Legendary
*
Offline Offline

Activity: 1344


The Casascius 1oz 10BTC Silver Round (w/ Gold B)


View Profile WWW
February 09, 2011, 11:55:56 PM
 #29

Problem is, "TBC" is your own invention, no matter how many times you repeat it.

Even though I think "TBC" is silly, if the RPC accepted strings and could either be decimal ones (1234.567) as well as hexadecimal (0x1234.567) then he'd have his Tonal Bitcoins.  It would be up to him to fork it to put those silly 19th-century Mormon Deseret Alphabet looking digits in instead of the hexadecimal the rest of us understand, but anyone who shared the legitimate concern about bitcoins being strictly divisible by ten would have it solved, this could be used to represent exact amounts from IEEE floating point as well.

Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable.  I never believe them.  If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins.  I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion.  Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice.  Don't keep coins online. Use paper wallets instead.
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
February 10, 2011, 04:53:38 AM
 #30

Even though I think "TBC" is silly, if the RPC accepted strings and could either be decimal ones (1234.567) as well as hexadecimal (0x1234.567) then he'd have his Tonal Bitcoins.  It would be up to him to fork it to put those silly 19th-century Mormon Deseret Alphabet looking digits in instead of the hexadecimal the rest of us understand, but anyone who shared the legitimate concern about bitcoins being strictly divisible by ten would have it solved, this could be used to represent exact amounts from IEEE floating point as well.
1 BTC != 1 TBC. 0x1234.567 BTC is 6816.287 TBC (6C81C6.E9287 in hexadecimal; it is also impossible, given it contains a fractional 0.7 (Tonal/hex; 0.4375 decimal) base units)

In any case, I don't want RPC to use TBC. I want it to use base units, like all internals/protocols should. Adding a ".0" to the end is only to workaround a known buggy JSON implementation.
 

casascius
Mike Caldwell
VIP
Legendary
*
Offline Offline

Activity: 1344


The Casascius 1oz 10BTC Silver Round (w/ Gold B)


View Profile WWW
February 10, 2011, 07:31:30 AM
 #31

Even though I think "TBC" is silly, if the RPC accepted strings and could either be decimal ones (1234.567) as well as hexadecimal (0x1234.567) then he'd have his Tonal Bitcoins.  It would be up to him to fork it to put those silly 19th-century Mormon Deseret Alphabet looking digits in instead of the hexadecimal the rest of us understand, but anyone who shared the legitimate concern about bitcoins being strictly divisible by ten would have it solved, this could be used to represent exact amounts from IEEE floating point as well.
1 BTC != 1 TBC. 0x1234.567 BTC is 6816.9287 TBC (6C81C6.E9287 in hexadecimal; it is also impossible, given it contains a fractional 0.7 (Tonal/hex; 0.4375 decimal) base units)

In any case, I don't want RPC to use TBC. I want it to use base units, like all internals/protocols should. Adding a ".0" to the end is only to workaround a known buggy JSON implementation.
 
6816.9287 TBC ==6C81C6.E9287 in hex?
See look you even got your own 9 confused. Isn't 9 in this tonal gibberish really a ten (0xa)?  You have used a 9 in the same spot in your tonal quantity as in hex. If the purported fact that 5+5=9 in bonal trips up even a tonal genius, imagine how much the rest of us want nothing to do with it.

Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable.  I never believe them.  If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins.  I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion.  Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice.  Don't keep coins online. Use paper wallets instead.
Pages: « 1 [2]  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!