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

[genjix]

Try this:

Code:

<?php
$json = '{"e":5.01}';
var_dump(json_decode($json));
?>

Output:

Code:

object(stdClass)#1 (1) { ["e"]=> float(5.01) } 

[1714164408]

1714164408

[1714164408]

1714164408

[1714164408]

1714164408

[ShadowOfHarbringer]

My result:

Code:

object(stdClass)#1 (1) {
  ["e"]=>
  float(5.01)
}

Checked on 2 separate PHP Versions : 5.3.5 and 5.2.14

Different versions, different results ?

[Gavin Andresen]

PHP 5.3.3. on my mac gives:

Code:

object(stdClass)#1 (1) {
  ["e"]=>
  float(5.01)
}

Please be specific about what platform you're running on, what version of PHP are you running, are you running with a standard php.ini or have you tweaked it, etc.

[genjix]

sorry it was a typo. supposed to say 5.01

The point was that PHP is casting to floats in their JSON decoder and there's no option to use doubles or strings.

[BitterTea]

The PHP manual says that float=double.

Wouldn't gavin's solution of "float * 1e8" work?

[ShadowOfHarbringer]

sorry it was a typo. supposed to say 5.01

Probably a buggy version of PHP.

Anyway, on a lot of hosting providers have old versions of PHP installed (there are older versions in many distros' repositories), so it may be dangerous to use floats.
This is one of the reasons why i said initially that floats are dangerous as hell.

[Alex Beckenham]

Anyone that prefers a saner API (because they're using PHP) should check out my branch,
https://github.com/genjix/bitcoin/tree/strrpc

Values are returned as int64 strings.

Code:

function numstr_to_internal($numstr)
{
    return bcmul($numstr, pow(10, 8), 0);
}
function internal_to_numstr($num, $precision=8)
{
    $repr = gmp_strval($num);
    $repr = bcdiv($repr, pow(10, 8), $precision);
    # now tidy output...
    # trim trailing 0s
    $repr = rtrim($repr, '0');
    # and a trailing . if it exists
    $repr = rtrim($repr, '.');
    return $repr;
}

Those are the 2 functions I use to convert from internal values to display/user input values (numstr).

I updated the wiki, https://en.bitcoin.it/wiki/API_tutorial_%28JSON-RPC%29#PHP

Reading this at the moment... https://en.bitcoin.it/wiki/API_reference_(JSON-RPC)

Under 'Precision' you wrote:

You will need to get a saner branch and compile it.
https://github.com/genjix/bitcoin/tree/strrpc

Does 'saner branch' mean get a good version of GMP? I don't quite get what the phrase refers to.

[Nefario]

Saner branch is a genjix fork of bitcoind that returns int64 strings instead of floats or doubles in the json-api

This prevents any rounding errors associated with floats.

[Alex Beckenham]

Saner branch is a genjix fork of bitcoind that returns int64 strings instead of floats or doubles in the json-api

This prevents any rounding errors associated with floats.

Cheers, still getting used to terms such as 'fork' and 'branch'.

So is this still the best way to go about it for a 32-bit PHP install? (Change seems to happen quickly in this community at the moment).

[Nefario]

I don't know if it's the best way, I'm using ruby, and the whole float thing is a pain in my ass. I'm working with genjix anyway so I use his fork and avoid the entire float thing altogether.

[Alex Beckenham]

I don't know if it's the best way, I'm using ruby, and the whole float thing is a pain in my ass. I'm working with genjix anyway so I use his fork and avoid the entire float thing altogether.

Okay thanks... It looks like my host is able to up my PHP install to 64bit anyway.

[Gavin Andresen]

Can you'all educate me about these mythical rounding errors that require using GMP?

I can see, maybe, if you're computing interest down to the penny on a 30-year mortgage you might conceivably be off by a penny if you use 64-bit floats instead of 64-bit integers, although even there you're going to have to think hard about rounding as you get integer remainders.

And I can see being really careful if you're writing a bitcoin exchange site or bitcoin bank that deals in thousands of internal transactions that must all balance exactly.

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.

[burtyb]

I've seen problems when porting C test functions to ARM a few years ago, you definitely can't trust a floats to behave the same on all platforms.

[Nefario]

Can you'all educate me about these mythical rounding errors that require using 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.

Whoa there cowboy, I wasn't recommending anything, I just ansered a question, what was the genjix fork, and when asked what the best thing to do simply said what I was doing, and why.

I'm working with genjix on my project so it's not an issue for me if I use his fork, but I can't say the same for anyone else.

[jgarzik]

I've seen problems when porting C test functions to ARM a few years ago, you definitely can't trust a floats to behave the same on all platforms.

Actually, as long as you make sure all your IEEE compliance options are turned on...

[ShadowOfHarbringer]

I've seen problems when porting C test functions to ARM a few years ago, you definitely can't trust a floats to behave the same on all platforms.

Actually, as long as you make sure all your IEEE compliance options are turned on...

...but probably sometimes for some reason they won't be turned on...

[ShadowOfHarbringer]

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.

[Gavin Andresen]

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

[jgarzik]

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.

[jgarzik]

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.