fix: move bignum-dependent multipleOf tests to optional/bignum.json

[Sagar-6203620715]

What this changes

Two test groups in the core multipleOf.json files require arbitrary-precision arithmetic to evaluate correctly, making them de-facto mandatory bignum tests. This violates the suite's own convention that bignum support is optional.

The two affected test groups, moved across all 6 drafts:

• "float division = inf" — validates 1e308 against multipleOf: 0.123456789, expects valid: false. Assumes implementations overflow to false rather than erroring/throwing, which is not guaranteed on all platforms.

• "small multiple of large integer" — validates 12391239123 against multipleOf: 1e-8, expects valid: true. Requires arbitrary-precision arithmetic to compute correctly; IEEE 754 double implementations will silently produce a wrong result.

Files modified

Each multipleOf.json retains exactly 3 test groups: "by int", "by number", and "by small number" — none of which require bignum support.

Notes

• Draft-specific $schema URIs are preserved exactly as they appeared in the original multipleOf.json files (draft4/6/7 have no $schema; 2019-09, 2020-12, and v1 retain their respective URIs).
• The wording difference in draft4 ("invalid, but naive..." vs "always invalid, but naive..." in later drafts) is intentionally preserved.
• All 12 modified files pass JSON validation.
• No other tests are affected.

Fixes #536

[Sagar-6203620715]

/cc @Julian

[jdesrosiers]

Are we sure this is necessary? Most implementations don't support bignum and if this was a problem, someone would have said something by now. I know my implementation passes these tests and doesn't have bignum support.

[Sagar-6203620715]

Hi @jdesrosiers Thanks for the review,
your question is reasonable but I think the issue is less about whether an implementation happens to pass these tests and more about whether passing them is guaranteed to be correct without bignum support.

for the "float division = inf" case: an implementation without bignum may return valid: false not because it correctly evaluated the divisibility, but because it hit an overflow or exception and fell back to false.
gregsdennis addressed this directly in #536 an overflow is an error, not a valid result, so returning false by coincidence isn't correct behavior the suite should mandate.

for the "small multiple of large integer" case (12391239123 against multipleOf: 1e-8): IEEE 754 double arithmetic silently produces an incorrect result here.
An implementation may return valid: true for the wrong reason, the floating point math just happens to land close enough. That's not the same as correctly computing arbitrary-precision divisibility.

so the concern isn't that implementations can't pass these, it's that they can pass them through platform-specific coincidences rather than correct evaluation.
The optional/ directory exists exactly for cases where correct behavior depends on capabilities (like bignum) that aren't universally available.

This was also the consensus reached in #536, @Julian @gregsdennis all agreed these belong in optional, and @Julian explicitly invited a PR to move them.

Happy to discuss further if you see it differently!

[jdesrosiers]

for the "float division = inf" case: an implementation without bignum may return valid: false not because it correctly evaluated the divisibility, but because it hit an overflow or exception and fell back to false.

I agree that implementations shouldn't catch overflows and report them as false, but that's not necessary for these tests. 1e308 / .123456789 may produce Infinity, but 1e308 % .123456789 produces a representable number just fine. % is what's needed to do this calculation, not /, so I don't think there's anything wrong with this test.

for the "small multiple of large integer" case (12391239123 against multipleOf: 1e-8): IEEE 754 double arithmetic silently produces an incorrect result here.
An implementation may return valid: true for the wrong reason, the floating point math just happens to land close enough. That's not the same as correctly computing arbitrary-precision divisibility.

Floating point math can have issues even with simple numbers (0.3 / 0.1 === 2.9999999999999996). Implementations are expected to handle these cases regardless of whether they handle big numbers. The strategy involves comparing the % result to a very small number to account for the possible discrepancy. Lookup floating point epsilon comparison. So, I think this test is fine too. (Didn't we used to have a lot more tests covering this?)

[Sagar-6203620715]

@jdesrosiers I verified the arithmetic, and it seems your reasoning is correct.

For float division = inf: 1e308 % 0.123456789 produces 0.04711... finite and representable. The % operator doesn't propagate Infinity the way / does, so there's no overflow concern. My original framing was based on the wrong operator.

For small multiple of large integer: I've confirmed , 12391239123 / 1e-8 produces 1239123912300000000 and Number.isInteger() returns true, so an implementation using the division strategy passes correctly. I'll note that this value is above MAX_SAFE_INTEGER , so Number.isInteger is coarse there, but that's the implementation's problem to handle correctly, not a reason to move the test to optional.

Happy to close this if you're satisfied the tests are correctly placed as required. Also I think the issue #536 may be closed.

[jdesrosiers]

Actually, there is something to be done here. The description of the first test, ("always invalid, but naive implementations may raise an overflow error") is not correct and it would be great if we could fix that. No overflow should be expected.