TIL json can't encode NaN or +/-inf. wtf!?...

Hows that a surprise? JSON's main selling point is inter-operability

NaN doesnt natively exist everywhere

@azuredivay nan/inf are part of the ieee754 float standard. It's probably harder to not support inf than it is to support it.

@azuredivay ieee754 floating points are not only the industry standard, they are literally what JS specifies as their number type

.... shouldn't an encoding format called "javascript object notation" be able to encode reasonable primitive values?...

@atheist @12bitfloat yes NaN/infinity are part of IEEE754 but JSON does NOT conform to that standard
why JSON doesnt, idk ._. they ideally should have

JSON caters to the common denominators to maximise interoperability, so maybe that's got something to do with it

@chatgpt why is there no NaN nor +/-inf in JSON? It is in javascript, and JSON is a javascript's object notation, so.. what gives?

Or maybe they are available in JSON spec, after all, we just can't find it?

@netikras
In JSON, NaN (Not a Number) and +/-Infinity are not included as data types because JSON is meant to be a lightweight data interchange format that is easy for both humans and machines to read and write. Including these special values would complicate the parsing process and potentially introduce ambiguity.

If you need to represent these values in your JSON data, you can use alternative representations. For NaN, you can use the string "NaN" or simply omit the value altogether. For Infinity and -Infinity, you can use the strings "Infinity" and "-Infinity" respectively.

Overall, JSON aims to be a simple and consistent format, and not including these special values helps maintain its clarity and ease of use.

and now tell me how often you use NaN or +/-inf in real life?

and in how many cases you could, for all intents and purposes, just use NULL and float.min/float.max?

it is an oversight in the specification, i agree. but personally, i find it less significant (by far) than, for example, a lack of comments, and no trailing commas being allowed. or the fact that duplicate keys are allowed.

My guess is it’s because there are no literal representations of nan and infinity.

In a programming language you would use a function or a constant, but json stores data as literals.

Because it's meant to be an exchange language and not every language supports that (how would NaN even translate to C?).

Javascript Object Notation means every JSON counts as a valid JS variable, not the other way around: not every valid JS variable instantly counts as JSON.

You can't serialize functions, you can't serialize NaN, you can't serialize Infinity. Seems pretty straightforward.

ChatGPT has a special aptitude for generating the worst possible answers by tunnel visioning on the stupidest expression of the problem.

@IHateForALiving float nan = 0.0 / 0.0;
float inf = 1.0 / 0.0;
There are also macros and functions for it
Every language that supports IEEE754 automatically supports NaN and infinity, it's just a few specific bits set

@tosensei if NaN shows up it's usually a fuck up. If inf shows up it's sometimes a fuck up, sometimes true. But don't use it very often.

@IHateForALiving My guy, floats in C are also just IEEE 754 floats. Not guarenteed by the spec, but on every modern (last 20 years) compiler, they are

Literally any language or processor which supports floating point numbers is using IEEE 754

@Lensflare Good point! That's likely the actual reason. JavaScript doesn't have syntax for it therefore JSON doesn't either

Wait until you learn that double keys are allowed. But i am not surprised at all by this.

@retoor Oh no... that's cursed

@12bitfloat Well in JS it's just NaN and Infinity literal. JSON could easily have done the same.

@retoor I guess they brought that over from the JS spec ;P

@12bitfloat CUDA is only vaguely compliant to the float spec, particularly in accuracy. I had to verify a C++ & CUDA implementation were the same, I started with a one line comment saying CUDA isn't compliant and a link to the docs, got a rambling rant in review about how I was wrong. So that one line is now 10 lines explaining in detail how that person is full of shit. There were no further comments on that part of the review.

@atheist Depends. Graphics cards in general aren't 100% compliant (e.g. only supporting some select rounding modes)

But they still mostly adhere. They at least do support nan and infs

@BordedDev Those are global properties I think, not literals

But i don't know, I would've just put a special case in the json spec to have those :P

@12bitfloat Same yeah

btw do you know what the result of this is:

NaN == NaN

@BordedDev It's false :P

Fun fact: floats are the primary reason Rust has both PartialEq/PartialOrd and Eq/Ord

Those damn nans, i tell ya!

@retoor oooh, I wonder if different parsers treat them differently too so you can use them for exploits just like URL params.

@12bitfloat And ordered_float is a wonderful crate. If it ever actually gets done (I'm beginning to doubt this), Orchid will have no NaN or infinities and instead float operations will produce an option of float.

@lorentz I'm honestly not sure whether having PartialOrd/Ord was a good idea

Nowadays I'm really appreciating simplicity and PartialOrd/Ord adds a huge layer of inconvenience for not that much gain ("oh no, my float-keyed hashmap experiences weirdness when the keys are NaN! How could this have happened!")

I guess it does make sense for more complex user defined types though

@lorentz I agree that options would be a nice replacement for NaN, but infinity should remain to be a special value.

Unless you mean option as in algebraic sum types and not as "nullable", then I agree for infinity.

Uh last I checked there was no standard support to represent infinity in any programming language I've ever used so why would json be able to represent it ?

@AvatarOfKaine https://en.wikipedia.org/wiki/...

@Lensflare it's all algebraic types, with the unique twist that option of float is implemented as an IEEE float and regular float is guaranteed to be an actual ordered finite number.