Nathan Myers wrote:
>
> Helmut Zeisel <zeisel@vai.co.at> wrote:
> > ncm@nospam.cantrip.org (Nathan Myers) writes:
> >> Arguably one shouldn't put complex<float> values in a set, because
> >> it implicitly involves comparing them for equality and float is
> >> an imprecise representation: equality of floating-point values is
> >> often illusory.  (E.g. assert(2.0 == sqrt(2.0)*sqrt(2.0)).)
> >
> >The same kolds not only for complex<float>, but also for float itself.
> >You can use set<float>, however.
>
> You had better be careful what you put in there.  less<float>
> doesn't define a total ordering.  Unfortunately the compiler
> probably will not warn you about this.

AFAIK it's enough to provide a strict weak order. Does less<float>
fail to provide this as well (in a conforming program without
invoking undefined behaviour; therefore no NaN produced)?

I think, apart from the NaN issue, the only problematic point is 0,
which can be +0 or -0; however, this is still a strict weak order.
Also, you seldom want to distinguish between +0 and -0 anyway.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern/std-c++/faq.html                  ]

In article <6bbkbo$maa$1@shell7.ba.best.com>, ncm@nospam.cantrip.org (Nathan Myers) writes:
> Helmut Zeisel <zeisel@vai.co.at> wrote:
> > ncm@nospam.cantrip.org (Nathan Myers) writes:
> >> Arguably one shouldn't put complex<float> values in a set, because
> >> it implicitly involves comparing them for equality and float is
> >> an imprecise representation: equality of floating-point values is
> >> often illusory.  (E.g. assert(2.0 == sqrt(2.0)*sqrt(2.0)).)
> >
> >The same kolds not only for complex<float>, but also for float itself.
> >You can use set<float>, however.
>
> You had better be careful what you put in there.  less<float>
> doesn't define a total ordering.  Unfortunately the compiler
> probably will not warn you about this.

When I understand correctly, you are thinking of
the IEEE NaN's etc.
As far as I know, the C++ standard does not say anything about the
special floating representation (DRAFT 2 Dec 96, 3.9.1 (8)).

My point, however, is independent of that:
the standard treats set<float> and set<complex<float> > differently,
and I do not see any conclusive theoretical reason for that.

Helmut Zeisel <zeisel@vai.co.at> wrote:
> ncm@nospam.cantrip.org (Nathan Myers) writes:
>> Arguably one shouldn't put complex<float> values in a set, because
>> it implicitly involves comparing them for equality and float is
>> an imprecise representation: equality of floating-point values is
>> often illusory.  (E.g. assert(2.0 == sqrt(2.0)*sqrt(2.0)).)
>
>The same kolds not only for complex<float>, but also for float itself.
>You can use set<float>, however.

You had better be careful what you put in there.  less<float>
doesn't define a total ordering.  Unfortunately the compiler
probably will not warn you about this.

Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <6au77r$fbi$1@shell7.ba.best.com>, ncm@nospam.cantrip.org (Nathan Myers) writes:
> In article <34D1C28D.5EDB@pratique.fr>,
> Valentin Bonnard  <bonnardv@pratique.fr> wrote:
> >
> >I repeat the question: how can you say that C++ types can
> >be ordered but complex<> can't ?
>
> You can say it because if you try it out, set<char*> works,
> but set< complex<float> > doesn't.  Anything else is just
> hand-waving.
>
> It was pointed out, and the committee agreed, that pointers would
> be put in sets often enough to be worth special dispensation.
>
> Arguably one shouldn't put complex<float> values in a set because
> it implicitly involves comparing them for equality, and float is
> an imprecise representation: equality of floating-point values is
> often illusory.  (E.g. assert(2.0 == sqrt(2.0)*sqrt(2.0)).)
>

The same kolds not only for complex<float>, but also for float itself.
You can use set<float>, however.

Helmut


--
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <6b8mma$6ks@marianna.psu.edu>, Oleg Zabluda <zabluda@math.psu.edu> writes:
> J. Kanze <kanze@gabi-soft.fr> wrote:
>
> : So why is it called set, then.  This is NOT a characteristic of sets as
> : I know them.
>
> It's just an unfortunate choice of the name. The set should have been
> called linearly_ordered_set. There is a need for just set
> (no order whatsoever), partially_ordered_set (set of sets is an example,
> where 'less' means 'is a subset of'), linearly_ordered_set (that's what
> our standard set is), and about 20 other types of ordered sets, I don't
> even want to mention. What a nice way to introduce OO into STL :-).
> That would also introduce the opportunity to turn the notion of
> 'map' back into what god intended it to be, not what the programmers
> turned it into :-).
>

As I understand STL, it was not the intention to provide
a linearly_ordered_set. There was also a set implemented as hash table,
which was not included in the standard because it was difficult
to define it properly.
The ordering is an implementation detail,
the idea, however, was to obtain an efficient implementation of a set.

Maybe Alexander Stepanov can clarify this.

Helmut



--
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <fxtk9bwm7bz.fsf@isolde.mti.sgi.com>, Matt Austern <austern@isolde.mti.sgi.com> writes:
>
> No.  Defining less<typeinfo> might be reasonable, but defining
> less<complex<T> > would be a terrible mistake.  Complex numbers are
> not ordered.

I think you meant "... are not ordered in a natural way".
Every set can be ordered.
For the complex numbers you can
define e.g. the lexicographic order -
no order of the complex numbers, however,
provides the expected algebraic properties.

Ordering is needed when you want to use
a set<complex<double> > or a map<complex<double>,...>.
It is, however, not a bad decision that the user
of such a class has to specify an ordering that fits the special needs.

Helmut
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]