3 ms·

> JSON does not have a proper integer type What are the drawbacks to using the JavaScript Number (really a double float I think) datatype as an integer in an o

> JSON does not have a proper integer type What are the drawbacks to using the JavaScript Number (really a double float I think) datatype as an integer in an object representation language such as JSON? I've never seen a use case where e.g. 42 (int) could be confused with 42.0 (float). If your application needs specifically an int or a float, then the ingesting application knows that. If the answer is monetary values, then those should never be floats, and should not be represented in JSON as such. E.g. a dollar and a half should be represented as 150 cents. This follows even for sub-cent precision.

zzo38computer 1y ago
I don't mean 32-bit integers, but rather, 64-bit (and sometimes bigger) integers. JSON already works OK for 32-bit integers (although it is not ideal).
RedShift1 1y ago
Much easier would just be native decimal support in JS and we can represent a decimal using d as the decimal point, for example 15d0 (15.0) or 384d25 (384.25). Using cents instead of dollars sounds fine until you have to do math like VAT, you really need decimal math for that.
- afiori 1y ago
  Many applications simply use strings for that, like for dates
cstrahan 1y ago
JSON numbers are not JavaScript Numbers. While the grammar is specified (that’s what JSON is, after all), the runtime representation is unspecified. A conformant JSON parser can parse “1” as 1.0. They can be backed by doubles, or singles, or arbitrary precision.
- dotancohen 1y ago
  That's exactly my point. If one needs an integer or a float, the parser converts it. I ask under what use case is there ever ambiguity?
  - cstrahan 1y ago
    > If one needs an integer or a float, the parser converts it. Which parser? That’s the problem: if you’re using JSON as a data interchange format, you’ll need to carefully control both the serializers and deserializers, and whatever libraries you use, they will need to (at least internally) hold onto the number in a lossless way — I am not aware of any libraries that do this. They all parse the number as an f64 before any deserializers run. If your input JSON contains a u128, then you’ll have a loss of precision when your type is deserialized. If you can set up (de)serialization to work the way you need it, then there’s no problem. But if you share your JSON serialized data with other parties, then you/they may be in for a bit of a surprise. You might find it a worth while exercise to try parsing JSON containing an arbitrary unsigned 128 bit integer in your language of choice.
funcDropShadow 1y ago
Even if we assume that JSON numbers are JavaScript numbers. There is the problem that some large natural numbers cannot be represented in double or float although some even larger numbers can be represented. This is very bad if you use these numbers as IDs. scala> (Long.MaxValue-1) val res4: Long = 9223372036854775806 scala> (Long.MaxValue-1).toDouble.toLong val res5: Long = 9223372036854775807 The fact that I used Scala is irrelevant here. That is true for many programming languages that 64 bit long and double types.
- dotancohen 1y ago
  But that problem is not inherent to JSON, which is a pain text encoding of those numbers.

zzo38computer 1y ago

I don't mean 32-bit integers, but rather, 64-bit (and sometimes bigger) integers. JSON already works OK for 32-bit integers (although it is not ideal).

RedShift1 1y ago

Much easier would just be native decimal support in JS and we can represent a decimal using d as the decimal point, for example 15d0 (15.0) or 384d25 (384.25). Using cents instead of dollars sounds fine until you have to do math like VAT, you really need decimal math for that.

afiori 1y ago
Many applications simply use strings for that, like for dates

cstrahan 1y ago

JSON numbers are not JavaScript Numbers. While the grammar is specified (that’s what JSON is, after all), the runtime representation is unspecified. A conformant JSON parser can parse “1” as 1.0. They can be backed by doubles, or singles, or arbitrary precision.

dotancohen 1y ago
That's exactly my point. If one needs an integer or a float, the parser converts it. I ask under what use case is there ever ambiguity?
- cstrahan 1y ago
  > If one needs an integer or a float, the parser converts it. Which parser? That’s the problem: if you’re using JSON as a data interchange format, you’ll need to carefully control both the serializers and deserializers, and whatever libraries you use, they will need to (at least internally) hold onto the number in a lossless way — I am not aware of any libraries that do this. They all parse the number as an f64 before any deserializers run. If your input JSON contains a u128, then you’ll have a loss of precision when your type is deserialized. If you can set up (de)serialization to work the way you need it, then there’s no problem. But if you share your JSON serialized data with other parties, then you/they may be in for a bit of a surprise. You might find it a worth while exercise to try parsing JSON containing an arbitrary unsigned 128 bit integer in your language of choice.

funcDropShadow 1y ago

Even if we assume that JSON numbers are JavaScript numbers. There is the problem that some large natural numbers cannot be represented in double or float although some even larger numbers can be represented. This is very bad if you use these numbers as IDs. scala> (Long.MaxValue-1) val res4: Long = 9223372036854775806 scala> (Long.MaxValue-1).toDouble.toLong val res5: Long = 9223372036854775807 The fact that I used Scala is irrelevant here. That is true for many programming languages that 64 bit long and double types.

dotancohen 1y ago
But that problem is not inherent to JSON, which is a pain text encoding of those numbers.