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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk