Consider parsing -0 as a double and not as zero

[lemire]

Currently, we parse -0 as 0 (integer value) and -0.0 as (-0, double value) in the DOM API.

[lemire]

Python behaves like simdjson:

>>> import math
>>> import json
>>> math.copysign(1, json.loads("-0"))
1.0
>>> math.copysign(1, json.loads("0"))
1.0
>>> math.copysign(1, -0.0)
-1.0
>>> math.copysign(1, json.loads("-0.0"))
-1.0

[lemire]

I am tempted to close this and leave "as is".

The fix would be simple enough:

is_float |= ((i == 0) && negative);

But any user that really cares about -0 and wants portability would almost surely be careful enough to serialize it as "-0.0".

Meanwhile, it is really subjective what -0 means. It is clear what -0.0 but many people would interpret -0 as zero.

[jkeiser]

The description indicates DOM already treats -0 as double, is that true? Is this about On Demand? In the On Demand API, you have to ask for either int or double, so I assume the issue is that getDouble() is returning double(+0.0)?

[lemire]

@jkeiser The issue is that integer types in C++ have no notion of -0 but doubles do. So some people would consider -0 to be a double.

We process -0 as the integer 0, and -0.0 as the double value -0.

In On Demand, we no longer distinguish between ints and doubles for the user. Still, if someone encountered -0 and decided to parse it as an integer, they would get 0, if they want it as a double, they would get -0.

so I assume the issue is that getDouble() is returning double(+0.0)?

I think you would get -0 actually.

[jkeiser]

Oh, so the idea is that if you ask for an integer, we treat -0 as INCORRECT_TYPE?

[lemire]

@jkeiser Yes!

But I am not sure I like this idea, but as you can see it is logical.

[jkeiser]

Yeah. I feel sort of positive about the principle that we refuse to parse to a type if it loses information that would be preserved if we parsed to a different type.

A compelling argument could be made that it is obvious which integer to assign this value, but we refuse to parse 1.1 to 1, and it seems like that would apply to integers as well.

On the other hand, we refuse to parse 1.0 as an integer ... that doesn't fit the principle I suggested above. We don't preserve the number of decimal places when we parse doubles with trailing zeroes, so I don't think we can claim we're trying to preserve the number of significant digits ...