instance equality - trailing zeroes are insignificant?

[asgs]

Hello! The spec says that trailing zeroes are insignificant when it comes to instance equality.

Was it meant as leading zeroes instead? Also, I'm assuming this is referring to the fields of type "number". Please clarify.

[Relequestual]

That's actually a really good point... No idea how that skipped through the net. I believe you are correct.

@awwright @handrews could either of you confirm this?

[Relequestual]

The intention may have been trailing zeroes AFTER the decimal place, but I agree it's somewhat ambigious.

[awwright]

Yeah that can probably be better worded. It's just an informative sentence, but maybe we could update it to say "insignificant zeros" (leading or excess in a decimal part)

…

On Jan 4, 2017 03:02, "Ben Hutton" ***@***.***> wrote: The intention may have been trailing zeroes AFTER the decimal place, but I agree it's somewhat ambigious. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#221 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAatDad1iHkBw0EjoKyt1ci_nsWBLZ9sks5rO24igaJpZM4LaY-0> .

[Relequestual]

OK. I'll self assign to make a PR on this one.

[awwright]

Cool. Also, j/k on my leading zeros part, I recalled the JSON ABNF doesn't permit that.

…

On Jan 4, 2017 10:43, "Ben Hutton" ***@***.***> wrote: OK. I'll self assign to make a PR on this one. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#221 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAatDXsd5gRKI4pu52Ee-DBu2VPJJArfks5rO8w7gaJpZM4LaY-0> .

[handrews]

This just intends to say that differences in trailing zeros do not impact equality because they are not mathematically significant, right? 1, 1.0, and 1.00000 are all mathematically equivalent, so as instances they are equal. This is different from JSON equality as discussed in RFC 7159 which just discusses equality in terms of encoded strings.

[awwright]

Here's some examples as I understand the concern and behavior of JSON: `01` is invalid JSON `1.0`==`1.00` But `10`!=`100` (I.e. the spec should say leading zeros in the fractional part)

…

On Jan 5, 2017 15:04, "Henry Andrews" ***@***.***> wrote: This just intends to say that differences in trailing zeros do not impact equality because they are not mathematically significant, right? 1, 1.0, and 1.00000 are all mathematically equivalent, so as instances they are equal. This is different from JSON equality as discussed in RFC 7159 which just discusses equality in terms of encoded strings. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#221 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAatDeYf3BQjcKDoj6E8k_nQLPmBv1trks5rPUy9gaJpZM4LaY-0> .

[handrews]

@awwright I don't think that JSON Schema needs to clutter itself with explanations that 10 and 100 are different numbers.

[awwright]

I mean *trailing zeros in the fractional part On Jan 5, 2017 16:05, "Austin William Wright" <[email protected]> wrote: Here's some examples as I understand the concern and behavior of JSON: `01` is invalid JSON `1.0`==`1.00` But `10`!=`100` (I.e. the spec should say leading zeros in the fractional part)

…

On Jan 5, 2017 15:04, "Henry Andrews" ***@***.***> wrote: This just intends to say that differences in trailing zeros do not impact equality because they are not mathematically significant, right? 1, 1.0, and 1.00000 are all mathematically equivalent, so as instances they are equal. This is different from JSON equality as discussed in RFC 7159 which just discusses equality in terms of encoded strings. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#221 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAatDeYf3BQjcKDoj6E8k_nQLPmBv1trks5rPUy9gaJpZM4LaY-0> .

[awwright]

Can we just say "excess zeros" here instead?

[seagreen]

Here's some examples as I understand the concern and behavior of JSON:
...
1.0==1.00

This is incorrect. A JSON text is a series of tokens. 1.0 and 1.00 are clearly different series of tokens.

[awwright]

@seagreen That seems to be a different understanding, of the sense that they will be different lexical representations (and different information resources/documents), but not necessarily different values. The value space of JSON is sort of implied in RFC 7159, as in this passage among others:

Implementations that transform the
textual representation into sequences of Unicode code units and then
perform the comparison numerically, code unit by code unit, are
interoperable in the sense that implementations will agree in all
cases on equality or inequality of two strings. For example,
implementations that compare strings with escaped characters
unconverted may incorrectly find that "a\b" and "a\u005Cb" are not
equal.

JSON Schema specifically defines a data model that JSON values are computed by, however see #152 for an idea on exposing the precision of a number for applications that need to distinguish between 1 and 1.0000 (like engineering applications).

[seagreen]

Right, JSON Schema works on a different data model than plain JSON.

I just wanted to be clear that there's nothing in JSON that says 1.0 == 1.00. JSON specifies a lexical representation in which those sequences of tokens aren't equal. It also clearly expects that in-memory representations of JSON will sometimes be compared (as is discussed in your excerpt about comparing strings) but doesn't say how this comparison should be done for numbers.

Sorry if this seems nitpicky, but I think it's important to be precise on what JSON is, what JSON Schema is, and the boundaries between them.

[handrews]

I think #455 addresses this sufficiently, please re-open if not.