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

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

Great, Ulrich.
When you do answer, you might want to explain how it is that computing EDPs will help computing with intervals to address the following problem 

<http://www.scientificamerican.com/article.cfm?id=puzzling-measurement-of-big-g-gravitational-constant-ignites-debate-slide-show&WT.mc_id=SA_CAT_SPCPHYS_20130919>
It seems to me that this is a prime example of the kind of problem on which the interval computational and research communities should concentrate their efforts. We have a unique opportunity in situations like this. 

Cheers,

Bill


On 9/18/13 8:37 PM, Ulrich Kulisch wrote:

Bill,
I shall answer your question if I have more time. For the moment take the present discussion which started with computing a dot product for vectors with interval data. 

I have to leave for a meeting in one hour.

Best regards
Ulrich




Am 18.09.2013 20:02, schrieb G. William (Bill) Walster:

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