Bitcoin Forum
December 08, 2016, 06:06:57 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: [PULL] Full-precision display/entry for bitcoin amounts  (Read 2048 times)
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
February 23, 2011, 09:37:03 PM
 #1

https://github.com/bitcoin/bitcoin/pull/79

This modifies FormatMoney to display full-precision values (with trailing zeroes trimmed correctly-- e.g. 0 is 0.00 but 0.00010000 displays as 0.0001).

And ParseMoney allows entry of full-precision values.

And JSON's AmountFromValue doesn't round to two places, so you can send/move full-precision values.

I haven't tested this with the GUI bitcoin yet, it will probably require UI layout tweaks.

How often do you get the chance to work on a potentially world-changing project?
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481177217
Hero Member
*
Offline Offline

Posts: 1481177217

View Profile Personal Message (Offline)

Ignore
1481177217
Reply with quote  #2

1481177217
Report to moderator
1481177217
Hero Member
*
Offline Offline

Posts: 1481177217

View Profile Personal Message (Offline)

Ignore
1481177217
Reply with quote  #2

1481177217
Report to moderator
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
February 23, 2011, 09:53:19 PM
 #2

I just did some testing (on Linux) and the GUI seems to handle full-precision values quite nicely.

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 23, 2011, 11:59:08 PM
 #3

Does this still work correctly for 0.1 BTC, or does it expose bitcoind to the problem with representing this amount in binary (which would make it truncated as 0.09999999 BTC)? This fix should at the very least be sure to round at 8 decimal places, if not reading the digits directly into an int64.

theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
February 24, 2011, 01:00:58 AM
 #4

Does this still work correctly for 0.1 BTC, or does it expose bitcoind to the problem with representing this amount in binary (which would make it truncated as 0.09999999 BTC)? This fix should at the very least be sure to round at 8 decimal places, if not reading the digits directly into an int64.

I agree that this needs to be addressed. I've been converting everything to strings and then moving the decimal within the string to perform the "/COIN" division. This has worked fine with BBE.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
February 24, 2011, 02:39:59 AM
 #5

Does this still work correctly for 0.1 BTC, or does it expose bitcoind to the problem with representing this amount in binary (which would make it truncated as 0.09999999 BTC)? This fix should at the very least be sure to round at 8 decimal places, if not reading the digits directly into an int64.

Converting from a double-precision float from the JSON library to an int64 bitcoin is:
Code:
int64 nAmount = roundint64(dAmount * COIN);
... which will always do the right thing (COIN is 100000000).

int64 to JSON string there are no code changes.

GUI string to int64 is a direct conversion, no intermediate double precision.

And int64 to GUI string is:
Code:
strprintf("%.08f", double(amount)/double(COIN))
... which also always does the right thing (printf of a floating point number rounds, and there is enough precision in a double the rounding will always be correct).

0.1 bitcoins will always become exactly 10000000 base units internally, and 10000000 base units will always be shown as exactly 0.10 (in the GUI) or 0.10000000 (in JSON).


How often do you get the chance to work on a potentially world-changing project?
tcatm
Sr. Member
****
qt
Offline Offline

Activity: 337


View Profile
February 27, 2011, 10:40:20 PM
 #6

This patch introduces a bug on de_DE locale when sending using the wxGUI. Dialogbox with "Error in amount"
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
February 28, 2011, 06:29:09 PM
 #7

This patch introduces a bug on de_DE locale when sending using the wxGUI. Dialogbox with "Error in amount"

Can anybody else reproduce this?  It works for me:

How often do you get the chance to work on a potentially world-changing project?
tcatm
Sr. Member
****
qt
Offline Offline

Activity: 337


View Profile
February 28, 2011, 08:15:56 PM
 #8



Code:
LANG=de_DE.utf8
LC_CTYPE="de_DE.utf8"
LC_NUMERIC="de_DE.utf8"
LC_TIME="de_DE.utf8"
LC_COLLATE="de_DE.utf8"
LC_MONETARY="de_DE.utf8"
LC_MESSAGES="de_DE.utf8"
LC_PAPER="de_DE.utf8"
LC_NAME="de_DE.utf8"
LC_ADDRESS="de_DE.utf8"
LC_TELEPHONE="de_DE.utf8"
LC_MEASUREMENT="de_DE.utf8"
LC_IDENTIFICATION="de_DE.utf8"
LC_ALL=
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
February 28, 2011, 09:38:36 PM
 #9

It was LC_NUMERIC, I bet... (I'd just set LANG and unset the rest and assumed they'd all get picked up; internationalizing C++ applications is something I know very little about).

I modified the patch to format numbers the way they were formatted before:  always , for the thousands separator, and . for the decimal point (instead of letting sprintf try to do the right thing).

How often do you get the chance to work on a potentially world-changing project?
tcatm
Sr. Member
****
qt
Offline Offline

Activity: 337


View Profile
February 28, 2011, 11:19:44 PM
 #10

That fixes the problem.
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
March 01, 2011, 12:45:40 AM
 #11

I modified the patch to format numbers the way they were formatted before:  always , for the thousands separator, and . for the decimal point (instead of letting sprintf try to do the right thing).
That seems like an internationalization bug. What was wrong with using the correct localization? It would be nice to have BitCoin clients "just work" when LC_NUMERIC=tonal is fixed.

Also, especially with this change, it's even more important to merge my bugfix for unnecessary subcent waste/throwaway. That's in the gitorious bitcoin master branch ( git pull git://gitorious.org/bitcoin/bitcoin.git master )

Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
March 01, 2011, 01:00:42 AM
 #12

That seems like an internationalization bug. What was wrong with using the correct localization?

I was tempted to do more than fix the rounding problem...
... but then sanity overwhelmed me.

If you'd like to start a discussion of whether or not it is a good idea for one-thousand German bitcoin amounts to be displayed as "1.000,00", be my guest.  I think there was such a discussion in the past, but I didn't pay attention to it.  I think it would be nice if an amount like "1.001 BTC" (or even "1.001 tonal bitcoins") was unambiguous.

RE: subcent throwaway change:  turn it into a proper PULL request (yes, you'll have to-- horrors! -- use that evil, not 100%-pure-open-source github) and it'll happen faster.

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
March 01, 2011, 03:27:05 AM
 #13

(yes, you'll have to-- horrors! -- use that evil, not 100%-pure-open-source github)
Since the GitHub terms of service require me to agree to fund a legal defense of them if they get sued, this is not an economically viable option. tcatm did it, though.

Pages: [1]
  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!