[std-interval] Current draft of the proposal for std::interval

[Hervé Brönnimann]

Peux tu stp repondre a ton courrier et donner un pdf au lieu d'un  
ps.gz?  C'est plus portable...
Merci.
--
Hervé Brönnimann
CIS, Polytechnic University
hbr at poly.edu


On Feb 24, 2006, at 12:34 PM, Guillaume Melquiond wrote:

> Dear subscribers,
>
> First, a bit of history. We (Hervé Brönnimann, Guillaume Melquiond,  
> and
> Sylvain Pion) have written a C++ library for interval arithmetic  
> that is
> part of the Boost project. This work gave us a better understanding on
> how to provide interval arithmetic in C++. So we submitted a proposal
> for adding this arithmetic to the C++ Standard Library. We had decided
> that the template classes would be simple, and in particular that they
> would not be policy-based, contrarily to the Boost library.
>
> This proposal was presented during the Fall'05 meeting of the C++
> standardization committee. It was rather well received, but developers
> of implementations of the STL were concerned whether there was or  
> not a
> sufficient user demand for interval arithmetic.
>
> Anyway, we have decided to submit a revised version of the proposal to
> the Spring'06 meeting. Since the first release of our proposal, a  
> lot of
> comments have been sent to us and we have tried to take them into
> account. This is a draft of our revised proposal. Please note that
> interval comparisons have been temporarily left aside from this draft
> because we have yet to converge on a syntax.
>
> Among these comments, a major concern was the kind of interval
> arithmetic. The current proposal implements an arithmetic that is  
> usable
> for doing forward evaluation on the set of real numbers. Some would  
> like
> the computations to be on the set of extended real numbers: it  
> would for
> example allow <0,inf> * <1,inf> = <-inf,inf>. Some would like the
> computations to have backward propagation properties: <0,0> / <0,0> =
> <-inf,inf>. Some would like both forward and backward semantics in  
> order
> to do global optimization. And so on.
>
> As long as intervals have finite bounds and do not contain zero, all
> these semantics are equivalent. But in presence of infinities and  
> zeroes
> (that is as soon as there is an underflow or an overflow on the
> floating-point bounds), these various arithmetics produce incompatible
> results. And they all have their own use cases. As a consequence, this
> is the main point left unsolved.
>
> We are interested in your comments on this draft.
>
> Best regards,
>
> Hervé, Guillaume, and Sylvain
>
> <interval.ps.gz>
> _______________________________________________
> Std-interval mailing list
> Std-interval at compgeom.poly.edu
> http://compgeom.poly.edu/mailman/listinfo/std-interval