Alternate floating-point results under directed rounding
Arnold Neumaier wrote:
> Nobody so far suggested seriously to convert by epsilon-inflation.
As Arnold already noted a bit later, Van Snyder did, but ALSO
supported conversion to point intervals, if I understood his
(Fri, 07 Nov 2008 17:28:11 -0800) proposal correctly:
> intval(inf) -> (HUGE:+inf)
> intval(-inf) -> (-inf:-HUGE)
> intval(1.0e40) = intval(sinf) -> (HUGE(1.0e0):sinf)
> intval(1.0e400) = intval(sinf) -> (HUGE(1.0e0):sinf)
> intval(1.0d400) = intval(dinf) -> (HUGE(1.0d0):dinf)
> intval(1.0d40) -> (NEAREST(1.0d40,-1.0d0):NEAREST(1.0d40,+1.0d0))
> intval(0.1) -> (NEAREST(0.1,-1.0):NEAREST(0.1,+1.0))
> intval('0.1') should become something sharper than intval(0.1).
> intval(NaN) -> (NaN:NaN) = the empty set
> intval(x,y) -> (x:y) provided x <= y and either x or y is finite.
> If either one is NaN the result represents the empty set.
> intval(-inf,-inf) -> (-inf:-HUGE)
> intval(+inf,+inf) -> (+HUGE:+inf)
In other words, intval() may take one or two arguments; the former
implies epsilon-expansion, and the latter permits actual bounds to
be specified, so that intval(x,x) is a point conversion.
The standard should specify the availability of both types of conversion,
without tying down the syntax. The standard may require that there be
a single-argument epsilon-expanding conversion, in order to facilitate
language or environment definitions that define this to be the means of
automatic type conversion. If modes are appropriate, there could be a
mode (static or dynamic attribute, in the 754-2008 sense, hence possibly
under program control) to select whether point-conversion or expansion
should be used. In either case, if ACTUAL conversion is involved (e.g.
because of type narrowing or base change), two-way rounding should be
used to derive the interval.
Sent: 2008-11-10 15:40:49 UTC