more multipleOf and overflow tests, consolidated into optional/

[karenetheridge]

More argument combinations for multipleOf, including floats that will be treated as integers, as these might be internally represented as floats rather than ints, and therefore may behave differently.

All tests that might overflow (i.e. with very large/small numbers or a high number of significant digits) are consolidated into optional/ as an error may not be treated the same as valid: false.

[karenetheridge]

closes #534.

[karenetheridge]

I've tested these on drafts 2020-12, 2019-09 and 7; if someone else with support could check them on draft6 and draft4 that would be great.

[Julian]

(Thanks!)

I'm not sure how I feel about fully combining these yet personally.

There are 2 distinct pieces here to me --

• whether your implementation uses bignums (for integral values)
• whether your implementation supports infinite precision fixed-or-floating point values

JSON only has numbers, but many languages (mine, Python one of them) uses floats for JSON numbers with decimals, and ints for ones without. Which means I support (by default) bignum but not infinite precision floats. I think that will not be uncommon -- so personally I'd probably lean towards splitting these tests into two separate optional files rather than just the one.

Opinions welcome from others though.

[gregsdennis]

I'm happy either way. My main concern was putting both cases into optional, which is being addressed, so 👍

[karenetheridge]

JSON only has numbers, but many languages (mine, Python one of them) uses floats for JSON numbers with decimals, and ints for ones without. Which means I support (by default) bignum but not infinite precision floats.

I'm not following your logic here. You would need bignums for high precision calculations, whether that's with integers or floats. e.g. for a calculation like 1e+308 / 0.123456789, both the arguments can be represented with native-architecture floats, but the calculation itself requires a high degree of precision in order to determine if the remainder is zero.

[Julian]

I'm talking about tests like this: https://github.com/json-schema-org/JSON-Schema-Test-Suite/pull/538/files#diff-3070fe12dfc9ffeaf3ec0a633efce5b08f5cd07358f512904e3ffdb8f0b5103eR76-R95

That test mixes two unrelated concepts -- 18446744073709551600 passes if your implementation uses bigintegers. 18446744073709551600.0 requires the use of non-IEEE floats. An implementation may support one and not the other. And I was saying it's easier to deal with that if we have the two concepts separated.

[karenetheridge]

ok, I see.
I can split the tests back out.

[Julian]

@karenetheridge any chance you're still up for splitting the above?

[jdesrosiers]

@karenetheridge I'm going through closing old PRs with the philosophy that if it hasn't been addressed in years, it probably wasn't that important. This one looks like it was almost there, but waiting on an update from you. If you're interested in finishing it, please feel free to reopen.