On Tue, 2008-11-11 at 04:09 -0800, R. Baker Kearfott wrote:
Van et al,
I still don't understand why we need two conversions from floats
to intervals. As several have pointed out, we have no way of
knowing how the float originated, so we cannot prescribe rigorous
bounds on the accuracy. "Widening" a float hence still will
not give a rigorous enclosure in general. We simply need to
clearly specify how the standard converts the float, so users
will have a reliable tool upon which to design procedures that
are mathematically rigorous.
At the instant a program executes a conversion from FP to interval, it
doesn't know whether the FP number is exact or represents a 1ulp wide
interval. Frequently, however, the programmer knows.
People will be introducing interval methods into legacy codes. If they
have inexact processes in them, such as quadratures or zero finders or
least squares, they will want to convert their outputs to intervals with
widths estimated by those codes -- at least until those codes are
replaced by interval methods. Most special-function codes don't return
error estimates, but you know their results aren't exact. Until one has
interval versions of them, although you might have to guess the interval
width, it's better to produce a nonzero-width interval than a point
interval.