Comparison of objects containing floats

[amrcode]

The operator==() method for json objects uses '==' on the underlying number_float_t type. This may result in false negatives and is contrary to the function's documentation which states "Floating-point numbers are compared indirectly: two floating-point numbers f1 and f2 are considered equal if neither f1 > f2 nor f2 > f1 holds". Could this behavior be changed to abs(f1 - f2) < std::numeric_limits<number_float_t>::epsilon() ?

[nlohmann]

I think this is a documentation issue. We changed the comparison to use ==, but forgot to adjust the documentation. The rationale of using == is not to introduce behavior that is different from double's behavior.

[amrcode]

That makes sense. Is it recommended to avoid adding floats to json objects then? Using a string or other representation seems much safer, though slower.

[nlohmann]

What do you mean with "safer"? The JSON specification itself mentions using C doubles to represent floating point numbers.

[amrcode]

I mean that using them in a json object potentially breaks the ability to compare json objects. I came across the documentation discrepancy when I was creating unit tests for my code and had literal doubles in my "expected" object and when I compared it with an input object operator== said the objects were not equal despite dump() returning identical strings. At first there were a few bits different in the hex of the doubles but they did not affect significant-enough digits to show up when printed. Later it seemed that even doubles with identical hex representations were sometimes not equal, I suspect due to conversions going into and out of the json object.

[amrcode]

This: https://randomascii.wordpress.com/2012/03/21/intermediate-floating-point-precision/ is a good writeup of various issues with working with floating point values. Using the built-in == for comparison is, I think, the correct way to go. Being a general-purpose library the burden of dealing with special cases should be on the user because not everyone is going to want to do this comparison the same way. It would be nice to have some control over the comparison operations but I don't see a clear, easy way to achieve that.

[nlohmann]

In the end, I think the best would be for a user with special comparison needs to provide her own comparison function and cope with the types as necessary. I think all internally stored values can be queried using the get() functions, so basically this function could be realized with a switch over the type().

[nlohmann]

I think there is nothing to do from the library side, right?

[amrcode]

I don't think so, other than the documentation update. Thanks!

[nlohmann]

Right. Thanks for reporting this!