In I3 JSON, a Numeric Value of "NaN" is written to a JSON tree, but cannot be read again.
Is that intended, or, what is the prefered workaround?
Of course I can check values beeing written for "=NaN" prior to storing it to the JSON tree, use String instead of Numeric type, add an additional item to send the "NaN" status, encode "NaN" to -1 or whatever.
But: I was still surprised that the library writes NaN just fine if it's not supposed to read it back...
See the following snippets:
The IEEE754 special values like NaN, +Infinity, and -Infinity are not valid JSON Numeric values so allowing NaN through was an oversight. I'm glad the parser rejects it correctly since it is invalid JSON but it's unfortunate that the API lets you add a numeric node with NaN as the value.
There isn't really a preferred workaround, it depends on your application. All the options you describe seem reasonable.
An approach I have used before is the idea of knowing the schema of the data in LabVIEW and accepting multiple possible representations. For example, if I know the field of an object is a representation of time then when parsing in my application if I get a JSON Number value I would parse it as seconds since epoch, if I get a JSON String value I parse it using an expected format, if I get a JSON Object value with a seconds and fractions I parse it as parts of a LabVIEW Timestamp, etc. For this numeric case it seems like if I know the field represents a double then being able to accept a JSON Number or a JSON String with certain possible values seems doable in the application. I'm not necessarily recommending that approach, again it depends on the application.
I'll keep it in mind that IEEE754 values are incorrectly being passed through, thank you for mentioning it.