Re: [boost] Interval Library and comparison operators

From: Gabriel Dos Reis (gdr_at_[hidden])
Date: 2002-09-06 20:17:39

Sylvain Pion <pion_at_[hidden]> writes:

| On Fri, Sep 06, 2002 at 11:33:25PM +0200, Gabriel Dos Reis wrote:
| > | Given the high similarity with std::complex, consistency with std::complex
| > | is a serious option, right ?
| > 
| > Wrong.  
| 
| But your following argument is not againt inconsistency, you just argue that
| std::complex is buggy.  Which is not the same thing at all.

Well, my point is that new libraries should try to avoid existing
std::complex<> pitfalls.  I'm -not- found of the idea of reproducing
errors just for hypothetical consistency, especially when the existing
errors are subject to debate. 

| Anybody can make a proposal and discuss.

Mr. Lapalisse won't disagree with you on that.

| But is it (has it been ?) debated in some WGs ?
| What are the chances, and of which resolution, in the next revision ?

I'll tell you after the next meeting -- I expect we'll get chances to
discuss other numerical isssues.

| That's the real question that I'd like to see solved before we decide if the
| same arguments also apply to boost::interval.

Well, I don't think you really need to wait for the std::complex<> issues
being officially solved before you avoid the its mistakes -- if they are
corrected they won't be published in 2002 since the C++02 final draft
is already sent out.

| I have not seen these arguments
| myself behind your claims of "past mistakes".  How do I differentiate that
| from your own opinions ?

Oh, you might want to go back to discussions in csc++ in 1997-1998.
(I don't have the exact references handy, but I know the first time the
issue was brought up near FDIS time was around that time).  I do
however recall a famous sentence from Theo Papadopoulo:

   Now, NOT HAVING sets for complex numbers is mathematically as silly as
   having an operator< for  those !!!

(Yes, that is taken out of context, but since you're believeing that
I'm push my opinions on you, you might probably have another view if I
cited an opinion from one of your former co-workers.  Well maybe you
think you don't care about Theo's writing, in the case you might want
to search the discussion on csc++).

| interval is not standard and can evolve anyway,

Yeah, but it doesn't need to wait for std::complex<> issues solved
before avoiding them.

[...]

| Yep, but I assumed std::less and opertor< were supposed to have the same
| meaning

That is not clear.  A counter example is operator< for pointers.
Peter made arguments for making them behave identically.

[...]

| > 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.
| 
| It's your view that it's a mistake.
| Does everybody obviously shares this view ?

The Boost mailing list certainly should record discussions about the
fact of requiring std::complex<> layout compatible with similar
datatypes in other languages (e.g. C99 _Complex)

| Personnaly, I don't really feel that std::complex is overly over-abstracted,

The standard says std::complex<> does tsore Cartesian coordinates, yet
there is no way of having the rela and imaginary parts as lvalues --
with the unfortunate consequence that you can directly change the
imaginary part of a complex.  With no benefit.  You can't even assume
it works like C99 _Complex, yet *existing* numerical software operate
under that assumption.

What are the benefits of not accessing the individual components as
lvalues?  None.  On the other hand, there are many disavatanges.  An
over-abstraction for nothing.

I even saw a proposal from some Boosters to make std::complex<> (or
was is std::pair<>?) behave like an "almost POD". Dave Abrahamm, wasn't
you the author of that proposal?

| but I'm used to abstraction as you noted.

It is not a question of being used to.  

It is how it makes code reuse or interporability uneasy for no
*practical* gain.  After, sufficient time I'm certain you'll get used
to a given assembly language but you won't propose to write all CGAL
in assembly language.  Would you? 

| I must admit that I miss the key arguments behind this claim.
| The lack of std::less specialization cannot really be that, right ?

It is one of them.  As with the proposed interval library, concatenating
smallish issues together finally gets big and irritating.  

| > | May I mention that I therefore have the majority of the standard commitee
| > | on my side ? :)
| > 
| > How did you make the count?  
| 
| Simply because IF (I don't know) the issue has been discussed before rejection
| (I just look at the standard which tells me there's no such order, so I
| conclude it has been rejected if the issue has been considered),

But the standard didn't discuss interval.  If you're talking about
std::complex<>, then you don't know whether or not the issue was ever
discussed. You need to read the actual minutes (and I'm not sure
everything is recorded). 

| then I
| presume it is the consequence of a vote (any reasonnable comitee has a voting
| procedure, right ? :), whose majority decided for the rejection.
| Am I wrong ?

That reasoning is flawed.

Taking your reasoning further, the committee should not be discussing
defects at all, which obviously is silly.

[...]

| So to recap :
| you suggest specializing std::less<boost::interval<>> to be the lexicographic
| order.  It either means that std::less will have a different meaning than
| operator<, or it means that operator< has a useless arithmetical sense.

operator< already isn't really arithmetical on floating point types
supporting common IEEE-754.  So the argument of arithmetical sense for
operator< is a non-issue.

[...]

| Or let operator< have no arithmetic sense ?
| ( I do have a strong opinion against this one. )

I have no strong argument against having operator< behaving like
std::less<> which is lexicographical.

-- Gaby