Re: IEEEP1788

[Ulrich Kulisch <ulrich.kulisch@xxxxxxx>]

Am 25.05.2015 um 10:48 schrieb Vincent Lefevre:

On 2015-05-22 08:48:39 +0200, Ulrich Kulisch wrote:

I can only repeat myself: The exact dot product brings speed and
accuracy to interval arithmetic. It is the key operation for wide
acceptance of interval arithmetic.

You have never shown why/how this might be true.

It can be computed in a fraction of the time that any other known
method needs to compute a correctly rounded dot product.

This is not correct. You even have representation problems with
large-range formats such as GNU MPFR and DPE[*], where the difference
between the maximum exponent and the minimum one can about around
2^31, and even 2^63.

[*] https://gforge.inria.fr/projects/dpe/

It also is the key to many other valuable application like variable
precision interval arithmetic.

In what way?

Dear Vincent, please find my answers to the three questions 1), 2), 3) and 4) in your mail below:

1) You have never shown why/how this might be true.

I have written an entire book about this (published before P1788 was founded).
See, in particular, chapter 8 (Scalar products and complete arithmetic) and chapter 9
(Sample applications).

Let me repeat a short paragraph of my mail to John Pryce of May 19, 2015:

Interval arithmetic carries the potential to replace floating-point arithmetic by some general
computing tool where results come with highly accurate guarantees. Two things are definitely
necessary to reach this goal:

A. Fast double precision interval arithmetic and
B. An exact dot product (EDP). (for the data format double precision)

You find these two requirements already in the preface of my book "Computer Arithmetic and
Validity" (page XII). A standard that just specifies naive interval arithmetic and ignores questions of
accuracy is incomplete. It is, moreover, counterproductive since it will just reconfirm old reservations
against interval arithmetic. A simple and very fast tool for obtaining high accuracy is needed.

3) This is not correct. You even have representation problems with
large-range formats such as GNU MPFR and DPE[*], where the difference
between the maximum exponent and the minimum one can about around
2^31, and even 2^63.

I have not and don't know anybody who requested this!!!

4) In what way?

See chapter 9 of my book.

Best wishes
Ulrich,