From: Gabriel Dos Reis (gdr_at_[hidden])
Date: 2002-09-06 16:33:25
Sylvain Pion <pion_at_[hidden]> writes:
| On Fri, Sep 06, 2002 at 09:22:45PM +0200, Gabriel Dos Reis wrote:
| > However, the point is what makes more sense in practice *and* in the
| > surrounding framework of the enclosing library (not just IA). Give it
| > more thought.
| Here are my thoughts :
| Given the high similarity with std::complex, consistency with std::complex
| is a serious option, right ?
Several people have proposed to add a std::less<complex<> >.
(I certainly would like to see something similar ge into the the next
version of C++).
| The lexicographic order clashes with ALL existing practice over intervals !
| I don't know of any existing IA library defining the default comparison as the
| lexicographic one. And they all come from slightly/completely different
| > | The lexicographical order on the cartesian
| > | coordinates would not make any sense for a different application that your
| > | mapping of points !
| > You missed the point -- no pun intended. As I explained in another
| > message, the actual implementation of the ordering was immaterial in
| > the application (either in polynomial root finders or curvature line
| > tracing). However, given the actual *representation*, anything other
| > lexicographical would have been exercise in pure futility -- the
| > observable behaviour of the program would not have been affected,
| > however. Don't forget that std::complex<> does use Cartesian
| > representation.
| Agreed, but you may perfectly want to have a non-standard class with the same
If you have a non-standard class, then it is not std:complex<>,
therefore, there is no issue about std::less<std::complex<> >.
If you have a different
| interface _and_ associated semantic, and whose internal representation is
| polar, or homogeneous. For these, the corresponding semantic of Cartesian
| lexicographic order would be non-sense.
Certainly, but then the ordering won't be std::less<sd::complex<> >.
Don't confuse abstractions with their models.
| > Don't over-abstract. Or you'll get where we're with std::complex<> --
| > a perfect example of standard over-abstraction.
| It seems that we agree that interval and complex are really equivalent beasts
| on this topic.
| So all boils down to the fact that you think the standard is wrong for
| complex, and you would like to push your view on boost::interval.
All I'm saying is that the over-abstraction put in std::complex<> is
NOT an example to reproduce; it is an example to avoid. Let's not
repeat the mistake.
| May I mention that I therefore have the majority of the standard commitee
| on my side ? :)
How did you make the count?
| More seriously, I do not know what have been the discussions of the standard
| commitee (you surely know better) about this question, if there has been any.
| But may I suggest that you _first_ try to get the std::complex "fixed" with
| the standard working groups.
As you might probably know, I can't speak for the committee. But I
can point out mistakes made in the past and argue against reproducing
them. With your reasoning, any new library should follow all
imaginable mistakes made in the standard, and correct them only *after*
the standard issued a TC. IMHO, that is a nonsensical approach to
library design especially when we know of the mistakes and we know we
would have done better had we debatted of the issues much deeply.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk