| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Arnold Neumaier wrote:
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'm also sympathetic to the time constraints. BTW, this is one reason I had volunteered to start a subgroup: so that these questions can be studied in due course by those that have time and/or interest. The prupose would be to create a summary report for those that don't.
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". This is not the same as Overflow, where Overflow - Overflow = NaN is an undefined operation. An operation on interval endpoints involving Infinity - Infinty (or Overflow - Overflow) should be some exceptional condition. This has already been voted on and accepted in Motion 12.02.
-- Same for section 7.6 about quotients of Infinity (although there has not yet been any motion to that effect).
-- Sections 7.4 and 7.5 again require against normal conventions that -0 and +0 are not aliases for each-other. This might look good on paper, but I'm not convinced it will work in the real world.
-- 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.
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 thecomplex 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.
For example, all problems in the interval arithmetic operations go away in this case: we no longer have to try and rationalize Infinity*0=0 since the only option is Overflow*0=0. Such an IEEE 1788 standard would then (I believe) be fully compatible with some future IEEE 754 standard that (might) add Overflow.
For interval comparisons, we would then no longer have to define different results depending on if intervals are overflown and bounded or overflown and unbounded (or some combination of both). As previously mentioned, Motion 13.04 and Motion 21 already give definitions for topological interior that would be compatible with Overflow (and those definitions are still simpler and more efficient than the ones recently discussed for unbounded intervals).
Nate Hayes