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

Re: re motion 50 (Just to you...)

Ulrich,

Lets assume everything you say about EDP is correct.
Just because EDP is a fundamental mathematical operation does not mean that it should be required in an interval arithmetic standard. Requiring EDP in an interval arithmetic standard is a separate issue.
As I have repeatedly written and received no answer from you or anybody else, please provide a single example of an interval computation based on non-degenerate interval inputs that substantially benefits from the availability of EDP. 

Thanks in advance,

Respectfully,

Bill


On 9/18/13 9:37 AM, Ulrich Kulisch wrote:

Baker,
yes, you are right. But you have to produce it! Of course you can put it together by using other tools. Of all these producing it via the EDP is the simplest.
My argumentation is this: The dot product is a fundamental and frequent arithmetic operation in mathematics and in numerical analysis. Since it is so easy to realize it and since it can be implemented with extreme speed it should be made available on a modern computer as an elementary arithmetic operation. Then a user does not have to simulate it.
The only problem is that it obviously is not obvious how to do it. I remember that I had a similar problem with the US patent attourny more than 30 years ago. After many mails I sent him he asked me to see him in his office in New York and explain it to him. He was very happy when he understood it and filed the patent immediately. This does not mean that you should read these patents. It is much simpler described in my book "Computer Arithmetic and Validity". The poster also might be useful. 

Best regards
Ulrich




Am 18.09.2013 15:54, schrieb Ralph Baker Kearfott:

Ulrich,

Please correct me if I am wrong, but, according to my understanding,
a correctly rounded dot product would also give you 23456, by
definition.

Baker

On 09/18/2013 08:02 AM, Ulrich Kulisch wrote:
Let's assume that we are using decimal arithmetic. Consider the two vectors 
a = (10²ºº, 23456, -10²ºº)   and b = (1, 1, 1).
A conventional for loop for the dot product of a and b in any available
fixed precision gives you 0, while the EDP would give you 23456.
A conventional for loop for the dot product of a by itself (norm) would
give you an overflow, while the EDP would give you the value of the
product.23456×23456 with no overflow.

For more details see the poster.
Let me mention that I shall be out of town for a conference for one week. 

Ulrich Kulisch


Am 17.09.2013 23:09, schrieb Richard Fateman:

On 9/17/2013 6:24 AM, Ulrich Kulisch wrote:


Let me just discuss an explicit example more closely, computing the
dot product of two vectors with interval components. What you would
like to have is the least enclosure of the set of all dot products of
real vectors out of the two interval vectors. Computing the interval
dot product in conventional interval arithmetic (what we are going to
standardize in P1788) for each interval product of two vector
components you round the minimum of all products of the interval
bounds downwards and the maximum upwards.

There is no requirement that an interval dot product be computed by a
simple loop
for i:=1 to n sum a[i]*b[i]      {where sum and * are interval
operations}
just as there is no requirement that a dot product of floats be computed 
by that same loop.
If I were computing a dot product of vectors of ordinary floats I might 
consider
extra-precise multiplication (via Split/TwoSum/TwoProd etc.)
and compensated summation.
For the analogous interval operation, perhaps the convenient operations 
I would need
are already implicit in the standard, which permits
multiple-precision.... For example
multiplication of 2 double-float intervals [a1,a2] * [b1,b2] to produce 
[C,D]  where C and D were
quad-float numbers. e.g. C = <e,f> where e + f ,each a double-float, is 
a representation of exactly the product.

This would be available as an appropriately overloaded interval mul(),
with a quad target precision, e.g.
quad_mul(a,b).
I think that quad_add() would be effective in adding the minima and the 
maxima, vastly decreasing the
possibility of a significant rounding error affecting the final outcome. Or perhaps a compensated summation of the collection of (scalar) values 
separately.

While it is possible to add 3 numbers a,b,c  via EDP(<a,b,c>, <1,1,1>)
and multiply two numbers by EDP(<a>,<b>), it does not seem economical.

RJF