Avoid numeric issues on export #33
turepalsson
started this conversation in
General
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
TL;DR: To a first approximation, this is a non-issue. :-) Though someone should check my math; I have corrected several mistakes already...
If we take the path that node colocation implies a topological connection, we should make sure that this does not cause accidental node "glueing" because of numerical issues on export.
Obviously, this should mostly be left to data consumers. As long as the data we give out is correct according to our own specs, we cannot be held responsible for whatever strange and buggy procedures data consumers subject it to.
However, we should at least consider the issue, so that we do not unwittingly create a situation where treating our data in some "obvious" way leads to subtle pitfalls.
In practice, this probably means that we should make sure that if two values, which are distinct in our database, are encoded in some transport format (ASCII strings for XML and JSON; I’m not sure what for PBF) and then converted to IEEE 754 64-bit floats, they are always still distinct.
I’m not sure what the internal format is, but the study mentions 7 decimal places. If I’m not mistaken, a number around 180 (which should be the worst case) gets stored as (roughly) 1.41 * 2^7 in 64-bit float. With 53 bits of significand, that means that the least significant bit is 2^-45, which is very roughly 10^-13, which seems like a healthy margin.
Beta Was this translation helpful? Give feedback.
All reactions