Ian,
You wrote: "My interpretation of what you wrote is that you don't need an exact dot product if the inputs aren't exact."
That is exactly correct. I am well aware of all the ways you describe that accuracy can be lost in floating-point and interval computations with exact inputs. However, for the sake of argument, lets assume that exact EDP exists. Then please provide an example of an interval computation with say 1 ulp interval widths in the 6th decimal digit in which the exact EDP computed interval bounds on the solution are substantially narrower than those computed using double precision floating-point interval arithmetic.
My point is that for typical engineering problems EDP does not add value and therefor is not relevant for most practical interval computations.
That does not mean that EDP is not relevant for the development of high quality library routines that return the narrowest possible interval bounds on the evaluation of nasty functions or their inverses. These are problems where argument and parameter values can be exact. However, even for such library functions, when argument and/or parameter values are non-degenerate intervals, the effort required to compute narrowest possible interval bounds generally will be wasted.
Cheers,
Bill
On 8/26/13 9:40 AM, Ian McIntosh wrote:
BW> As far as I can tell the only time when a case can be made that EDP is
BW> essential for interval computations is when all interval inputs are
BW> degenerate and therefore infinitely precise. Otherwise, with interval
BW> bounds on the accuracy of typical measured data, I don't see the
BW> requirement for EDP. I continue to wait to see even one practical
BW> example thereof.
My interpretation of what you wrote is that you don't need an exact dot product if the inputs aren't exact. Having dealt with gradually deteriorating accuracy of chained computations each losing just half an ulp or one ulp, I'm wary of inexactness but also very aware of the performance it can bring. So my preference is to allow the choice of either exact or a good approximation, and I support having EDP but not mandatorily implemented via CA even though it is an elegant solution.
The key advantage of Interval Arithmetic is that you can see how accurate the final result is. If it isn't accurate enough for your needs you can try to improve the accuracy of the inputs by better or more measurements, and/or improve the accuracy of the computation by using higher precision types, a higher precision math library, exact divide instead of multiply by reciprocal, exact dot product instead of fast dot product, etc.
- Ian McIntosh IBM Canada Lab Compiler Back End Support and Development
"G. William (Bill) Walster" ---08/24/2013 03:50:22 PM---Ian, As far as I can tell the only time when a case can be made that EDP is
From:
"G. William (Bill) Walster" <bill@xxxxxxxxxxx>
To:
Ian McIntosh/Toronto/IBM@IBMCA
Date:
08/24/2013 03:50 PM
Subject:
Re: Please listen to Ulrich here...
Ian,
As far as I can tell the only time when a case can be made that EDP is
essential for interval computations is when all interval inputs are
degenerate and therefore infinitely precise. Otherwise, with interval
bounds on the accuracy of typical measured data, I don't see the
requirement for EDP. I continue to wait to see even one practical
example thereof.
Cheers,
Bill
On 8/24/13 11:13 AM, Richard Fateman wrote:
> On 8/23/2013 9:58 PM, Ulrich Kulisch wrote:
>> Ian,
>>
>> I attach a few more pages which might be interesting for you.
>>
>> Best regards
>> Ulrich
>>
>> P.S.: These details are more or less known since 1980. But obviously
>> they are not wide spread. I discussed this matter already with
>> IEEE754R. At the end they said they don't have the necessary
>> knowledge to make a clear decision. A few month after the first
>> edition of my book was published in 2008 IEEE 1788 was founded. Now
>> it seems that we end with the same situation.
>>
> Repeatedly pointing out the hardware aspects makes me wonder if the
> argument
> for EDP being essential for interval computation other than EDP of
> intervals is simply
> unsupported.
>
> RJF
>
