Bitcoin Forum
December 03, 2016, 02:48:54 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 2 3 [4] 5 »  All
  Print  
Author Topic: why JSON RPC values not use INT64 instead of float string?  (Read 16798 times)
Nefario
Hero Member
*****
Offline Offline

Activity: 602


GLBSE Support support@glbse.com


View Profile WWW
March 30, 2011, 06:28:11 PM
 #61

The api doesn't need to be changed, we can just add an option to the command line that will specify int64 with float being the default.

Merge genjix's changes to be the ones used when int64 is passed in.

PGP key id at pgp.mit.edu 0xA68F4B7C

To get help and support for GLBSE please email support@glbse.com
1480733334
Hero Member
*
Offline Offline

Posts: 1480733334

View Profile Personal Message (Offline)

Ignore
1480733334
Reply with quote  #2

1480733334
Report to moderator
1480733334
Hero Member
*
Offline Offline

Posts: 1480733334

View Profile Personal Message (Offline)

Ignore
1480733334
Reply with quote  #2

1480733334
Report to moderator
1480733334
Hero Member
*
Offline Offline

Posts: 1480733334

View Profile Personal Message (Offline)

Ignore
1480733334
Reply with quote  #2

1480733334
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480733334
Hero Member
*
Offline Offline

Posts: 1480733334

View Profile Personal Message (Offline)

Ignore
1480733334
Reply with quote  #2

1480733334
Report to moderator
1480733334
Hero Member
*
Offline Offline

Posts: 1480733334

View Profile Personal Message (Offline)

Ignore
1480733334
Reply with quote  #2

1480733334
Report to moderator
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
March 30, 2011, 06:29:02 PM
 #62

If we want to be taken remotely seriously by the banking and merchant communities, floats need to go.

People keep claiming that, and yet I just did YET ANOTHER google search for "banking apis", clicked through to the Open Financial Exchange standard (from Microsoft and Quicken), and what do you know!  Money amounts look like floats:

Code:
          <STMTTRN>
              <TRNTYPE>CREDIT
              <DTPOSTED>20070315
              <DTUSER>20070315
              <TRNAMT>200.00
              <FITID>980315001
              <NAME>DEPOSIT
              <MEMO>automatic deposit
            </STMTTRN>
http://www.ofx.net/OFXExamplesPage/OFXExamples.aspx


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

Activity: 1470


View Profile
March 30, 2011, 06:30:04 PM
 #63

The api doesn't need to be changed, we can just add an option to the command line that will specify int64 with float being the default.

Thus creating a new, second parallel API, conditionally present or absent?  Ugh, no thanks.




Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1470


View Profile
March 30, 2011, 06:34:12 PM
 #64

People keep claiming that, and yet I just did YET ANOTHER google search for "banking apis", clicked through to the Open Financial Exchange standard (from Microsoft and Quicken), and what do you know!  Money amounts look like floats:

Don't assume a decimal (".") implies floating point.

Explanation by example:  Remember the difference in SQL between a FLOAT and DECIMAL.  Float is Approximate-number data type, which means that not all values in the data type range can be represented exactly.  Decimal/Numeric is Fixed-Precision data type, which means that all the values in the data type range can be represented exactly with precision and scale.

Anyone who deals with money demands DECIMAL-like behavior.  Bitcoin's internal use of int64 for values provides that fixed-precision, DECIMAL-like behavior.

Decimals (".") are common in monetary software.  Floating point data types are not.


Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
March 30, 2011, 06:38:57 PM
 #65

All righty, I hereby state:

All money values in the bitcoin JSON-RPC interface Are and Shall Be treated as Decimal, with 8 digits of precision after the decimal point.

If you're writing a banking application in a language that doesn't support Decimal types from JSON, then you should pack up your bags and go home.

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

Activity: 1470


View Profile
March 30, 2011, 06:43:41 PM
 #66

If you're writing a banking application in a language that doesn't support Decimal types from JSON, then you should pack up your bags and go home.

Is there a language that does produce fixed-precision from JSON?

jansson (C) and python's json both produce float, from a JSON number containing "."


Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
error
Hero Member
*****
Offline Offline

Activity: 574



View Profile
March 30, 2011, 06:46:15 PM
 #67

