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

Re: Up-to date Interval Arithmetic



On 4/1/2015 9:31 AM, Ulrich Kulisch wrote:
<snip>

But I am not talking about that in my mail above. Hoping to find consent  let me try to explain my mail above  with other words:
The set D of IEEE 754 data consists of floating-point numbers of F and the IEEE 754 exceptions E,
so D = F +E. Arithmetic in D can lead to overflow, underflow, NaN, +oo, -oo, +0, -0, and so on. Arithmetic of IEEE P1788 deals with intervals of ID.
This is lumping two concepts together. 

IEEE 754 has exceptional operands, +-oo, subnormal, many NaNs [with encoded fields].

IEEE 754 has (optional) exceptions which can be used to interrupt the normal control flow.

As I recall,
recognizing that interrupting the normal control flow (or even allowing for the possibility of interrupting the normal
control flow) likely impedes certain efficiencies (slows down parallel or out-of-order execution)
the 754 standard provides for computation to proceed using exceptional operands instead of interrupts.


That routines developed in ID frequently work is due to the fact that arithmetic in IF is an exception-free closed calculus, i.e., an arithmetic operation for intervals of IF leads to an interval of IF again.
I assume that you are allowing for the 'endpoints' of intervals of IF to be exceptional operands like oo, which would
signify an interval that is open "at oo"   but has in its interior only elements of F.

So the calculus is free of operations that cause interrupts, but includes in the data representation, +-oo.

Similarly, it is possible to extend the calculus of intervals by using other signifiers that come from IEEE 754,
namely NaNs.
 There may also be uses for signed +-0. 
There might be a use for an unsigned 0  (different from +0),
but at some point one runs out of bits, or ideas for how to use them.

The IEEE 754 exceptions are definitely not needed for developing interval arithmetic.

I think you mean "interrupts".  I think one can make a stronger statement, which is that IEEE 754
interrupts are not needed for IEEE 754 arithmetic, as indicated above.

 If you means signifiers like +-oo are not needed,   all I can say is it makes some interval
calculations much easier.  
Never in the many years I am working with interval arithmetic I needed to use constructs like NaN or NaI.
I have found it convenient to use NaNs as endpoints for Not an Interval, but then I also allowed [3, -3] to
represent the external interval   x>=3 or x<=-3.  So I have many more valid intervals.
They came into the business because someone had the terrible idea to develop interval arithmeic over the set ID (= IEEE P1788).
Has someone suggested converting an IEEE 754 NaN into a valid interval?

It really is  like a cuckoo's egg that someone put on interval arithmetic. A standard for interval arithmetic (IR and IF) could be much simpler than the present draft of IEEE P1788 if you strictly seperate interval arithmetic form IEEE 754 floating-point arithmetic.

A good deal of effort was devoted to directed roundings in IEEE 754 standards deliberations,
with the intention of forcing implementers to provide tools for supporting interval arithmetic.

It seems unlikely that directed roundings would be so widely available without IEEE 754.  Indeed some
"implementations" defy the standard by making directed rounding slow and/or inconvenient.

 Of course interval arithmetic is entirely separate from IEEE 754
arithmetic in the sense that intervals are represented by pairs, and floating-point numbers are scalars.
 Manufacturing one from the
other requires specific attention to conversions or operations  (like midpoint, min, max)...

Richard Fateman