Disclaimer: while I'm fairly sure what I've written below is accurate, I've never actually read the IEEE spec. There could conceivably be some property of floating point arithmetic that I'm not aware of and which invalidates some or all of this!
There can't be an infinite amount of floating point values, since floats are stored in a finite amount of memory. Subnormal numbers (which I'm still not sure I understand fully) complicate things a bit, but they are only used for very small values; smaller than Number.MIN_VALUE, in fact.
So, when y + height
for an object is outside of the range (-Number.MIN_VALUE, Number.MIN_VALUE)
, there is no representable position between y + height - Number.MIN_VALUE
and y + height
Inside that range, which is an unfathomably tiny sliver of your game world, there is indeed a value which is closer to the interval closure. Depending on how you think about it, this would allow your objects to overlap by some amount smaller than Number.MIN_VALUE.
This is most likely not a serious problem.
Anyway, as the an object gets further from the origin and the base of your numbers go up, you lose enough precision to make all of this inconsequential. In fact now that I think about it, I'm pretty sure once you start moving away from values close to 1.0, foo - Number.MIN_VALUE
is going to be equal to foo
I've managed to confuse myself a bit here, so I'm going to use a scene break and then try to make a point.
I actually think bateleur's solution makes the most sense, for this particular case. He was saying you should raycast from (x, y + height), but reject collisions for which the ray is exactly touching an edge. Compared to trying to find the closest nearby ray and using that, this is a nice simple solution.
In the general case though, the kinds of errors we're dealing with here aren't going to affect gameplay. You expressed an aversion to subtracting 0.0001 in your first post, but that probably would have worked fine