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
|