Floating-Point Indoctrination: Final Lecture

David Hough dgh%dgh at Sun.COM
Fri Jul 15 06:14:00 AEST 1988


     During May-July 1988, Prof. W. Kahan of the University
of California presented a lecture course on Computer System
Support for Scientific and Engineering Computation at Sun
Microsystems in Mountain View, CA.  To summarize this
course, Prof. Kahan will present a final lecture, at 7:30 PM
on Thursday, 28 July 1988, at Apple Computer's DeAnza-3
Building, 10500 N DeAnza Boulevard, Cupertino, CA.  Enter
from the south side.

     This final lecture is free to the public.  Please pub-
licize to interested colleagues.

                          ABSTRACT

Most scientific and engineering computer users consider
irrelevant the details of floating-point hardware implemen-
tation, compiler code generation, and system exception han-
dling, until some anomalous behavior confronts them and
prevents the satisfactory completion of a computational
task.  Some of these confrontations are inevitable conse-
quences of the use of finite-precision floating-point arith-
metic; others are gratuitous results of hardware and
software designs diminished by the designers' well-
intentioned corner-cutting.  Distinguishing the intrinsic
from the gratuitous is no simple matter; such chastened com-
puter users are not sure what they might reasonably demand
of computer system purveyors.

The novice's impression that there is no rhyme nor reason to
the dark mysteries of floating-point computation is some-
times superseded by a euphoric discovery that there is a
good deal that can be axiomatized and proven about floating
point; later experience may temper such a discovery by indi-
cating that not everything that can be axiomatized or proven
is worth the trouble.  Furthermore, what would be worth
knowing is often surprisingly difficult to encapsulate and
refractory to prove; even when each subproblem of a realis-
tic application permits a satisfactory error analysis, the
overall problem may admit no such analysis.  The proofs of
simple statements about algorithms or programs often require
machinery from other parts of mathematics far more elaborate
than expected.  Thus some of the mathematically inclined who
become involved in these studies, out of external necessity,
then become permanently sidetracked by intricate mathemati-
cal issues. To remain relevant, a sense of engineering econ-
omy must guide such studies, in order to distinguish the
things that are worth doing, and therefore worth doing well,
from those that aren't.

Over the nearly twenty years since this lecture course was
first presented, the software environment has gradually
deteriorated despite that hardware has improved. The
software deterioration may be attributable to the
establishment of Computer Science as a separate academic
discipline, whose graduates need have little acquaintance
with scientific computation.  The hardware improvement can
be principally attributed to the advent and acceptance, for
most microcomputers, of the ANSI/IEEE Standards 754 and 854
for floating-point arithmetic.  But some of the potential
benefits of those standards are lost because so much
software was and is written to exploit only those few
worthwhile features common to almost all commercially signi-
ficant existing systems.  In fact, much portable mathemati-
cal software, created with funding directly or indirectly
from American taxpayers, is crippled by a misguided quest
for performance on the fastest existing supercomputers
regardless of detriment to far more numerous mini- and
microcomputers.

Well-intentioned attempts by language architects and stan-
dardizing bodies to ameliorate some of the difficulties
encountered in floating-point computation have too often
exacerbated them and, in some instances, spread over them a
fog caused by ostensibly insignificant variations in the
definitions of words with otherwise familiar connotations.
What we need now is a measure of consensus on language-
independent definitions of needed functionality, even if we
must sacrifice some compatibility with past practice to
achieve intellectual economy in the future.  Alas, few pro-
fessionals will pay the present costs of incompatibility
with past errors to achieve gains promised for an indeter-
minate future.  The computing world has too many broken
promises rusting in its basement.

One of the anticipated outcomes of this course is that lec-
ture notes will eventually be published reflecting current
thinking on some of these issues.  In addition a group of
students has undertaken to improve the implementation of
certain elementary transcendental functions to a better
standard than has been customary.


David Hough

dhough at sun.com   
na.hough at na-net.stanford.edu
{ucbvax,decvax,decwrl,seismo}!sun!dhough



More information about the Comp.lang.c mailing list