The main problem is that floating point is not sufficient to accurately store a Bitcoin balance or to do simple math and achieve a correct answer. Discussions of this problem are all over the Internet. A slightly oversimplified example from a Python FAQ hints at the real problem.

Ultimately a Bitcoin balance isn't a floating point number, it's a fixed-point number, and such numbers should not be manipulated with floating point functions, ever, lest Bitcoins start showing up in unexpected wallets.

Oh, and some people need pictures, so here's one.


15UFyv6kfWgq83Pp3yhXPr8rknv9m6581W
error
Hero Member
*****
Offline Offline

Activity: 574



View Profile
March 30, 2011, 06:47:46 PM
 #68

If you're writing a banking application in a language that doesn't support Decimal types from JSON, then you should pack up your bags and go home.

Is there a language that does produce fixed-precision from JSON?

jansson (C) and python's json both produce float, from a JSON number containing "."

PHP will soon have an option to json_decode() to treat large numbers as strings, though this code hasn't yet been released.

15UFyv6kfWgq83Pp3yhXPr8rknv9m6581W
genjix
Legendary
*
expert
Offline Offline

Activity: 1232


View Profile
March 30, 2011, 07:02:04 PM
 #69

And why do I defend floats:  because simple things should be simple.  Using GMP/BCMATH is overkill for 98% of what bitcoin JSON-RPC users will be doing.

As an aside:   Using GMP (or similar) is overkill for two big reasons:

  • We already link with and use OpenSSL's bignum (CBigNum), so there is no need for an additional library for Big Maths
  • It's just silly to want GMP when we already handle money properly internally, as int64.  The only issues present are interface issues, and you don't need to link with GMP in order to display an int64 with a decimal point somewhere in the middle.

My Bitcoin branch doesn't use GMP. It's simply a change to AmountFromValue, ValueFromAmount and other functions that weren't using those helper methods. They're referring to me using GMP in PHP which I use for a range of reasons. Namely PHP not always having 64 bit ints:
http://stackoverflow.com/questions/864058/how-to-have-64-bit-integer-on-php
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
March 30, 2011, 07:18:46 PM
 #70

The main problem is that floating point is not sufficient to accurately store a Bitcoin balance

An IEEE double-precision floating point number has 53 bits of precision, which IS sufficiently accurate to store a bitcoin balance.

Every single possible bitcoin value can be converted to and from an IEEE 64-bit float with no loss of precision.

I agree that if you're going to be performing lots of calculations on bitcoin values you need a Decimal type (and ClearCoin stores and uses python's decimal.Decimal(precision=8) for all bitcoin values)-- if you don't, floating point errors can accumulate and eventually cause you to gain or lose .00000001 of a coin.

But really the main problem with storing monetary values as any floating point type is you're likely to be embarrassed by mistakes like error's cash register receipt if you truncate values instead of rounding before printing.

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 30, 2011, 07:24:27 PM
 #71

I agree that if you're going to be performing lots of calculations on bitcoin values you need a Decimal type
If you're going to be doing *anything* with Bitcoin values, you should be using an int64.

error
Hero Member
*****
Offline Offline

Activity: 574



View Profile
March 30, 2011, 07:38:04 PM
 #72

The main problem is that floating point is not sufficient to accurately store a Bitcoin balance

An IEEE double-precision floating point number has 53 bits of precision, which IS sufficiently accurate to store a bitcoin balance.

Ha. I had to go check this for myself. Indeed, the maximum number of Bitcoins that can currently exist, 21000000.00000000 requires only 51 bits of data to store.

Eventually, perhaps not in our lifetimes, Bitcoin will be working with such "tiny" values as 0.00000001, and then it becomes a big issue. So I think it's better to deal with the issue now, so our kids don't have to. Cheesy

15UFyv6kfWgq83Pp3yhXPr8rknv9m6581W
ShadowOfHarbringer
Legendary
*
Offline Offline

Activity: 1470


Bringing Legendary Har® to you since 1952


View Profile
March 30, 2011, 08:13:27 PM
 #73

The api doesn't need to be changed, we can just add an option to the command line that will specify int64 with float being the default.

Thus creating a new, second parallel API, conditionally present or absent?  Ugh, no thanks.

