why JSON RPC values not use INT64 instead of float string? - page 2.

BitterTea

sr. member

Activity: 294

Merit: 252

Quote from: ShadowOfHarbringer on March 30, 2011, 05:01:18 PM

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.

ShadowOfHarbringer

legendary

Activity: 1470

Merit: 1006

Bringing Legendary Har® to you since 1952

Quote from: jgarzik on March 30, 2011, 03:36:14 PM

Quote from: ShadowOfHarbringer on March 30, 2011, 03:13:27 PM

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.

jgarzik

legendary

Activity: 1596

Merit: 1100

Quote from: ShadowOfHarbringer on March 30, 2011, 03:13:27 PM

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

legendary

Activity: 1470

Merit: 1006

Bringing Legendary Har® to you since 1952

Quote from: jgarzik on March 30, 2011, 01:30:04 PM

Quote from: Nefario on March 30, 2011, 01:28:11 PM

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.

error

hero member

Activity: 588

Merit: 500

Quote from: Gavin Andresen on March 30, 2011, 02:18:46 PM

Quote from: error on March 30, 2011, 01:46:15 PM

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

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: Gavin Andresen on March 30, 2011, 02:18:46 PM

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.

Gavin Andresen

legendary

Activity: 1652

Merit: 2311

Chief Scientist

Quote from: error on March 30, 2011, 01:46:15 PM

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.

genjix

legendary

Activity: 1232

Merit: 1076

Quote from: jgarzik on March 30, 2011, 01:26:13 PM

Quote from: Gavin Andresen on March 30, 2011, 01:22:16 PM

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

error

hero member

Activity: 588

Merit: 500

Quote from: jgarzik on March 30, 2011, 01:43:41 PM

Quote from: Gavin Andresen on March 30, 2011, 01:38:57 PM

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.

error

hero member

Activity: 588

Merit: 500

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.

jgarzik

legendary

Activity: 1596

Merit: 1100

Quote from: Gavin Andresen on March 30, 2011, 01:38:57 PM

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

Gavin Andresen

legendary

Activity: 1652

Merit: 2311

Chief Scientist

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

legendary

Activity: 1596

Merit: 1100

Quote from: Gavin Andresen on March 30, 2011, 01:29:02 PM

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.

jgarzik

legendary

Activity: 1596

Merit: 1100

Quote from: Nefario on March 30, 2011, 01:28:11 PM

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.

Gavin Andresen

legendary

Activity: 1652

Merit: 2311

Chief Scientist

Quote from: jgarzik on March 30, 2011, 01:22:43 PM

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:

           
              CREDIT
              20070315
              20070315
              200.00
              980315001
              DEPOSIT
              automatic deposit

http://www.ofx.net/OFXExamplesPage/OFXExamples.aspx

Nefario

hero member

Activity: 602

Merit: 513

GLBSE Support [email protected]

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.

jgarzik

legendary

Activity: 1596

Merit: 1100

Quote from: Gavin Andresen on March 30, 2011, 01:22:16 PM

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.

jgarzik

legendary

Activity: 1596

Merit: 1100

If we want to be taken remotely seriously by the banking and merchant communities, floats need to go. Whether the end result is "1000000000" or "10.00000000" is largely cosmetic. But I do agree that -- long term -- JSON's "number" and internal floats fall short of what is needed for proper money handling software.

But.... it just hurts to change the API right now, because we will see very little payback for a large amount of pain.

Gavin Andresen

legendary

Activity: 1652

Merit: 2311

Chief Scientist

Apologies to Nefario, I was reacting to the wiki pages written by genjix on how to use PHP with bitcoind that started with:

+ First, compile my fork.
+ Next, install the GMP and BCMath libraries...

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.

And because certain people keep beating this dead horse. I have said that I am PERFECTLY WILLING to support strings in the JSON-RPC interface if somebody can demonstrate to me someplace where it is actually a real problem (that isn't trivially solved using something like round(value*1e8+0.5) or printf("%.08", value)).

ShadowOfHarbringer

legendary

Activity: 1470

Merit: 1006

Bringing Legendary Har® to you since 1952

Quote from: Gavin Andresen on March 30, 2011, 12:11:31 PM

But for the typical PHP website that is just going to add up 10 items in a shopping cart using plain-old PHP Numbers will be just fine. I don't see PayPal recommending that PHP users of it's APIs install GMP. Recommending that any website dealing with bitcoins compile genjix' fork and use GMP is a really good way to ensure that nobody accepts bitcoins.

Can't we just have 2 separate APIs - one float and one string in the official client ? Or maybe perhaps one API with "string mode" and "float mode" ?

BTW, are the floats really so necessary and important that you defend them ?
No offense, but while reading this topic it seems that almost nobody here likes floats except you.

Topic: why JSON RPC values not use INT64 instead of float string? - page 2. (Read 18438 times)