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

Re: Overflow and Inf

Nate Hayes wrote:

Arnolde Neumaier wrote:

Nate Hayes wrote [in: Comparisons and decorations]
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).
Please point to a particular item that needs a clearer formulation and an example. I currently have no time to do them all. 




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.