Thinking about this some more, I think that what my current code is designed to do is reduce the number of occurences of floating point innaccuracies causing problems (with a bug of not checking the sign first). If the number is 1.03, that might end up in floating point as 1.02999999, or 1.03000001. Ideally, I'd like both of these to produce the same key value. My current code multiplies by 100 to produce 102.999999 or 103.000001, then adds .005, which produces 103.004999 or 103.005001, both of which get converted to 103. (I think this works out for negative numbers also, but the result would be -102, instead of -103 as normally expected. Given their use as keys, where the actual values don't really matter, this probably doesn't hurt anything.)
The expectation here is that LDraw files start out with fixed point coordinates, and very often, the transformed coordinate will also be very close to fixed point values (due to transformation matrices often being simple translations, or 90-degree increment rotations). So I wanted to prevent floating point innacuracies from separating two points from each other that were expected to be together.
It could well be that all of this was completely wrong-headed, and doesn't in fact do the job that it's intended to do when dealing with real-world parts.
The expectation here is that LDraw files start out with fixed point coordinates, and very often, the transformed coordinate will also be very close to fixed point values (due to transformation matrices often being simple translations, or 90-degree increment rotations). So I wanted to prevent floating point innacuracies from separating two points from each other that were expected to be together.
It could well be that all of this was completely wrong-headed, and doesn't in fact do the job that it's intended to do when dealing with real-world parts.