[boost] Re: Proposal: Interval arithmetic library

From: Jens Maurer (jmaurer_at_[hidden])
Date: 2000-03-08 16:48:03

I've had a look at the two C++ interval classes offered at  http://www.cs.utep.edu/interval-comp/main.html
(thanks to Gabriel).

RVInterval 1.1.1 (http://www-math.cudenver.edu/~rvan/Software.html)
is quite old (iostream.h etc.), has no documentation, is not templated,
doesn't have binary operators as free functions (this hampers automatic
type conversion), but does have transcendental functions.

PROFIL/BIAS (http://www.ti3.tu-harburg.de/Software/PROFIL.html)
is quite old (iostream.h etc.), has no documentation, is not
templated, uses reserved identifiers for include guards, has
lots of preprocessor symbol space pollution, has no transcendental
functions, and has no copyright information.

interval-1.0 by Jeremy Siek (thanks for the code) is quite modern,
has documentation, is templated, has trancendental functions, but
is only usable for non-commercial stuff, thus it is incompatible
with boost copyright policies. In addition, it has several places
where it re-implements std::min() or std::max(), I don't like
the non-const accessor functions, pred() can return a non-proper
interval, and it defines isnan(), although in my implementation of
ISO C99 (gcc 2.95.2, glibc 2.1.2), it's a macro (you may call that
a design error).

So let's take all these things and merge a decent approach out
of them.

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

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

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.
 (4) What's better, my width() or Jeremy's diameter()?
 (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.
 (6) I think that empty() is superfluous, interval::is_nan() should
be enough.  However, an empty() which says "width() == 0" might
be useful.
 (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?
 (8) operator& for intersect() seems a bit too far-fetched for me, so 
I don't want to implement it.
 (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.
 (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.)

Please help me with suggestions.

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.

Jens Maurer