
Boost : 
From: Maarten Keijzer (mak_at_[hidden])
Date: 20000309 04:41:54
At 10:58 PM 3/8/00 +0100, you wrote:
> (2) Unique naming for the functions. I think that there should
>be a single name for a given functionality. For example, for
>the lower interval bounds, we have the choice of lower(), left(),
>and inf().
I think inf() and sup() are mathematicaly sound, short and clear.
>
>
>Specific issues:
>
> (3) I never know whether subset(a,b) is one way or the other,
>but a.contains(b) looks much more intuitive to me. However,
>we have to fit proper_subset into this scheme as well.
>properly_contains() sounds awful.
An alternative could be b.in(a), to check if b is a subset of a. b.in(a) &&
!a.in(b) would be the check for a proper subset. For people acquinted with
set theory this follows that notation as close as possible.
> (4) What's better, my width() or Jeremy's diameter()?
width(). With diameter I'm usually thinking (in) circles, not lines. You
might consider range(), though I think width() is superior.
> (6) I think that empty() is superfluous, interval::is_nan() should
>be enough. However, an empty() which says "width() == 0" might
>be useful.
is_point()? point_interval()? Or something better. Empty to me means
there's nothing in it: here it means that there's a single point.
> (7) pos_half() and neg_half() sound like they return something
>like width()/2, which they don't. What do you think about pos_sect() and
>neg_sect()? Should that be a member function or a global one?
I don't see much use for this functionality, but then again, my use of
intervals is quite limited to checking bounds. To provide a better building
block it might help to add static functions like
largest_positive_interval() and largest_negative_interval() that return
just that. You can then intersect that interval with your own.
Come to think of it, does neg_sect() include zero? Should it include
negative zero if that exists on your platform?
> (8) operator& for intersect() seems a bit too farfetched for me, so
>I don't want to implement it.
I agree it is farfetched, especcially without a unifying operator.
> (9) intersect() or intersection()?
global: interval intersection(...)
member: bool intersects(...)
> (10) After my experiments with the Matrix Template Library, I'm
>fairly certain that "x < y" should mean "x.upper() < y.lower()".
>However, there is also the interpretation "there exists some a in
>x and some b in y so that a < b". Jeremy called this "possibly
>less than". We can have global functions like "poslt" for it, or a
>separate mayfly class with appropriately overloaded operators so we
>could write "possibly(x) < possibly(y)". It's more typing, though.
I think operator< should obey:
!(x < y) && !(y < x) implies x == y
So that the default implementation fits in a std::map. So that would
probably mean:
(x.sup() == y.sup())? x.inf() < y.inf() : x.sup() < y.sup();
> (11) Jeremy has two constructors, one saying "the bounds are exact",
>the other "make the bounds a bit larger, just to be sure". My
>policy differs and is as follows: If you specify the interval
>bounds, they're assumed to be exact. If this is not what you mean,
>call succ() on the constructed object. (We agree that the
>singleargument constructor yields a very small interval around the
>given value.)
this seems to be quite reasonable.
just a few suggestions.
Maarten
******************************************
Maarten Keijzer
DHI Water & Environment
Agern Allé 11
DK2970 Hørsholm
Denmark
Phone: +45 45 16 92 00
Direct phone: +45 45 16 93 52
Fax: +45 45 16 92 92
email: mak_at_[hidden]
******************************************
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk