Re: Edge case conversions, exceptions to IEEE FPA
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. If the standard
only provides for one method, the other either isn't available, or has
to be done a harder way. The programmer should be able to say "convert
this FP number, which I know to be exact, to a point interval" or
"convert this FP number, which I don't know to be exact, to a 2ulp
interval," or, as has appeared recently in this thread, "convert this
number to an interval this wide" (a center+radius conversion). 0.5 is
exact. Euler's number (0.57721 56649 ...) isn't. Converting an inexact
single-precision FP number to an interval represented by
double-precision bounds ought to produce an interval 1 SP ulp wide.
The same argument holds for textual numbers, although with inexact
textual numbers one ought to be able to get 1ulp intervals.
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.
One way to avoid the controversy is for the standard not to provide any
functions to convert either FP or textual numbers to intervals. Rather,
provide a constructor and methods to say "evaluate this expression to
produce its rounded-down value", "evaluate this expression to produce
its rounded-up value," "produce the FP predecessor of the value of this
expression," "produce the FP successor of the value of this
expression," ....
Best regards,
Van
> Baker
>
> Van Snyder wrote:
> > On Mon, 2008-11-10 at 02:48 -0800, Arnold Neumaier wrote:
> >>> intval(0.1) -> (NEAREST(0.1,-1.0):NEAREST(0.1,+1.0))
> >> So you suggest to use inflation 2ulp wide for conversion of floats?
> >> What then about intval(0.5) or intval(0.5e1)?
> >
> > It is desirable to have two conversions from FP numbers to intervals.
> > In general, FP numbers already represent 2ulp intervals, but sometimes
> > one knows they are exact.
> >
> >>> intval('0.1') should become something sharper than intval(0.1).
> >> 1ulp wide?
> >
> > Hopefully. intval('0.5') could be a point interval. If the underlying
> > IEEE FPA is decimal, however, one might be tempted that
> > intval('0.3333333') ought to be a point interval. So again it may be
> > desirable to have two conversions from text to intervals.
> >
>
>
> --
>
> ---------------------------------------------------------------
> 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
> ---------------------------------------------------------------