Fix #75310 - Use DBL_EPSILON to avoid rounding errors in the range function - #2804

If at all, shouldn't we use DBL_EPSILON instead of introducing an own constant?

@cmb69 thanks for the feedback. That makes it better indeed.

@pmmaga thanks for checking. Nope, i literally meant to use abs() and the threshold is meant to be DBL_EPSILON. With that, it would be a usual epsilon comparison and one wouldn't have to care about the sign, however i see now it'd possibly require some more patch in the other area like size calculation. The comparison with >= or <= involving epsilon is still tricky with floating points. There are also so called relative epsilon comparisons of floating point, that might be useful in other cases.

I've just tested more, your patch indeed improves the situation with cases as in the tests pushed, but perhaps you could also check cases like range(111111111110.00057, 111111111110.00049, -0.00001). In general, where the fraction part tends to be smaller while the integral part is non zero and possibly big - some issues might still be present. For sure there is no ideal solution for arbitrary floating numbers, perhaps some documentation would be sufficient to describe reliable cases :/ Anyway, i'd recommend not to targed 7.0 with this, as there are for sure some unknown side effects but it would land in the last 7.0 release with the active support so couldn't get any follow ups.

Thanks.

Given that the change would not provide a consistent fix for all cases, it's better to leave the choice to users instead of trying (and sometimes failing) to help.