Firstly, many thanks for this test-suite. It has help me significantly improve my parser.
Some of the "y_" tests assume that numbers have 64-bits (in some sense), specifically:
j_number.json (123e65);y_number_double_close_to_zero.json (-0.000000000000000000000000000000000000000000000000000000000000000000000000000001);y_number_real_exponent.json (123e45);y_number_real_fractions_exponent.json (123.456e78).
RFC8259 states (§6. Numbers):
This specification allows implementations to set limits on the range
and precision of numbers accepted. Since software that implements
IEEE 754 binary64 (double precision) numbers [IEEE754] is generally
available and widely used, good interoperability can be achieved by
implementations that expect no more precision or range than these
provide, in the sense that implementations will approximate JSON
numbers within the expected precision. A JSON number such as 1E400
or 3.141592653589793238462643383279 may indicate potential
interoperability problems, since it suggests that the software that
created it expects receiving software to have greater capabilities
for numeric magnitude and precision than is widely available.
Note that when such software is used, numbers that are integers and
are in the range [-(253)+1, (253)-1] are interoperable in the
sense that implementations will agree exactly on their numeric
values.
My parser is written for a RP2350 microcontroller which is a 32-bit ARM with single-precision floating point coprocessor and a limited double-precision coprocessor. Given the limited processing power and memory, I've chosen to set limits on the range and precision of numbers accepted consistent with 32-bit numbers. Of course, this may limit the interoperability of my applications, but my Use Case is operating in a closed system of communicating, embedded devices, so I can live with this restriction.
I've trivially tweaked the tests above according to the limits of my parser, but thought I might mention that the standard does not insist on any particular ranges, but merely suggests limits that maximises interoperability. Given this, is "123e45" a better test than, say, "543e21"?
I should hold my hand up at this point and admit that I don't have the perfect answer to my own question. If the standard allows any limits, then how can you define any numeric test cases? I've trivially tweaked the tests above for 32 bit values, but someone else may use half-precision floats. I just think that if the test case is checking the Well-Formed-ness (if that is a real word) of numbers, then might it be best to choose "smaller" numbers for the "y_" tests, and add some larger numbers for some "i_" tests?
Thanks again,
Steve
Firstly, many thanks for this test-suite. It has help me significantly improve my parser.
Some of the "y_" tests assume that numbers have 64-bits (in some sense), specifically:
j_number.json(123e65);y_number_double_close_to_zero.json(-0.000000000000000000000000000000000000000000000000000000000000000000000000000001);y_number_real_exponent.json(123e45);y_number_real_fractions_exponent.json(123.456e78).RFC8259 states (§6. Numbers):
My parser is written for a RP2350 microcontroller which is a 32-bit ARM with single-precision floating point coprocessor and a limited double-precision coprocessor. Given the limited processing power and memory, I've chosen to set limits on the range and precision of numbers accepted consistent with 32-bit numbers. Of course, this may limit the interoperability of my applications, but my Use Case is operating in a closed system of communicating, embedded devices, so I can live with this restriction.
I've trivially tweaked the tests above according to the limits of my parser, but thought I might mention that the standard does not insist on any particular ranges, but merely suggests limits that maximises interoperability. Given this, is "123e45" a better test than, say, "543e21"?
I should hold my hand up at this point and admit that I don't have the perfect answer to my own question. If the standard allows any limits, then how can you define any numeric test cases? I've trivially tweaked the tests above for 32 bit values, but someone else may use half-precision floats. I just think that if the test case is checking the Well-Formed-ness (if that is a real word) of numbers, then might it be best to choose "smaller" numbers for the "y_" tests, and add some larger numbers for some "i_" tests?
Thanks again,
Steve