Re: using a float as the index in an STL map?
On Apr 23, 4:37 am, Greg Herlihy <gre...@pacbell.net> wrote:
On Apr 21, 2:51 am, James Kanze <james.ka...@gmail.com> wrote:
On Apr 21, 3:07 am, red floyd <no.s...@here.dude> wrote:
James Kanze wrote:
On Apr 21, 12:36 am, zeppethef...@gmail.com wrote:
I think a good alternative would be to manually define the compari=
son
operator "less" considering that the equality
(a == b)
on a map is given by
!less(a,b) && !less(b,a)
it should be sufficient to write less() as something like
less(a, b){
if (a - b > threshold)
return false;
else
return true;
}
with threshold a proper small number.
That's a nice way to get undefined behavior. Since such a
function doesn't define an ordering relationship (which must be
transitive), it doesn't meet the requirements for std::map or
std::set.
On the other hand, assuming a reasonable threshold (EPSILON), what's
wrong with:
less(float a, float b)
{
if (fabs(a - b) > EPSILON) // difference big enough to be
return a < b; // significant
else
return false; // elements are "equal"
}
What have you changed? You still haven't defined a strict
ordering relationship, so you have undefined behavior.
There is no undefined behavior. The less() function does produce a
total ordering:
For any a, b, and c such that less(a, b) returns true and less(b, c)
returns true, then it is the case that less( a, c) also returns true.
So? The standard requires a "strict weak ordering". I'm not
too sure what that means mathematically, but the standard
explicitly defines what it means. In particular, it defines
"equiv(a, b)" as "!comp(a, b) && !comp(b, a)", and requires that
equiv define an equivalence relationship. That doesn't hold
for the above function, so the constraints are not met for the
relationship, and undefined behavior results.
Note that it's very easy to end up with undefined behavior
because of this where floating point is involved. But then,
it's very easy to end up with wrong results in general where
floating point is involved. Writing correct floating point code
requires knowing what you are doing, not just stabbing in the
dark and playing around with espilons or avoiding == or
whatever.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34