Re: Overflow and Inf
Arnolde Neumaier wrote:
Nate Hayes wrote [in: Comparisons and decorations]
Arnold Neumaier wrote:
Nate Hayes wrote:
Arnold Neumaier wrote:
Nate Hayes wrote:
I considered two alternatives within 754: either you represnt it
that way, or you don't. In the first case, you get nonsens upon
multiplication with a finite number, in the second case, you must
represent it by Inf. But then Overflow is inf, and there is no need
to treat it as something new.
No. This is one of the points you miss. In the second case there is
still a distinction to be made between Overflow and Infinity, just as
there is still a distiction to be made between an interval [1,Infinity]
that either does or does not have the IsBounded decoration present.
Since we have Infinity anyway, what is the use to have in addition an
Overflow?
Overflow must behave just like Inf is handled in the suggestions of
the Vienna proposal for modifying the IEEE 754 directed rounding modes.
But then there is no need for distinguishing the two, beyond what the
usual Inf and the IsBounded decoration offer.
Whhat is the advantage of having another object Overflow?
It depends on many cases, none of which P1788 has made any decision about
yet (that I know of).
If P1788 decides to include an IsBounded decoration, then the decorated
intervals:
([1,Infinity],NotBounded) and ([1,Infinity],IsBounded)
are two different intervals.
They are the same intervals but different decorated intervals.
The upper bound of the former is truly unbounded, but the upper bound of
the latter is not.
The upper bound, as defined by Motion 3, is in both cases Inf.
But the former is a possible overestimate of a range that is known
to extend to infinity, while the second is a possible overestimate
of a range that is known not to extend to infinity.
Or as has been previously mentioned
([1,Infinity],IsBounded) = [1,Overflow]
represents a family of compact intervals.
In this case, the
IsBounded decoration could be "stored" in the floating-point
representation of the Infinity, hence
[1,Infinity] and [1,Overflow]
But what is the point of storing a few decorations in Infs and NaNs
if others (such as isContinuous) cannot be stored that way?
Decorations should be handled in a uniform style, and not differently
for each particular decoration. Otherwise one gets a mess.
One really good reason is that the distinction between [1,Infinity] and
[1,Overflow] can be made between BARE intervals. Hence, relations between
such intervals do not depend on interval decorations but only the bare
intervals.
In the past, this has been one of the reasons given NOT to have an IsBounded
decoration: that interval relations might then depend on the decoration as
well as on the interval portion of a decorated interval.
Overflow makes this argument against an IsBounded decoration moot.
makes the same difference as the two decorated intervals above. In this
sense, the "IsBounded" decoration of interval [1,Infinity] can be viewed
as an Overflow in disguise. The reson the opposite is not necissarily
true, however, is that certain representations are explicitly possible
with Overflow that would not other-wise be possible with just an
IsBounded interval deocration, e.g.
[-Infinity,Overflow] and [-Overflow,Infinity]
are two intervals that could not be represented if the IsBounded
decoration is an attribute of the interval, itself.
And where are they needed?
I strongly oppose introducing possibilities only for the sake
that it is possible to define them.
A standard should be as restrictive as possible, given the constraint
that it does not exclude something that has been useful in the past.
Now, regardless if P1788 includes an IsBounded decoration or not,
distinguishing between Overflow and Infinity in the IEEE 754 arithmetic
(or a replacement thereof) gives a fast and efficient way to compute
[1,Overflow]*[0,0]=[1*0,Overflow*0]=[0,0]
as opposed to the incorrect results obtained by using IEEE 754 arithmetic
as it exists today. Ian has already explained this in detail, so I'm not
going to repeat it all over again.
I assume you refer to Ian Mcintosh's mail from September 22.
What he says is independent of whether a distinction is made between
Inf and Overflow.
It applies verbatim if all of his Overflows are interpreted as Inf
in the sense of Motion 3, but are implemented as nonstandard Inf
(called DirectedInf for the sake of the following discussion)
for which an implementation can (apparently, if I understand
him correctly) specify its own operation rules without being
inconsistent with 754.
I'd like to have an explicit confirmation that I understood this
correctly, or else clarification about what was intended.
To me, this part of the Vienna Proposal is not so clear, so I would like to
have an explicit confirmation of exactly how all that works, in much greater
detail (and with practical examples).
On the other hand, he is silent about how to produce DirectedInf
by using the directed rounding operations. Doesn't 754 require that
overflow produce a _particular_ Inf?
If so, each operation that could overflow would have to be patched
up by changing each Inf produced to DirectedInf.
If not, this would elegantly solve all problems by using a new
implementation of the directed rounding modes that gives always
a DirectedInf when an Inf would be expected.
This DirectedInf would then _not_ have the meaning of Overflow,
but of Inf, and thus also treat cases like
[1,1]/[0,1]=[1,DirectedInf]
correctly.
Thus one could implement in this way the last Section of the
Vienna Proposal in the same way.
No separate Overflow with its otherwise unwanted properties
(and an arithmetic dependent on decorations) would be needed.
I personally don't have strong feelings one way or the other whether or
not P1788 decides to include an IsBounded decoration. But it seems clear
to me Overflow as a concept is a relevant topic, either way.
I find IsBounded useful and would like to have it in the standard.
As mentioned above, Overflow makes moot one of the critisims which have been
made (I believe by John Pryce, if not others) that there should NOT be an
IsBounded decoration, since in that case interval comparisons might depend
on the IsBounded decoration and not just the bare intervals.
Ok. I'm glad to hear you are listening. :-)
Sometimes you have to make a lot of noise to see if someone is paying
attention....
It would be a waste of my time if I were writng without also listening.
I am not that inefficient.
From a conceptual point of view, this would be the same as leaving
the IEEE 754 arithmetic "as is," decorating the interval [1,Infinity]
with an IsBounded decoration, and then using special routines to
"fix" the endpoint results that are incorrectly produced by existing
IEEE 754 arithmetic.
But if you need a special routine to fix the behavior depending on the
decoration, this is by no means better than fixing the behavior of Inf
as it is fixed traditionally, e.g., in Intlab.
On the other hand, you violate by this special procedure the general
conceptual rule that the result of the interval part should not depend
on the decorations.
The important differences (benefits) are in how the underlying
interval arithmetic operations are potentially implemented... not the
definition of interval arithmetic itself as we've already accepted in
Motion 5 (that would NOT change).
I can't see how you'd implement your formula with Overflow more
efficiently than Rump implemented the treatment of Inf.
Will you please show me the source code of how Rump does this?
How he did it in version 5.0 is appended to the end of this mail.
But the code looks quite ugly since he does the real case and the
complex case and the vector-valued case simultaneously, and also has
overloading by real numbers and complex numbers/intervals as part of the
procedure. The essential part for real intervals is:
setround(-1)
c.inf = min( a.inf .* b.inf , a.inf .* b.sup );
c.inf = min( c.inf , a.sup .* b.inf );
c.inf = min( c.inf , a.sup .* b.sup );
setround(1)
c.sup = max( a.inf .* b.inf , a.inf .* b.sup );
c.sup = max( c.sup , a.sup .* b.inf );
c.sup = max( c.sup , a.sup .* b.sup );
It works correctly except for the case when a and b are [0,0] and Entire
(in some order), where the Intlab result is (wrongly) [NaN,NaN] rather
than [0,0]. The code can easily be fixed (for scalar intervals) by
appending
if isnan(c.sup), c.inf=0;c.sup=0; end;
Easy to write in code, I agree. But notice this puts a branch into the
code to detect what typically will be quite a rare case. The branch needs
to be tested and executed for every interval operation, though. This can
lead to big performance loss.
Suppose that Entire was produced by [0,0]/[0,0], so that it does _not_
represent a bounded interval.
How would your Overflow solve this more efficiently?
As I have said, the exact use and definiton of Overflow for P1788 depends on
other questions that have yet to be voted on. So the answer could depend on
many variables which have not yet been settled.
Nate Hayes
Arnold Neumaier