Is adding a "string mode" creating a second API ? I don't think so. This is just a switch, how can you call this a second api ?
Also, an option for selecting the format of output data through XMLRPC/Command line/Whatever already exists in many modern applications.

jgarzik
Legendary
*
qt
Offline Offline

Activity: 1470


View Profile
March 30, 2011, 08:36:14 PM
 #74

Is adding a "string mode" creating a second API ? I don't think so. This is just a switch, how can you call this a second api ?

Because it changes the data format of every number in every RPC call.


Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
ShadowOfHarbringer
Legendary
*
Offline Offline

Activity: 1470


Bringing Legendary Har® to you since 1952


View Profile
March 30, 2011, 10:01:18 PM
 #75

Is adding a "string mode" creating a second API ? I don't think so. This is just a switch, how can you call this a second api ?

Because it changes the data format of every number in every RPC call.

Well, OK. You've got a point.
Still, no big deal.

After everybody starts using strings instead of floats (and they will, because floats are seen as VERY unprofessional in the industry), we may remove the old float mode completely.
However no hurry there, it may wait a few years.

BitterTea
Sr. Member
****
Offline Offline

Activity: 294



View Profile
March 30, 2011, 10:15:23 PM
 #76

Well, OK. You've got a point.
Still, no big deal.

After everybody starts using strings instead of floats (and they will, because floats are seen as VERY unprofessional in the industry), we may remove the old float mode completely.
However no hurry there, it may wait a few years.

If this change was made, any code using the API must first determine the API version, and then handle numbers in two different ways. No thanks.
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
March 31, 2011, 12:52:35 AM
 #77

No, they would just have their single "JSON-RPC value to raw bitcoins" function check the type of the argument and react appropriately. However, using strings is even MORE unprofessional than floats.

error
Hero Member
*****
Offline Offline

Activity: 574



View Profile
March 31, 2011, 12:58:31 AM
 #78

No, they would just have their single "JSON-RPC value to raw bitcoins" function check the type of the argument and react appropriately. However, using strings is even MORE unprofessional than floats.

The language may not give you a choice in the matter. Hello?

15UFyv6kfWgq83Pp3yhXPr8rknv9m6581W
ShadowOfHarbringer
Legendary
*
Offline Offline

Activity: 1470


Bringing Legendary Har® to you since 1952


View Profile
March 31, 2011, 01:55:54 AM
 #79

Well, OK. You've got a point.
Still, no big deal.

After everybody starts using strings instead of floats (and they will, because floats are seen as VERY unprofessional in the industry), we may remove the old float mode completely.
However no hurry there, it may wait a few years.

If this change was made, any code using the API must first determine the API version, and then handle numbers in two different ways. No thanks.

We can use different names for parameters, like

SendCoinsString 100.00000000
Instead of
SendCoins 100.00000000

That would eleminate such problems forever.

If you want to operate on string, just add suffix "String" to every parameter/attribute name.

ShadowOfHarbringer
Legendary
*
Offline Offline

Activity: 1470


Bringing Legendary Har® to you since 1952


View Profile
March 31, 2011, 02:12:05 AM
 #80

Ok.... so Gavin asked me (many times before and now) for the proof that the banking/financial industry avoids floats.

And i have found it !!

http://en.wikipedia.org/wiki/Floating_point#Minimizing_the_effect_of_accuracy_problems

Quote
Binary floating-point arithmetic is at its best when it is simply being used to measure real-world quantities over a wide range of scales (such as the orbital period of a moon around Saturn or the mass of a proton), and at its worst when it is expected to model the interactions of quantities expressed as decimal strings that are expected to be exact. An example of the latter case is financial calculations. For this reason, financial software tends not to use a binary floating-point number representation.[7] The "decimal" data type of the C# and Python programming languages, and the IEEE 754-2008 decimal floating-point standard, are designed to avoid the problems of binary floating-point representations when applied to human-entered exact decimal values, and make the arithmetic always behave as expected when numbers are printed in decimal.

The [7] reference leads here:
http://speleotrove.com/decimal/

--------------
I think we can call the topic closed.
Let's go string baby !

Pages: « 1 2 3 [4] 5 »  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!