Handling of precision for doubles

This topic provides information on the limits of precision in serialization of doubles in EQL results.

The nature of floating-point numbers is such that EQL cannot guarantee perfect precision when converting from an internal double to a string representation of that double and back again. In particular, if a number has more than 15 decimal digits, doing the double-to-string-to-double round trip will lose precision, and you will get a different number than you started with. (That's total number of digits, not necessarily digits after the decimal point.)

In principle, the number of decimal digits depends on a variety of implementation factors, but it is unlikely to change in practice. (More technically: as long as EQL uses IEEE 754 64-bit floating-point numbers, that limit will stay the same value.)

Therefore, if a client such as Studio takes a double from an EQL query's results and submits a new query using that double in a refinement filter, the user should not expect to get anything useful back if the number itself requires more than 15 decimal digits to represent. If that behavior is required, consider replacing the refinement filter with an EQL filter of the form:

x BETWEEN (dblVal - epsilon) AND (dblVal + epsilon)

where dblVal is the value from the previous query, and epsilon is some small positive number indicating the tolerance with which the record must match.

Similarly, if a client wishes to use a double from EQL results as the end point of a range filter, the client should probably adjust the range by some small tolerance amount.