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

Re: discussion period begins, until Jan. 26: "natural interval extension": friendly amendment to M001.02



Dear Richard and others,

thank you for your mail. I think I do not have to tell you that I disagree with most of its contents. What can be wrong with the requirement to replace a slow and possibly wrong operation by a fast and correct one? The dot product is ubiquitous in Numerical Analysis.

Two students of Jim Demmel show that a dot product can exactly be computed in 1/6 of the time that is needed for computing a possibly wrong result in conventional floating-point arithmetic. Not to require it and let users thruggle with wrong results would be an irresponsible mistake. We would never have got NaN in processors if IEEE 754 not would have required it. There still is some competition among manufacturers and it needs only one who provides it and the others have to follow. In the worst case a software simulation would not be much slower than a possibly wrong computation in conventional floating-point arithmetic. Additions and multiplications in fixed-point are simpler and faster than in floating-point with a complicated rounding mechanism after each single addition and multiplication
.
Let me tell you another story. In 1966 my university got a new computer called X8. I was the director of the computer center. In the same year Ramon Moore's book on interval arithmetic was published. It contains many fascinating ideas. To study and use them seemed promissing. But the X8 did not provide the operations with the directed roundings. So we studied the hardware of our computer and jointly with the manufacturer provided the operations with rounding downward. Rounding upward was done by roundup(x) = - rounddown(-x). This hardware extension was done in three hours. Within one year one of our collaborators implemented an ALGOL extension that provided a new data type and operations for intervals together with elementary functions.
Fifty years later the operations with the directed roundings are still not yet reasonably provided on commercial processors. The situation certainly would be different if they were requested by a standard. We have to articulate what we need otherwise we will never get it.

European supercomputing meetengs are held annually. They usually attract around 2000 participants. (Corresponding meetings in the US have twice as many participants). A majority of them struggles with numericl problems and problems of accuracy. For tens of millions of dollars we let them buy computers which are not optimized for their needs. As a mathematician I do not feel well in this situation.

With best regards
Ulrich



Am 16.01.2016 um 17:26 schrieb Richard Fateman:
Dear Ulrich (and others)

Setting a standard that can only be achieved by custom hardware is neither necessary nor,
it seems to me, advisable.  By repeatedly emphasizing the hardware aspect of EDP
implementation (although of course it can be more slowly in software) you raise the
prospect that people will think that the 1788 standard requires special hardware
or can only be efficiently implemented with special hardware.  This would be,
I think, unfortunate.

An understanding of techniques to ameliorate software bottlenecks
so that we might achieve the results dictated by the standard
using existing commercial hardware and programming languages and libraries
is, in my opinion, important for the viability of the standard. Some of this
has been vastly simplified by the convergence of floating-point hardware
specifications.  There remain significant barriers in some programming
languages, compiler tools,  and libraries, in my view.  Finding a pathway
through these issues for implementers and users of interval arithmetic
is, I think, important. 

While in the past different manufacturers had divergent floating-point
hardware and the IEEE 754 standard "cleared the air",  I am unaware of
any commercial processor manufacturer who has incorporated in hardware
any operations that are specifically interval-related in such a fashion as
to exclude any of the variants of interval arithmetic of interest.  This
committee is, it seems, an unlikely place to demand a standard that
requires new hardware that no one is building.

In spite of the apparent success of the IEEE 754 standard, note that some
manufacturers and software language developers (most?) have implementations
in which fundamental operations are slow, inconvenient, and occasionally
impossible to achieve,  such as setting rounding modes or working with
traps and NaNs. Some of these operations are of course key to implementing
interval arithmetic.  I point this out to illustrate that we are not in
the driver's seat in regard to hardware changes, even in that much more
compelling case of a need for floating-point standards --  implemented
efficiently.

For instance,
it might lead to substantial interval-arithmetic efficiencies if  hardware dealt efficiently dealt with
rounding modes.  One proposal would have instructions sets that included
extended-float-add-register-rounding-up  etc. 

Thus there are many opportunities for efficiency in hardware that could
improve performance on interval tasks, as well as other floating-point related
processing.

   I think that the interval standard document is
sufficiently complicated without discussions of hardware.

I do not expect that this will change your enthusiasm for hardware EDP.

Nevertheless, I hope this note  explains why I would prefer that the value of EDP toward a
standard, if it is to be included in the document,  be explained on
grounds of its contribution to achieving computational results. I think that any
comments regarding special efficient hardware be relegated to -at best- a footnote and
references.

Regards.

Richard




On 1/16/2016 3:11 AM, Ulrich Kulisch wrote:
Dear Richard;

thank you for your mail. It shows me that some further clarification seems to be necessary:

What you say in the first paragraph of your mail has nothing to do with the task developing a standard for interval arithmetic. But since you explicitly ask for it, let me say it: I very much appreciate what James Demmel, Siegfried Rump, Shin ichi Oishi, Baker Kearfott, and many others have done for computer and interval arithmetic (with a tool not primarily developed for it). It is excellent work! But stating this is not our task.

A standard for interval arithmetic has to state clearly what is needed for efficient, accurate, and successful interval arithmetic and emphatically demand this from manufacturers.

Any analysis how close existing processors come to our requirements is not subject of our task. I am strictly against that representatives of processor manufacturers, they may be from Sun, Intel, IBM, or others, tell us what a standard for interval arithmetic is permitted to require. Their intention finally only can be selling us perhaps with little changes what they have already. We should not permanently be forced to approximate our needs on processors primarily developed for other purposes. Processors need to be better adapted to the needs of interval arithmetic!

Well defined and implemented interval arithmetic has a very high potential for the future of scientific computing. Developing a standard for it gives us a unique chance and the power to get it into commercial processors. Let's not miss this chance!
 
With best regards
Ulrich Kulisch

(By the way: Well defined and implemented interval arithmetic means quite a bit more than just an EDP).





Am 14.01.2016 um 17:20 schrieb Richard Fateman:
On 1/14/2016 7:48 AM, Ulrich Kulisch wrote:
Dear colleagues, 

I apologize for repeating myself.


Perhaps you could comment on
 James Demmel's recent posting in which he
refers to a nice result for the related objective of summation of
n numbers, accurately. This method can use one
or more processors such as are currently available, uses a
small number of registers, and is modestly slower than
 the obvious method for (unreliable) summation.


While your proposals are interesting, to achieve the claimed
speed would require special hardware (hardware which
is not commercially available).   So we must consider if
the EDP is worthwhile to incorporate in the 1788 standard
if it were inevitably implemented in software.  Which means
it should be compared to other software schemes such
as Demmel's  (and MPIR -- which of course does far more
than EDP).


-- 
Karlsruher Institut für Technologie (KIT)
Institut für Angewandte und Numerische Mathematik
D-76128 Karlsruhe, Germany
Prof. Ulrich Kulisch
KIT Distinguished Senior Fellow

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 - Universität des Landes Baden-Württemberg 
und nationales Großforschungszentrum in der 
Helmholtz-Gesellschaft