Re: Please listen to Ulrich here...
On 29 Aug 2013, at 16:58, Richard Fateman wrote:
> 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.
Hmm, and as I have been arguing, even as part of a standard it is not a tempting target for hardware
designers.
I am a little surprised that EDP -- if it is so useful -- has not been adopted by the 754 committee.
Why? Is there some problem with EDP?
One reason may be that it is not the best way to organise even something as simple as matrix multiply.
The data flow through a 32x32 multicore processor is not particularly efficient. It almost certainly
makes more sense for the instructions to move to the data than _vice_versa_.
How do partially completed accumulators get moved to the data?
>
> 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" .
Why compromise?
>
> 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.
Most chips don't even have an FPU. Do we have a view on fixed point EDP?
>
> 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.
And we never did get a sensible definition of "hardware".
I propose that by "hardware", we mean a single processor machine with micro-code. Anything else is just a glorified FPGA, isn't it?
>
> <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.
What evidence is there that this is true?
> 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.
I'd be very surprised if the supposed quad inefficiency were true.
>> 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.
Strangely enough, that looks very attractive as a solution..
>
> Regard
> Richard
>
>