[boost] Re: Proposal: Interval arithmetic library

From: Gabriel Dos Reis (Gabriel.Dos-Reis_at_[hidden])
Date: 2000-03-08 19:05:39

Jens Maurer <jmaurer_at_[hidden]> writes:

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

Agreed.

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

Agreed.  I do not use PROFIL/BIAS myself, but those with whom I'm
working use it every day (worse, they spend their time in trying to
integrate it into modern C++ software :-).  PROFIL/BIAS seems also to
have some preference on the reliable_computing list.

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

Terrific!

My intent was to point out that there are some amount of interval
software floating around and work being done by a dedicated
community.  It is my opinion that in order to acheive wide acceptance,
any boost-library addressing interval numerics has to acknowledge
existing practice.  I'm glad to see, we're in agreement here.

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

From a template-based point of view, a non member function is
preferable.

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

lower_bound(), 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,

I'd vote for a.contains(b), but...

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

I'm for width().

|  (5) I personally think the dist() function has an unintuitive
| name.

Me too.

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

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?

Why not spell them out in full?  As said earlier, it would be
preferable if they're non-members.

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

I think we should be very careful in choosing operator-names when we
choose to overload some random operator.  In this case I do think that
intersect() is perfectly reasonable. operator& isn't that
obvious/intuitive. 

|  (9) intersect() or intersection()?

Both are fine with me.

|  (10) After my experiments with the Matrix Template Library, I'm
| fairly certain that "x < y" should mean "x.upper() < y.lower()".

Agreed.

[...]

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

Good!

-- Gaby