Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: float to interval and (float,float) to interval



Van et al,

Please see my inserted comments.

Baker

Van Snyder wrote:
On Mon, 2008-11-10 at 06:32 -0800, R. Baker Kearfott wrote:
.
.
.

Again, in what context?   Also, using other than 754 types would
complicate 1788's task.  We should consider what it would gain us
if we did so.

The proposal from IFIP WG 2.5 to P754 preferred that intervals be
provided with bounds represented by all types the implementor of 754
provided.

My perception (subject to refutation by others) is that such would
be a bit of a luxury, unless it is simple and convenient to do so.
(It may be, especially if the interval arithmetic is tied closely
to the floating point arithmetic.)

Conversion between interval representations was not
addressed, bug should have been.  Rounding the bounds outward seems like
the only sensible definition, unless one knows for sure that one or the
other bound is exact.

Yes. Again, I would advocate rounding according to the round-down
and round-up already specified in 754-2008 for the floating point
conversions.  I remind everyone that the underlying principle is
that the result of the operation should contain the exact answer (and
this is a mathematically rigorous statement).  Furthermore, if
754-2008 specifies accuracy (such as, for rounding down, "the result
is the nearest number in the system less than the exact result"), then
there is no reason why the interval standard should not demand
corresponding accuracy (which translates to "narrowness").

Providing conversions with flags that indicate
that one or the other bound is exact seems like too much complication,
at least for a first edition standard.


I agree.

Constructors of intervals from pairs of FP numbers are obviously needed.

Yes.

In this context, should the FP numbers be considered to be exact?

Yes.  Nothing else can be assumed otherwise.  The user can look at
the standard, and if the user understands the principle of automatically
verified computation, we will be providing that user with a tool upon which they
can construct their code with confidence.  Rounding out pairs of floating point numbers
does such a user a disservice, and still will not protect other users
from producing results that do not contain the mathematically exact
result.

If
only constructors that take the same type bounds are offered, and can
only produce intervals having a representation consisting of the two FP
given numbers, there is no need to consider whether one or the other
bound is inexact.  Presumably, if one decomposes an interval into two FP
numbers, however, and then converts those FP numbers to a different
precision, and then re-composes them into an interval, it would be
desirable to round (or not) each one correctly.

Yes, if we provided intervals for different data types,
the emphasis would be on "correct rounding."  I believe that's all
we need.  Multiple conversions, however, might expand the width of
the resulting intervals a bit.  That is unavoidable, because it would
be necessary for mathematical rigor.  Ideally, such multiple conversions
would be optimized out at a higher level (perhaps by hand, to avoid
automatic optimization that makes implicit assumptions that cause
the answer not to be correct in some cases.)

I think P754 can
already convert from one precision to another with directed rounding.


YES!!!


--

---------------------------------------------------------------
R. Baker Kearfott,    rbk@xxxxxxxxxxxxx   (337) 482-5346 (fax)
(337) 482-5270 (work)                     (337) 993-1827 (home)
URL: http://interval.louisiana.edu/kearfott.html
Department of Mathematics, University of Louisiana at Lafayette
(Room 217 Maxim D. Doucet Hall, 1403 Johnston Street)
Box 4-1010, Lafayette, LA 70504-1010, USA
---------------------------------------------------------------