Thread Links |
Date Links |
||||
---|---|---|---|---|---|

Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |

*To*: Van.Snyder@xxxxxxxxxxxx*Subject*: Re: Edge case conversions, exceptions to IEEE FPA*From*: Arnold Neumaier <Arnold.Neumaier@xxxxxxxxxxxx>*Date*: Mon, 10 Nov 2008 11:48:37 +0100*Cc*: "Siegfried M. Rump" <rump@xxxxxxxxxxxxx>, stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>*Delivered-to*: mhonarc@xxxxxxxxxxxxxxxx*In-reply-to*: <1226107692.26045.453.camel@xxxxxxxxxxxxxxxxx>*List-help*: <http://listserv.ieee.org/cgi-bin/wa?LIST=STDS-1788>, <mailto:LISTSERV@LISTSERV.IEEE.ORG?body=INFO%20STDS-1788>*List-owner*: <mailto:STDS-1788-request@LISTSERV.IEEE.ORG>*List-subscribe*: <mailto:STDS-1788-subscribe-request@LISTSERV.IEEE.ORG>*List-unsubscribe*: <mailto:STDS-1788-unsubscribe-request@LISTSERV.IEEE.ORG>*Organization*: University of Vienna*References*: <200810311555.m9VFtNru005903@xxxxxxxxxxxxxxxxxxx> <op.ujxpwjm5v059od@xxxxxxxxxxxx> <490EC8FA.3080302@xxxxxxxxxxxx> <op.uj5ac6agv059od@xxxxxxxxxxxx> <49119AE0.5070001@xxxxxxxxxxxx> <4471533ED9154CF892A590B5538A1563@proton> <491404B2.9020108@xxxxxxxxxxxx> <op.uj8yncn5v059od@xxxxxxxxxxxx> <491431F7.509@xxxxxxxxxxxx> <op.uj9a1za7v059od@xxxxxxxxxxxx> <491471C0.70501@xxxxxxxxxxxx> <1226107692.26045.453.camel@xxxxxxxxxxxxxxxxx>*Sender*: stds-1788@xxxxxxxx*User-agent*: Thunderbird 1.5.0.14ubu (X11/20080925)

Van Snyder schrieb:

On Fri, 2008-11-07 at 08:50 -0800, Arnold Neumaier wrote:This is why I had proposed to convert +inf into the interval [realmax,realmax], -inf into the interval [-realmax,-realmax], NaN into the interval [0,0] (for symmetry reasons, and since 0*inf=NaN suggest that in floating-point arithmetic, NaN is a limiting form of zero), and to raise the nonstandardNumber flag as in Section 2.1 of my proposal (Version 2.0).I assume the reason for this is to avoid exceptions from the behavior of P754 when interval arithmetic is built atop it. If P754 had defined 0*inf to be zero instead of NaN, would your conversions be different?

I find myself defending a mere suggestion before it has been commented on by Siegfried, who

If no arithmetic operation of floated different from NaN would give NaN, one would not need to convert NaN.

Arnold's conversion suggests that +realmax represents {x|x>=+realmax}.

No.

In Siegfried's sproposal, realmax is converted to itself, and inf to [realmax,inf] = {x|x>=+realmax}.

Therein, intval(+realmax) -> [+realmax,+realmax], so there is no difference between +realmax and +inf, and we might as well use +inf. If P1788 is based upon P754 we still have the problem that [a,+realmax]+ [b,+realmax] -> [a+b,+inf] with overflow signaled.

Should the IA implementation trap the overflow signal and convert the interval to [a +b,+realmax]? How is this different from leaving the result as [a+b, +inf]?

No.

This would remove the above strangeness.I think it just moves the strangeness somewhere else.

inf is needed as a bound, and this is uncontroversial.

Somehow, my suggestion seems to have missed your attention. Please comment on this proposal to modify the interpretation of +-inf and NaN. With this interpretation, fixed operations could be handled at about the same cost as with the interpretation in my proposal (Version 2.0). With nonreal floating-point numbers interpreted as empty, we'd have to convert a=+-inf to NaN before execution of formulas such as a+[l,u] = [a+l,a+u], etc., while with the above proposal, we'd convert a=+-inf to +-realmax and a=NaN to 0 before execution. And similar for formulas based on explicit case distinctions. Then mixed arithmetic operations with floats and intervals will never result in the empty set.In the proposal that I prepared for P754 from Ulrich's work (I acted purely as editor -- I didn't change any of his mathematics), empty sets arose during division [x,y]/[0,0] when x>0 or y<0. So it seems empty sets arise, although perhaps not from operations between points and intervals.

proposal (v2.0), and this would remain so even with the above modification. But mixed arithmetic operations with floats and intervals will

in it.

Consideration of the exceptional cases from a computational perspective, leads me to believe that if intervals represented by two IEEE objects other than NaN are considered to be open (in the real-number sense, not the FP number sense), IA can be based upon IEEE FPA with only a few exceptional cases mentioned below, and the sign of zero can be ignored. I,ve just done some hand-waving about limits, but haven't otherwise thought this through from a mathematical perspective. If any interval with NaN as either boundary is specified to represent the empty set, IEEE FPA causes any operation in which an operand is the empty set to produce an empty set as the result. I think this the desired behavior. Fortran's notation for intervals of integers is I:J (so far, this exists only for subscripts but ought to be extended to first-class integer-based objects and would be a natural program notation for FP-based intervals). I use this notation to distinguish what follows from what we have been discussing in this forum. For the same reasons, I use Fortran's HUGE and TINY. Unless explicit otherwise, HUGE and TINY are taken according to the precision of the context, i.e., either HUGE(1.0e0) or HUGE(1.0d0), etc., as necessary. I interpret the single object IEEE +inf to repesent {x|x>+HUGE}, not thepoint \infty.

In the notation of intervals as pairs of floats representing endpoints,

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))

So you suggest to use inflation 2ulp wide for conversion of floats? What then about intval(0.5) or intval(0.5e1)?

intval('0.1') should become something sharper than intval(0.1).

1ulp wide?

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) Using IEEE FPA, (a:+inf) - (b:+inf) -> (a-b:NaN) = the empty set. T

No. (a:+inf) - (b:+inf) -> (a-inf,+inf-b) = (-inf,inf).

With the above definition of subtraction and bounds overflow, interval addition and subtraction can be built on IEEE FPA without exceptions.

The problems with the conversion of +-inf and NaN has nothing to do

completely separate issues. Arnold Neumaier

**Follow-Ups**:**Re: Edge case conversions, exceptions to IEEE FPA***From:*Siegfried M. Rump

**Re: Edge case conversions, exceptions to IEEE FPA***From:*Van Snyder

**Re: Edge case conversions, exceptions to IEEE FPA***From:*R. Baker Kearfott

**References**:**Re: Alternate floating-point results under directed rounding***From:*Siegfried M. Rump

**Re: Alternate floating-point results under directed rounding***From:*Arnold Neumaier

**Edge case conversions, exceptions to IEEE FPA***From:*Van Snyder

- Prev by Date:
**Version 2.11, Proposal for interval standardization** - Next by Date:
**Re: Alternate floating-point results under directed rounding** - Previous by thread:
**Edge case conversions, exceptions to IEEE FPA** - Next by thread:
**Re: Edge case conversions, exceptions to IEEE FPA** - Index(es):