Re: Please listen to Ulrich here...

[Richard Fateman <fateman@xxxxxxxxx>]

On 8/29/2013 7:44 AM, Ulrich Kulisch wrote:

....

(Fateman) Since, for 99.9999+% of computers, it is not supported by hardware, this is not relevant.

(Kulisch) Computer technology is so powerful today that I am absolutely convinced that we shall get in hardware if we require it. My experience is that hardware designers are very openminded to new ideas.

Designers may be open-minded. Manufacturers are responsive to markets. I do not expect
interval computations to be a big market.

  Your statement does make explicit your reason for
arguing for EDP as part of a standard.  That is, you believe that one way (perhaps the only way) of
getting a hardware implementation of EDP is to make EDP a REQUIREMENT for conforming to
the 1788 standard, and since EDP is so much more efficient in hardware than software, that computer
manufacturers will be compelled to implement in hardware.

There are several difficulties here. 

1.There is skepticism that EDP is even needed, much less required for the
interval standard. As a compromise which you seem to find unacceptable,
 people have agreed to  include it as a  "recommendation" .

 2. I think others share my skepticism that -- EVEN IF IT WERE IN THE STANDARD -- that
it would trigger manufacturers to implement it in hardware.   Note that implementation
of parts of the (old) IEEE754 have sometimes been done quite inefficiently, requiring
traps to software, in some computers.  I have found some old statistics that suggest the
operation-code frequency of floating-point instructions is somewhat less than 4% of
typical process streams.

While you may believe that requiring EDP in 1788 is just the cudgel you need to make EDP
universally available in every new CPU chip, voting  shows that only a minority agree that it should
be required.

Continuing to press for it in 1788 and insisting that hardware implementation is somehow vital,
seems to detract from the process of converging on a 1788 standard document.

<snip>

(Kulisch)

The advantage of the EDP is that it eliminates cancellation from accumulations.

Let us assume that there is merit to accumulating sums without cancellation. (regardless of
application for intervals).
There are numerous methods to eliminate cancellations described in the literature.  There are
also efficient methods for accumulation that do not totally eliminate, but tightly bound errors. 

Asking 1788 to REQUIRE EDP, without examination of alternatives that accomplish the same
goals, seems odd.  Perhaps this committee has done some such investigations in earlier documents?

If multiple precision is implemented in software nobody uses it.

This does not seem to be a very good line of argument for us.
 Almost no one uses interval arithmetic.
Is this because it is not implemented in hardware? 

(Statistically, almost no one uses floating point, and it IS usually in hardware...Even scientific software
probably does mostly indexing calculations in fixed point, loads, stores, calls/returns, compares....)

So lets assume that both are implemented by hardware. Then implementing the EDP is much simpler and it runs much faster than a quadruple precision arithmetic.

Do you have a reference to the open literature on this topic?  It seems to me that quadruple-precision
arithmetic in hardware might be slower or faster, depending on the implementation.  Also quad might be
much more interesting if it also includes (say) division,   or a larger exponent range, etc.

You have to provide an extemely high precision until multiple precision arithmetic can compete with the EDP in double precision with respect to cancellation.

EDP is limited to double precision inputs, not multiple-precision inputs. Also, there are other techniques
that provide sparse representations. Here's a paper I have handy that is online too:

Douglas M. Priest, Algorithms for Arbitrary Precision Floating Point Arithmetic, Tenth Symposium on Computer Arithmetic, pp. 132-143, IEEE Computer Society Press, 1991.

also more recent work by Demmel and Hida.

If the exponent range does not suffice you can add an exponent part to the EDP and use it as a movable window. Such systems are also available. See my book or [5] on the poster.

It is also possible to simulate double-floats by integer registers by adding an exponent part and using a shifting window. :)   Also, references that are free and online are much preferable to books.

Regard
Richard