Re: [boost] Formal Review for Interval Library beginning

From: Herve Bronnimann (hbr_at_[hidden])
Date: 2002-09-03 12:19:05

On Tue, Sep 03, 2002 at 05:41:23PM +0100, Paul A. Bristow wrote:
> There is a very clear need for an interval arithmetic package,
> and I believe this provides what is needed.  Indeed, a very impressive
> amount of thought and work and detailed testing has gone into it.

Thank you.

> I vote immediately for acceptance.

AFAICT, you are the first person to comment and say so. Thank you again :)

> However, I think the documentation and examples do not help those
> whose mathematical knowhow is/was inadequate, obselete and/or decayed.
> Like it or not, many potential users (including me) fall into this category,
> and it would be a shame to deter them for want of assistance on the first
> step.

Granted. Our aim was to present the library completely and in enough
detail that everything is covered. More care could (and should) be taken
into adding examples, links, etc. But we did not want to sidetrack
ourselves into doing the interval gospel. Rather, we wanted a finely
tuned and effective interval library.

> Even symbols like [] and the box [_] are not obvious to non-mathematicans.

We'll add a comment about the notation.

> The difference between std::max and min and interval max and min is
> not obvious, badly needs examples, and of usage, and perhaps should
> have a different name?  The functions are rather tersely defined and
> examples would be very helpful.

I agree. 

> References and/or links to math texts (if even they are 'standard' to
> mathematicians) seem an essential and very easy addition.

That is very true. The URL which is mentioned indirectly at the end has
this and much more:

  http://www.cs.utep.edu/interval-comp/main.html

We'll add it directly into the documentation.

> I would have found some more elementary examples of use helpful.
> (But I was impressed by the detailed testing examples).

The examples are in the libs/interval/examples directory, if this is
what you are referring to. And yes, I would have liked to provide a
short page for each, but did not find time to. This could (and should)
be done after the review.

> And an example of use with a bigint type would provide proof of
> extensibility.

True. There was/is noise of a fixed-point computation and a bigint 
library in boost. This would go a long way to demonstrate extensibility.

Otherwise, we do not want to rely on other packages too much, but some
work was done by Sylvain Pion within his interval arithmetic package for 
CGAL. Perhaps he will comment. Anyway, I am confident that such
extensibility is not out of reach.

> On a detail, I note that PI is only defined to 21 decimal digits,
> which might be insufficient for some potential uses.  Why is it not
> just defined to 40 decimal digits, sufficient for any foreseable
> floating point hardware, even allowing for the known need for a few
> extra digits - see Kahan's paper.  We should be able to assume that
> the compiler will convert this to the best representation that is
> possible for the floating point type, (if it doesn't then it is not
> compliant).  Then shouldn't + and - numeric_limits epsilon, pred and
> succ, or nextafter(x, +inf) and (x,-inf) function provide the pi()
> interval values?

I think Guillaume (who wrote that part of the code) will comment, but I
do not think that the compilers offer the best string-to-internal-float
conversion. It is common to see the last two or three LSBits wrong.
I do not know either if it is mandated by the standard.

> Finally I note that there remains a need for an even more complex
> system to handle the uncertainty of real physical measurements whose
> statistical properties (distribution, for example, gaussian or
> rectangular, degrees of freedom etc) are known., and need proprgation
> through calculations.  This package deals with the computational
> 'uncertainty' and provides a foundation on which in future to handle
> what we also know about the measurement uncertainty.

A very interesting thought, to connect to the distributions found in the
Boost.random library, perhaps? But definitely out-of-scope for this
library.

Thanks for your fair and interesting comments.
-- 
Hervé