[boost] Re: Proposal: Interval arithmetic library

From: jsiek_at_[hidden]
Date: 2000-03-08 18:08:29

Jens Maurer writes:
 > So let's take all these things and merge a decent approach out
 > of them.

Sounds good!

 > There are some general issues:
 > 
 >  (1) Do we prefer member functions or global ones for interval-
 > specific operations?  Where the C++ standard sets a precedent
 > (abs, exp, etc.), the decision is easy.  For symmetric functions
 > such as intersect() or hull(), I would vote for global functions,
 > but what about median() and contains()?

I would vote for global functions throughout. Globals have the
advantage that someone can take some old interval class (or even
struct) and independently add global functions to make it
interoperable without directly changing the old interval class
itself. (I think this is important as a general principal).

 >  (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().

Yes, that sounds good... would encourage client code to be uniform.
lower()/upper() would probably be best since they are commonly
referred to the lower bound and upper bound.

 > 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.

I suppose one could also have a.subset(b). However, I think the
advantages of global functions out-weigh the difference in
readability.

 >  (4) What's better, my width() or Jeremy's diameter()?

width was used in Baker Kearfott's book, which was suggested
for the standard notation

 >  (5) I personally think the dist() function has an unintuitive
 > name.  For me, it sounds like "the shortest distance between
 > the two arguments", which it isn't.

I'll keep an eye out for a better name...

 >  (6) I think that empty() is superfluous, interval::is_nan() should
 > be enough.  However, an empty() which says "width() == 0" might
 > be useful.

Ok

 >  (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?

pos_sect/neg_sect sounds good.

 >  (8) operator& for intersect() seems a bit too far-fetched for me, so 
 > I don't want to implement it.

Ok, that's fine.

 >  (9) intersect() or intersection()?
 >  (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.

Ok, and that semantics matches Baker's suggestion.

I think the added complexity of the mayflies is not worth it in this
situation.

 >  (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.)

That's fine.

 > I'll post an update with the obvious improvements to the
 > docvault soon.  After I got some opinions on the open issues,
 > Beman should upload a version to www.boost.org, and I'll post
 > a message to the reliable_computing mailing list regarding
 > semantic issues and naming.

Great.

Cheers,

Jeremy