4 ms·

> JSON numbers are also 64-bit floats In common implementations they are, but RFC 8259 and ECMA-404 do not specify the range, precision, or underlying implemen

by matja 4y ago

> JSON numbers are also 64-bit floats In common implementations they are, but RFC 8259 and ECMA-404 do not specify the range, precision, or underlying implementation for the storage of numbers in JSON. A implementation that guarantees interoperability between all implementations of JSON would use an arbitrary-sized number format, but they seldom do. No idea what ISO/IEC 21778:2017 says because it's not free.

bastawhiz 4y ago
I mean, I suppose you could use a numeric format that takes more than 64 bits, but you certainly couldn't use one that uses fewer. You have no way to know whether a number should be an int or a float. And since JavaScript (the JS in JSON) encodes with 64 bits, you'd be losing precision if you choose to use any less. The point is that an integer written as one byte in the JSON will take up more space (at least seven bytes more) when decoded, all the way up to numbers that take seven characters.
- gpderetta 4y ago
  (subsets of )ASN.1, LEB128, and of course UTF-8 are all examples of encoding binary integers with variable length.
  - bastawhiz 4y ago
    Sure, and JSON is as well. 0 takes three fewer bytes to encode than 1234. But if I parse JSON and my numbers come back as a type backed by UTF-8, I'm going to be left confused and angry. Nobody expects their JSON parser to give them back numeric values that their CPU can't natively perform operations on.
    - gpderetta 4y ago
      After you have spent some time confused and angry you can then read the documentation of whatever library you are using and verify whether it overloads numerical operations for its special number type or it has a function to convert them to whatever numerical type you need. In any case you wouldn't of course use UTF-8 to represent JSON numbers as it can only encode 21 bit intgers.

4 ms·

> JSON numbers are also 64-bit floats In common implementations they are, but RFC 8259 and ECMA-404 do not specify the range, precision, or underlying implemen

by matja 4y ago

bastawhiz 4y ago
I mean, I suppose you could use a numeric format that takes more than 64 bits, but you certainly couldn't use one that uses fewer. You have no way to know whether a number should be an int or a float. And since JavaScript (the JS in JSON) encodes with 64 bits, you'd be losing precision if you choose to use any less. The point is that an integer written as one byte in the JSON will take up more space (at least seven bytes more) when decoded, all the way up to numbers that take seven characters.
- gpderetta 4y ago
  (subsets of )ASN.1, LEB128, and of course UTF-8 are all examples of encoding binary integers with variable length.
  - bastawhiz 4y ago
    Sure, and JSON is as well. 0 takes three fewer bytes to encode than 1234. But if I parse JSON and my numbers come back as a type backed by UTF-8, I'm going to be left confused and angry. Nobody expects their JSON parser to give them back numeric values that their CPU can't natively perform operations on.
    - gpderetta 4y ago
      After you have spent some time confused and angry you can then read the documentation of whatever library you are using and verify whether it overloads numerical operations for its special number type or it has a function to convert them to whatever numerical type you need. In any case you wouldn't of course use UTF-8 to represent JSON numbers as it can only encode 21 bit intgers.