From: Andy Johnson on
On 4 Mar, 10:22, Louis Lavery <Lo...(a)LaverREMOVE.demon.co.uk> wrote:
> Andy Johnson wrote:
> >> So, does floating point < define a strict weak ordering?
>
> >> If you avoid NANs (and as -0.0 and +0.0 behave as equals when compared)
> >> then yes.
>
> > This was kinda the answer I was hoping for but the responses are far
> > from conclusive.
>
> > Is this in the standard anywhere?
>
> > I agree with the general opinion that without knowledge of what the
> > floating point number represents it pretty difficult to determine how
> > they should logically compare (what constitutes representation error
> > vs actual difference).
>
> I don't get what you mean here. To me, a float represents a float.
>
> I think you should decide what type of number you're trying to model
> and then ask if floats can model (or be made to model) that type, not
> the other way round.

What I mean is, say I have a sensor producing a continous value to
within some error/tolerance then I can set Epsilon to a value that
appropriately distinguishes between what is error due to floating
point representation and what represents an actual change in input.

> That is if floats differing by no more than epsilon[1] compare equal
> then you no longer have transitivity of equivalence.

I wasn't really referring to numeric_limits::epsilon, more to a custom
value (much larger than epsilon<float>) tailored to my specific
problem.

AJ
>
> Louis.
>
> [1] Unless epsilon is 0, of course.

{ edits: quoted banner removed. please keep readers in mind. -mod }

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Francis Glassborow on
Andy Johnson wrote:
>> So, does floating point < define a strict weak ordering?
>
>> If you avoid NANs (and as -0.0 and +0.0 behave as equals when compared)
>> then yes.
>
> This was kinda the answer I was hoping for but the responses are far
> from conclusive.
>
> Is this in the standard anywhere?
>
> I agree with the general opinion that without knowledge of what the
> floating point number represents it pretty difficult to determine how
> they should logically compare (what constitutes representation error
> vs actual difference).
>
> I might err on the side of caution and decide on an epilson tailored
> to my specific problem.
>
> Thanks for all the responses
>
> AJ
>

This is fine if you know that the values will be well separated but may
fail if distinct actual values approach too closely.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: A. McKenney on
On Mar 3, 8:10 am, Louis Lavery <Lo...(a)LaverREMOVE.demon.co.uk> wrote:
> Andy Johnson wrote:

> > Can I use a floating point number (either single or double precision)
> > as the key for a map (and it work correctly)?
>
> So long as the comparison defines a strict weak ordering then it'll
> work correctly, no matter the type.
>
> So, does floating point < define a strict weak ordering?
>
> If you avoid NANs (and as -0.0 and +0.0 behave as equals when compared)
> then yes.

Assuming well-behaved arithmetic.

Non-IEEE-754 arithmetic tends to have badly-behaved areas.

Compilers -- or code -- that mix precisions can cause
problems here.

BTW, I know that IEEE specifies that -0.0 == +0.0,
but does it specify that -0.0 is not less than +0.0?
In the old days, before IEEE, hardware that
had +0.0 and -0.0 often had -0.0 < +0.0.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Louis Lavery on
Andy Johnson wrote:
> On 4 Mar, 10:22, Louis Lavery <Lo...(a)LaverREMOVE.demon.co.uk> wrote:
>> Andy Johnson wrote:
>>>> So, does floating point < define a strict weak ordering?
>>>> If you avoid NANs (and as -0.0 and +0.0 behave as equals when compared)
>>>> then yes.
>>> This was kinda the answer I was hoping for but the responses are far
>>> from conclusive.
>>> Is this in the standard anywhere?
>>> I agree with the general opinion that without knowledge of what the
>>> floating point number represents it pretty difficult to determine how
>>> they should logically compare (what constitutes representation error
>>> vs actual difference).
>> I don't get what you mean here. To me, a float represents a float.
>>
>> I think you should decide what type of number you're trying to model
>> and then ask if floats can model (or be made to model) that type, not
>> the other way round.
>
> What I mean is, say I have a sensor producing a continous value to
> within some error/tolerance then I can set Epsilon to a value that
> appropriately distinguishes between what is error due to floating
> point representation and what represents an actual change in input.
>
>> That is if floats differing by no more than epsilon[1] compare equal
>> then you no longer have transitivity of equivalence.
>
> I wasn't really referring to numeric_limits::epsilon,

Neither was I.

Louis.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Pete Becker on
Andy Johnson wrote:
> On 4 Mar, 10:22, Louis Lavery <Lo...(a)LaverREMOVE.demon.co.uk> wrote:
>> Andy Johnson wrote:
>>>> So, does floating point < define a strict weak ordering?
>>>> If you avoid NANs (and as -0.0 and +0.0 behave as equals when compared)
>>>> then yes.
>>> This was kinda the answer I was hoping for but the responses are far
>>> from conclusive.
>>> Is this in the standard anywhere?
>>> I agree with the general opinion that without knowledge of what the
>>> floating point number represents it pretty difficult to determine how
>>> they should logically compare (what constitutes representation error
>>> vs actual difference).
>> I don't get what you mean here. To me, a float represents a float.
>>
>> I think you should decide what type of number you're trying to model
>> and then ask if floats can model (or be made to model) that type, not
>> the other way round.
>
> What I mean is, say I have a sensor producing a continous value to
> within some error/tolerance then I can set Epsilon to a value that
> appropriately distinguishes between what is error due to floating
> point representation and what represents an actual change in input.
>

Interesting point. But this, in itself, doesn't fix the problem that a
fuzzy comparison function doesn't induce a strict weak ordering. As
Francis said, if the values are far enough apart, then you do get a
strict weak ordering. (On the other hand, if they're that far apart,
then you don't need the fuzzy comparison.) Another possibility would be
to divide the possible input range into a set of subranges, and replace
each value with the central value in its subrange. Voila, no fuzzy
comparisons. One way to do this would be to zero out the low two or
three bits in the value's mantissa.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of
"The Standard C++ Library Extensions: a Tutorial and Reference"
(www.petebecker.com/tr1book)

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]