Re: [Json] -0.0

[Bjoern Hoehrmann <[e-mail]>]

* R S wrote:
>On Thu, Sep 26, 2013 at 11:41 AM, Paul Hoffman <[e-mail]>wrote:
>
>>    Numbers which represent zero without a sign, for example as 0 or 0.0
>>    not -0 or -0.0, are interoperable in the sense that software
>>    implementations will agree on the zero value.  Signed zeros are
>>    significant in some numerically-intensive applications, but
>>    implementations which read JSON texts cannot be relied upon to
>>    preserve that distinction.
>>
>> On Sep 26, 2013, at 10:31 AM, R S <[e-mail]> wrote:
>>
>> > I don't think there is a rationale for the text on -0.0. Is it for
>> non-IEE754 implementations?
>>
>> Do we need to state a rationale here, or does the text stand on its own?
>>
>>
>I meant that I don't see why it's in the draft at all. I propose deleting
>this paragraph, since I don't believe it is correct. Most implementations
>can be relied upon to preserve signed zeros.

The primary problem with negative zero is that it is very common for
number-to-string algorithms to render `-0` as `0`, and accordingly it
is common that negative zero vanishes accidentally, say when you have

  process_json_string(json_string)

and turn that into

  process_json_string(sanatise(json_string))

where sanatise parses, modifies, and re-serialises the json_string.
As I have mentioned, ecmascript's JSON.stringify is an example of a
JSON serialisation function that does not preserve negative zero.

The secondary problem is that many deployed implementations treat a
value like `-0` as integer value and do not preserve the sign. As an
example,

  % perl -MJSON -e "printf '%g', JSON->new->decode('[-0]')->[0]"
  0

Also in case of Perl, `-0` is not the same as `-0.0`,

  % perl -MJSON -e "printf '%g', JSON->new->decode('[-0.0]')->[0]"
  -0
-- 
Björn Höhrmann · mailto:[e-mail] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: [phone] · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/