why JSON RPC values not use INT64 instead of float string?

[Nefario]

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.

[1713506116]

1713506116

[1713506116]

1713506116

[1713506116]

1713506116

[Gavin Andresen]

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

[jgarzik]

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.

[jgarzik]

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.

[Gavin Andresen]

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.

[jgarzik]

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 "."

[error]

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.

[error]

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.

[genjix]

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]

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.

[Luke-Jr]

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]

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.

[ShadowOfHarbringer]

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]

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.

[ShadowOfHarbringer]

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]

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]

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]

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?

[ShadowOfHarbringer]

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]

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

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 !