Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

DirectedInf

Nate Hayes wrote: [in Overflow and Inf]

Arnold Neumaier wrote:

Nate Hayes wrote:

Arnolde Neumaier wrote:


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.


Since Dan Zuras and Michel Hack assure me that adding new rounding modes
does not invalidate the property of being 754-conforming, the above
seems indeed to be the case, interpreted appropriately.

This opens up a door that I'll soon expl;ore in more detail.
Regarding section 7 of Vienna Proposal, there are a couple things I am concerned about:
-- The mechanism described is tightly dependent on the signs of zero appearing in the right place, e.g., [+0,-0] is a valid interval but [-0,+0], [-0,-0], [+0,+0] are all invalid constructions. This means -0 and +0 are no longer aliases of each-other and the interval arithmetic is highly sensitive to the signs of zeros in the endpoints.
-- Sections 7.3 says Infinty - Infinity = 0, which doesn't make sense to me. This seems to imply that "Infinity" is just "MAXREAL".
No. Infinity is not a real number; indeed, in a 754-conforming representation as DirectedInf it will be a particular NaN.
This is not the same as Overflow, where Overflow - Overflow = NaN is an undefined operation. 

I never claimed it was. But Overflow is not a real number either,
since Overflow^2+1=Overflow, while x^2+1=x has no real solution.
An operation on interval endpoints involving Infinity - Infinty (or Overflow - Overflow) should be some exceptional condition. 

No.
Since DirectedInf is a new concept, one can specify its properties arbitrarily.
-- Nothing in section 7 of Vienna Proposal address consequences of an IsBounded decoration (which you also advocate), nor the impact of this on comparisons. It seems to me this will require Overflow, anyways.
Of course, it cannot, since the concept of decorations was not yet born at that time. 

I intend upgrade Section 7 of the Vienna Proposal during the next
few weeks, and then hope to present a version in which everything
is clear.





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. 

Please pick the most favorable context and show how it is doen there.
Then one can discuss its merits.
As controversial as it may be, more and more I believe Motion 3 is too liberal in allowing unbounded intervals. Overflow makes things more efficient because P1788 then no longer has to deal with special case disctinctions between when the result is known to overflow and be unbounded vs. when the result is known to overflow and be bounded.
How would you then represent the interval defined by the bound constraint x>=1 in a linear program? 
Nothing overflowed, x can be any real number >=1.


Arnold Neumaier