[boost] Re: Proposal: Interval arithmetic library

From: Maarten Keijzer (mak_at_[hidden])
Date: 2000-03-09 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 far-fetched for me, so 
>I don't want to implement it.

I agree it is far-fetched, 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
>single-argument 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
DK-2970  Hørsholm
Denmark
Phone: [phone]
Direct phone: [phone]
Fax: [phone] 
email: mak_at_[hidden]
******************************************