Revisiting Decimal

Kris Zyp kris at
Thu Jan 15 12:32:53 PST 2009

Hash: SHA1

Brendan Eich wrote:
> On Jan 15, 2009, at 10:46 AM, Kris Zyp wrote:
>> Brendan Eich wrote:
>>> On Jan 15, 2009, at 9:47 AM, Kris Zyp wrote:
>>>> Where is the loss coming from?
>>> Decimal-using peer S1 encodes
>>> {p:1.1, q:2.2}
>>> Double-using peer C1 decodes, adds, and returns
>>> {p:1.1, q:2.2, r:3.3000000000000003}
>>> The sender then checks the result using decimal and finds an
>>> error. Meanwhile the same exchange between S1 and decimal-using
>>> peer C2 succeeds without error.
>>> /be
>> Exactly, C1 introduces the error by it's use of binary.
> This is not about blame allocation. The system has a problem
> because, even though JSON leaves numeric representation
> unspecified, higher layers fail to agree. That could be viewed as a
> JSON shortcoming, or it could be the fault of the higher layers. I
> don't want to debate which is to blame here right now (more below).
> The point is that all the JS self-hosted JSON implementations I've
> seen, and (crucially) the ES3.1 native JSON implementation, use
> double, not decimal. This constitutes an interoperation hazard and
> it constrains compatible future changes to ES-Harmony --
> specifically, we can't switch JSON from double to decimal by
> default, when decoding *or* encoding.
How do you switch to double or decimal by default on encoding? The
input defines it, not any default setting.
>> The JSON encoding didn't introduce the error. JSON exactly
>> represented the data it was given,
> JSON the RFC is about syntax. It doesn't say more than "An
> implementation may set limits on the range of numbers" regarding
> semantics of implementations.
> Actual implementations that use double and decimal will not
> interoperate for all values. That means "not interoperate".
>> and the decimal decoding and encoding peer refrains from
>> introducing errors as well.
> Assuming no errors is nice. (What color is the sky in your world?
> :-P) Meanwhile, back on this planet we were debating the best way
> to reduce the likelihood of errors when adding decimal to JS. Back
> to that debate:
3.3 is exactly the sum of 1.1 and 2.2 without errors as decimal math
produces here in the blue sky world (I was going off your example).
Utah may have unusually blue skies though, it is the desert :).

>> Are you arguing that all JSON interaction relies on other peers
>> introduces errors according to binary floating computations? I
>> already disproved that idea by pointing out there are existing
>> implementations that use decimal and thus don't add such errors.
> You didn't prove or disprove anything, you hand-waved. For all you
> or I know, and Bob Ippolito agrees, there are latent, hard-to-find
> bugs already out there.
You are saying there latent hard-to-find bugs because people believe
that JSON somehow implies that the sum of {"p":1.1, "q":2.2} must be
3.3000000000000003 ? If people are returning 3.3, then the argument
that JSON numbers are universally treated computed as binary is not
valid. Is there a less hand-wavy way of stating that?

> Our bone of contention specifically was making (typeof 1.1m ==
> "number"), and I am certain that this increases the likelihood of
> such bugs. It cannot reduce the likelihood of such bugs. Whether it
>  means more work for Dojo and other frameworks that would need to
> adapt to the addition of decimal to a future ES spec is secondary,
> or really just TANSTAAFL.
I thought JSON serialization and typeof results could be considered
separate issues.

>> If you are arguing that there are certain client-server couples
>> have become dependent on these errors there are couple faults in
>> this logic. First, the error dependencies experienced in
>> languages are almost always going to be internalized by devs.
>> Because there may be a number of internal error expectations in
>> existence does not imply a significant number of inter-machine
>> rounding error expectation dependency.
> To the extent I understand what you mean here, I can only disagree
> -- completely!
> You're arguing by assertion that rounding errors due to double's
> finite binary precision, which are the most reported JS bug at
>, are somehow insignificant when JSON
> transcoding is in the mix. That's a bold assertion.
The issue here is relying on another machine to do a computation. I
have trouble believing that all these people that are experiencing
rounding errors are then using these client-side computations for
their server. The compensation for rounding errors that we are
concerned are usually going to be kept as close to the error as
possible. Why would you build a client-server infrastructure around it?
>> Second, I am not asserting that JSON decoding should
>> automatically convert JSON numbers to binary, only that JSON
>> encoding should serialize decimals to numbers.
> What should JSON.parse use then, if not double (binary)? JSON.parse
>  is in ES3.1, and decimal is not.
It should use double. I presume that if a "use decimal" pragma or a
switch was available, it might parse to decimal, but the default would
be double, I would think.
>> In your example, if a server is sending these JSON values to C1
>> ES-harmony based peer for computation, the computations will
>> still take place in binary,
> Ok, hold that thought.
>> unless we were to add some mechanism for explicitly specifying
>> how numbers should be decoded.
> Let's say we don't. I showed interoperation failure if two peers,
> C1 and C2, fail to decode to the same numeric type. You now seem to
> be agreeing that binary should be the one type JSON number syntax
> decodes into. Great, except you want encoders to stringify decimal
> literals as JSON numbers.
> This means 1.1m and 1.1 both encode as '1.1' but do not compare as
> == or === (whatever happens with typeof and the typeof/==/===
> invariant). It also means
> 123345678901234567890.1234567890123m
> encodes as
> '123345678901234567890.1234567890123'
> but decodes as binary
> 123345678901234570000
> which breaks round-tripping, which breaks interoperation.
JSON doesn't round-trip JS, and it never will. There are plenty of
exceptions. I presume that if a receiver had a "use decimal" pragma
they could count as opt-in to parsing numbers into decimal and then
you could round-trip decimals, but only if the sender was properly
encoding decimals as JSON numbers (decimals). Encoding the decimals as
strings is far worse.

> Long ago in the '80s there was an RPC competition between Sun and
> Apollo (defunct Massachusetts-based company, but the RPC approach
> ended up in DCE), with both sides attempting to use open specs and
> even open source to build alliances. Bob Lyons of Sun argued
> eloquently for one standard type system for senders and receivers.
> Paul (I forget his last name) of Apollo argued for "receiver makes
> it right" to allow the funky non-IEEE-754 floating point formats of
>  the day to be used at the convenience of the sender. E.g. Cray and
>  DEC VAX senders would not have to transcode to the IEEE-754 lingua
>  franca, they could just blat out the bytes in a number in some
> standard byte order.
> Bob Lyon's rebuttal as I recall it was two-fold: 1. "receiver makes
>  it right" is really "receiver makes it wrong", because the many
> types and conversions are a fertile field for bugs and versionitis
> problems among peers. 2. There should be indeed be a lingua franca
> -- you should be able to put serialized data in a data vault for
> fifty years and hope to read it, so long as we're still around,
> without having to know which sender sent it, what floating point
> format that obsolete sender used, etc.
> The two points are distinct. Complexity makes for versionitis and
> bug habitat, but lack of a single on-the-wire *semantic* standard
> makes for a Tower of Babel scenario, which means data loss. Fat,
> buggy, and lossy are no way to go through college!
> See for
> more.
> We are not condemned to repeat history if we pay attention to what
> went before. JSON implementations in future ES specs cannot by
> default switch either encoding or decoding to use decimal instead
> of number.
The decimal number has been around much longer than the computer. Are
saying that a particular language type has more permanence?

Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla -

More information about the Es-discuss mailing list