DBL to JSON to DBL does not yield the same value

[daenglis]

Hi,

Thank you for JSONText.

How can I serialize doubles to JSON so that I get the same values back?

I have a large project, converting many files full of LabVIEW clusters of mixed data types to JSON. After conversion, I need to check them programmatically for accuracy. I must read back the converted JSON values and compare them to the originals.

Unfortunately I am getting a large number of falsely identified failures because the JSON doesn't contain all the digits of the LabVIEW DBL value.

In code, I need the first bool below to be True. Please understand that this is a minimal example, stripped of context, in an effort to make the issue simpler to understand.

 

The converted JSON reads {"Offset (nm)":-3670472.44094488}. It is missing the additional digits 221. If I tack on the extra digits  {"Offset (nm)":-3670472.44094488211} it does compare as equal to the original.

I understand that the numerical difference is meaningless, but if I can't check for simple equality, if I must instead check for equivalence within a range, it will greatly increase the difficulty of the validation program.

How can I serialize doubles to JSON so that I get the same value back? Thank you for your time

 

[drjdpowell]

I don't have an easy solution for you, I'm afraid.  JSON is a decimal notation, meant to be readable and writable by humans, rather than a serialization for binary numbers.  It isn't possible to both perfectly preserve serialized binary and preserve decimal numbers temporarily stored in floating-point binary numbers.   

For example, if your Operator set your Offset to 0.6 mm, that doesn't actually exist as a binary.  The nearest DBL is 0.5999999999999999778, and that is what the in-built "Flatten to JSON" primitive will output.  Someone similar to yourself trying to test if their JSON files are properly read in to DBL will find they have to write equivalence code, rather than a simple equality, as "Flatten to JSON" cannot output 0.6.  And the Operator will be rather unimpressed that the program is too stupid to properly read simple numbers.

JSONtext makes the choice that 0.6=0.6 is more important than perfectly reproducing binary numbers at levels no-one ever actually cares about.  Unfortunately that doesn't really help you.

[daenglis]

Thanks. I understand.

After looking more at your implementation, I see how you have tuned for the use case of directly editing json files, and I understand the choices you've made in the conversion of doubles.

My use cases are different. Humans will rarely, if ever, interact with my json. My current project is to convert to json for importation into a nosql database, where an existing application will query and process it. My previous project used JSONtext as the serializer for JSON-RPC in a large 0MQ-based API.

If it ever makes sense for you to offer the LV serialization of doubles as an option in JSONtext, I'd adopt it gratefully. If not, I understand

Cheers, thanks for your libraries!