[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
**Subject**: **Re: Float numbers equality.**
**From**: Dirk Laurie <dirk.laurie@...>
**Date**: Sun, 11 Aug 2013 18:58:33 +0200

2013/8/11 Victor Bombi <sonoro@telefonica.net>:
> In case rhs < 0
True, but one we know what Andrew means.
> ----- Original Message -----
> From: Andrew Starks
>
> In an effort to understand (not debate), where would:
>
> return math.abs(lhs - rhs) < epsilon*rhs
>
> ...be unsuitable?
Suppose lhs and rhs are both sums of many terms of both signs, and
the total is close to zero, in theory might even be equal to zero.
The above test may well not be satisfied when actually the numbers
are equal on paper. Instead, one should be using
return math.abs(lhs - rhs) < epsilon*scale
where 'scale' is a rough approximation to the sums of the absolute
values.
There are other situations. You can't fix epsilon by looking at
machine precision: the more computations it takes to compute the
operands, the bigger epsilon should be, etc.
Luiz is right here: the appropriate test for floating-point equality
is never so simple that any one method is always foolproof. There is
no substitute for consulting an experienced numerical analyst. :-)

**References**:
**Float numbers equality., ***Karol Dro*
**Re: Float numbers equality., ***Matthias Kluwe*
**Re: Float numbers equality., ***Coda Highland*
**Re: Float numbers equality., ***Luiz Henrique de Figueiredo*
**Re: Float numbers equality., ***Coda Highland*
**Re: Float numbers equality., ***Enrico Colombini*
**Re: Float numbers equality., ***Coda Highland*
**Re: Float numbers equality., ***Tim Hill*
**Re: Float numbers equality., ***Luiz Henrique de Figueiredo*
**Re: Float numbers equality., ***Andrew Starks*
**Re: Float numbers equality., ***Victor Bombi*