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

Re: Motion 31: V04.2 Revision of proposed Level 1 text

Title: Re: Motion 31: V04.2 Revision of proposed Level 1 text
John,

let me answer the last question of your mail of Febr. 14 first:

> How does it work in XSC?

Three XSC-languages have been developed. PASCAL-XSC, ACRITH-XSC, and C-XSC. The first two are language extensions which needed new compilers. C-XSC is a C++ class library.
ACRITH-XSC is a Fortran extension that we developed for and with IBM for their /370 architecture.

All these languages provide a data type 'dotprecision'. It is identical to what in your mail and in other recent mails is called 'complete'. Variables and assignments to such variables are possible. In the XSC-languages even vectors or matrices with components of this type are permitted.

I agree with: 
The operations were well summarized by Michel Hack (30 October 2009 18:46:45 GMT):
 - conversions between CF(F) and a FP format F' that need 
   not equal F but must have the same radix;
 - addition and subtraction of two inputs that are CF, FP
   or integer (if I understand) giving a result of a CF at
   least as wide as the inputs (all are of the same radix);
 - completeMultiplyAccumulate, a kind of FMA, forming a CF
   result x*y+z from FP inputs x,y and a CF input z (all
   are of the same radix).
Complete arithmetic can avoid a large number of rounding errors and cancellation errors in particular. It can even recover information that has been lost during a preceding calculation. See [9] in the attached paper.

The dot product is a fundamental operation in Numerical Analysis. With complete arithmetic it can be computed error-free and fast. Exact accumulation of floating-point numbers and products is a necessary increment of floating-point arithmetic.
It can have many side effects not seen by many users, for instance, avoiding a shift of the solution by preconditioning, speed up iterative solvers, or avoiding cancellation effects in iterative refinement or defect correction techniques.

When Motion 9 had passed UKVS prepared a shortened version of the text. I attach it to this mail. I personally would be satisfied getting complete arithmetic for the 64 bit IEEE 754 floating-point format(s) in the first round. But I hesitate resp. would not recommend requiring it for a floating-point format of which the definition is not well known (GPU).



Am 14.02.2012 05:06, schrieb John Pryce: 
Ulrich, and Van

On 13 Feb 2012, at 11:16, Ulrich Kulisch wrote:

Let me summarize what has been said: To adapt the computer more to the needs of interval arithmetic two requirements are needed:

I.  fast hardware support for interval arithmetic (easy obtainable on existing processors), and
II. a fast and exact multiply and accumulate operation (continued addition), or what is equivalent to it, an exact scalar product (for the double precision format. For a simple sketch see the poster). 

Both are basic arithmetic operations for interval arithmetic and should be listed as such in the document.
I agree with much that you write in this email, but this question still concerns me: How are the features specified in Motion 9 realised at the User Program level? Must it be possible to define Complete Format (CF) variables?
The answer is YES.
 
The specification that completeAddition must be able to evaluate
  CF = CF + CF,   i.e. add two CF values to get a CF result, 
seemingly implies that a language must support such variables. Whereas if one weakens this to only require
  CF = CF + FP,   i.e. add a floating point value to a CF values to get a CF result,
one can get by with just a single CF object that acts as an accumulator.

In the former case a language needs a constructor for CF objects, and variables referencing them, and presumably assignments to such variables. Hence, I fear, it complicates P1788 as we must specify a CF constructor?
I think we should do this. After 70 years with only floating-point, computing and the user deserve a more comfortable data format and arithmetic. An operation which can be performed
exactly with high speed and at low cost should never just be done approximately.
 
In the latter case it doesn't need a constructor or CF variables as the accumulator can be "just there"; and a "reset accumulator to zero" operation takes the place of assignment. Like a cash till.
I would not recommend this.

How deos it work in XSC?

John

I hope these remarks contribute clarifying the situation.

Best regards 
Ulrich


--
Karlsruher Institut fuer Technologie (KIT)
Institut fuer Angewandte und Numerische Mathematik (IANM2)
D-76128 Karlsruhe, Germany
Prof. Ulrich Kulisch Telefon: +49 721 608-42680 Fax: +49 721 608-46679 E-Mail: ulrich.kulisch@xxxxxxx www.kit.edu www.math.kit.edu/ianm2/~kulisch/
KIT - Universitaet des Landes Baden-Wuerttemberg und nationales Grossforschungszentrum in der Helmholtz-Gemeinschaft

Attachment: ErrorFree.pdf
Description: Adobe PDF document