Boost logo

Boost :

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
| (thanks to Gabriel).
| RVInterval 1.1.1 (
| 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.


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


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

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


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

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



| 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, and I'll post
| a message to the reliable_computing mailing list regarding
| semantic issues and naming.


-- Gaby

Boost list run by bdawes at, gregod at, cpdaniel at, john at