Re: Overflow and Inf
AN> The real question is whether a (hardware or software) implementation
AN> that produces +-DirectedInf in place of Inf whenever an operation with
AN> directed rounding to +-Inf overflows is still 754 compatible.
I believe it is not 754 compatible.
The other question I think is important is how that +-DirectedInf would be represented. What bit pattern would be used? In BFP (Binary Floating Point), every bit pattern already as a meaning. That's the reason for my previous email listing possible implementation approaches.
AN> If it is, everything is fine, and we can recommend implementors to
AN> create and prefer this version.
AN> Initially, this may be done in less efficient ways; ultimately it will
AN> be done by all implementations, and as efficiently as the current
AN> implementations, since hardly anything but applications for rigorous
AN> computations uses directed rounding anyway.
Unfortunately 754 already specifies the meaning of rounding modes, and there are real uses of their current meanings (and not rare, since some of the uses are hidden inside library functions). They could not just be redefined, unless there was a new mode. The more likely possibility would be to have new rounding modes instead of redefining the existing ones.
The representation of DirectedInf would still be an issue.
AN> If it is not, then redefining operations using either DirectedInf
AN> or Overflow will violate 754, and hence must be simulated on top
AN> of a 754 compatible architecture. In this case, is very unlikely
AN> that either of these gives an advantage over a direct simulation
AN> of the exceptional cases that arise in the treatment of unbounded
AN> (and empty) intervals.
It is not. Neither is Overflow, which is why I described it originally as wishful thinking. Sometimes wishes come true, according to the good witch in Oz, if you want them to enough and do the right things. So we should be considering whether and how a future 754 standard might be able to be changed, what we would want it changed to, and how to sell that (preferably also for the benefit of non-interval users). The first step is what we are doing now - discussing what we would want it changed to.
- Ian McIntosh IBM Canada Lab Compiler Back End Support and Development
Arnold Neumaier ---09/29/2010 02:59:47 PM---Ian McIntosh wrote: >
From: |
Arnold Neumaier <Arnold.Neumaier@xxxxxxxxxxxx> |
To: |
Ian McIntosh/Toronto/IBM@IBMCA |
Date: |
09/29/2010 02:59 PM |
Subject: |
Re: Overflow and Inf |
Ian McIntosh wrote:
>
> I also have the problem of having other things to do besides 1788, so I
> sympathize. I expect all of us are busy. I will reply to some other
> emails containing misinformation soon. In the meantime:
Thanks for the details!
> Adding Directed Infinity to 754 involves all the same considerations as
> adding Overflow, and in fact they are closely related. In each, you create
> a new bit pattern representing "almost infinity". An overflowing operation
> would produce it, and in most situations it would be treated the same as
> infinity, but in some situations it would act differently (the most obvious
> being that when multiplied by zero it gives zero not NaN). The semantics
> are different (each with some advantages over the other), but they are
> similar, including that they are both new variants of 754. Each would need
> new hardware developed to give top performance.
The real question is whether a (hardware or software) implementation
that produces +-DirectedInf in place of Inf whenever an operation with
directed rounding to +-Inf overflows is still 754 compatible.
If it is, everything is fine, and we can recommend implementors to
create and prefer this version.
Initially, this may be done in less efficient ways; ultimately it will
be done by all implementations, and as efficiently as the current
implementations, since hardly anything but applications for rigorous
computations uses directed rounding anyway.
If it is not, then redefining operations using either DirectedInf
or Overflow will violate 754, and hence must be simulated on top
of a 754 compatible architecture. In this case, is very unlikely
that either of these gives an advantage over a direct simulation
of the exceptional cases that arise in the treatment of unbounded
(and empty) intervals.
> Nate Hayes wrote:
>> Please note in your message below: "apparently", "I haven't yet had the
>> time to read through the 754 documentation...", "if it is...", "if it is
>> not..." etc. There is NOTHING that sounds certain about any of that.
[to which Arnold Neumaier replied:]
> This is only because I rely on information that Ian McIntosh and you
> regard as certain, but that I haven't checked yet. I have many other
> things to do besides carrying on these time-consuming 1788 discussions.
>
> But I wouldn't recommend putting any of this into the standard
> (or help presenting a motion on it) unless all these doubts are
> completely eliminated.