Xref: utzoo comp.arch:5483 comp.lang.c:11328 comp.lang.fortran:913 comp.lang.ada:1369 comp.lang.pascal:990 comp.lang.modula2:931 sci.math:4202 sci.math.stat:388 Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!oliveb!sun!dgh!dgh From: dgh%dgh@Sun.COM (David Hough) Newsgroups: comp.arch,comp.lang.c,comp.lang.fortran,comp.lang.ada,comp.lang.pascal,comp.lang.modula2,sci.math,sci.math.stat Subject: Floating-Point Indoctrination: Final Lecture Message-ID: <59946@sun.uucp> Date: 14 Jul 88 20:14:00 GMT Sender: news@sun.uucp Lines: 97 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@sun.com na.hough@na-net.stanford.edu {ucbvax,decvax,decwrl,seismo}!sun!dhough