Fast FloatingPoint Pro cessing in Common Lisp RICHARD J FATEMAN UniversityofCalifornia Berkeley and KEVIN A BROUGHAN and DIANE K WILLCOCK UniversityofWaikato and DUANE RETTIG Franz Inc Lisp one of the oldest higherlevel programming languages has rarely b een used for fast numerical oatingp oint computationWe explore the b enets of Common Lisp an emerging new language standard with some excellent implementations for numerical computation We compare it to Fortran in terms of the sp eed of eciency of generated co de as well as the structure and convenience of the language There are a surprising number of advantages to Lisp esp ecially in cases where a mixture of symbolic and numeric pro cessing is needed Categories and Sub ject Descriptors G Mathematics of Computing Mathematical Software eciency portability D Programming Languages Pro cessorscompilers interpreters optimization General terms Common Lisp Fortran C Floatingp oint arithmetic Additional Key Words and Phrases Compiler optimization Symb olic computation Numerical algorithms INTRODUCTION The combination of symbolic and numeric computation has b ecome p opular in sev eral application areas These include for example motion planning for rob otics signal pro cessing and image understanding One burgeoning area is the develop mentofscientic computing environments including symb olic mathematics sys tems numerical computing and graphics These tend to mix traditional strengths of the Lisp programming language interactivity and symb ol manipulation with the additional need for numerics In general mathematical mo deling of complex physical phenomena includes a symb olic manipulation phase of mo del formulation followed byanumerical solu tion phase and output visualization Mo del formulation has traditionally b een a Authors addresses Richard J Fateman Computer Science Division University of California Berkeley CA USA Kevin A Broughan and Diane K Willco ck Dept of Mathematics and Statistics UniversityofWaikato Private Bag Hamilton NZ Duane Rettig Franz Inc UniversityAve Berkeley CA USA email fate manp eoplesparcBerkeleyedu kabwaikatoacnz duanefranzcom Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage the ACM copyright notice and the title of the publication and its date app ear and notice is given that copying is by p ermission of the Asso ciation for Computing MachineryTo copy otherwise or to republish requires a fee andor sp ecic p ermission R J Fateman et al p encilandpap er activity but in recentyears computer algebra systems haveas sisted in analysis and subsequentFortran co de generation for numerical compu tation Since dierent languages are b eing used for the analysis and nal execution this approach precludes the development of algorithms which use mixed symb olic numeric pro cessing at a deep er level A b etter arrangmentwould allow the analysis and execution phases to exist simultaneouslyallowing eachtointeract with the other Still even if the symb olic and numeric phases coexist as a practical mat ter errors or exceptional conditions on one side of the software b oundary tend to b e dealt with inconveniently on the other side suchevents include oatingp oint exceptions keyb oard or mousegenerated interrupts op erating system actions and storagereclamation pro cessing garbage collection in Lisp A b etter metho d of joining the two kinds of pro cessing without descending to lowlevel implementation co ding would b e useful For some time now the need for a symb olicnumeric mixture has b een well recognized by designers of computer algebra systems Sometimes this need is met entirely in the Lisp system environmentby writing in Lisp Sometimes the numeric or graphical routines are loaded from a standard library or written in advance using CorFortran but integrated at compile or load time with the computer algebra system Sometimes the need for numerical co de is only satised by pro ducing on the y Fortran sourceco de compiling and loading it backinto Lisp This last approach tends to b e delicate but several systems have b een built around the use of symb olic systems to help co de Fortran subroutines which are then t into templates of other Fortran co de to pro duce complete packages Some recen twork includes work by Wirth Lanam Wang Broughan Co ok and Ka jler As a principal example of the approach of linking Lisp programs with numerics consider the developmentofsymb olicnumeric algorithms for the Senac environ ment under way at the UniversityofWaikato New Zealand Mathematical Soft ware Pro ject The goal of this development has b een to combine computer algebra languages with numeric and graphic subroutine libraries The combination has until recently b een achieved using Lispbased algebra languages combined with Fortranbased numeric and graphics co de The linking of these systems has of ten employed Lisp foreign function interfaces to C and Fortranlanguage co de Such links to foreign functions are included in a numb er of mo dern Lisp systems although the linkage sp ecication syntax is not yet standardized Another technique sometimes used is to set up interpro cess communication IPC between dierent pro cesses The IPC may in fact link programs running on dierent computers Either technique provides an alternative to the traditional concept of the users explicit editing of symb olic mathematical text into a numeric source program although the IPC technique is even less likely to b e robust in the face of errors than the foreignfunction linkage Using b oth of these metho ds the Waikato group has written a number of in terfaces Naglink was written b etween Macsyma and the NAG Library Numlink between Senac and Graink and the NAG Fortran Library and Graphics Library These references describ e howcomponents have b een integrated to provide a very highly automated problemsolving environment combining symb olic numeric and graphic to ols As exp ected the approaches retain the eciency and robustness of Fast FloatingPoint Pro cessing in Common Lisp the Fortran co de They automate using interface programs written in Lisp the calling and return pro cesses and userwritten subroutines demanded bysome Fortran packages eg numerical integration minimization can in fact b e written by Senac rather than the user An additional b enet of the Senac approachisthat the user need not attend to the tedious requirements to provide output formatting In spite of success in researchenvironments there have b een obstacles to the widespread propagation and generalization of these concepts They include The lack of a language standard for foreign function interfaces in Common Lisp Standardization on this topic is arguably to o dicult or controversial to hold out much exp ectation for a standard so on The low standard of maintenance of implementation dep endent foreign func tion interfaces and linkers in general by language and op erating system or hardware vendors The Waikato exp erience has b een that of grappling with a succession of serious bugs Lack of compatibilitybetween libraries for dierent language compilers and between ob jectco de formats for the same compiler at dierent revision levels This diversity has created a degree of insecurity for this and other comp osite language environment develop ers Op erating system defects Wecontinue to see ma jor computer corp orations releasing versions of their op erating systems for highsp eed workstations with no provision for dynamic linking In this pap er we explore an approachwhich enables all of the problems listed ab ovetobesolved at a single stroke use Lisp as the source language for the numeric and graphical co de This is not a new idea it was tried at MIT and UCB in the s While these exp eriments were mo destly successful the particular systems are obsolete Fortunately some of those ideas used in Maclisp NIL andFranz Lisp were incorp orated in the subsequent standardization of Common Lisp CL In this new setting it is appropriate to reexamine the theoretical and practical implications of writing numeric co de in Lisp The p opular conceptions of Lisps ineciency for numerics have b een based on rumor supp osition and exp erience with early and in fact inecient implemen tations It is certainly p ossible to continue to write inecient programs As one example of the results of deemphasizing numerics in the design consider the situ ation of the basic arithmetic op erators The denitions of these functions require that they are generic eg must b e able to add anycombination of several pre cisions of oats arbitraryprecision integers rational numb ers and complexes The very simple way of implementing this arithmetic b y subroutine calls is also v ery inecient Even with appropriate declarations to enable more sp ecic treatmentof numeric typ es compilers are free to ignore declarations and such implementations naturally do not accommo date the needs of intensivenumb ercrunching See the app endix for further discussion of declarations Be this as it may the situation with resp ect to Lisp has changed for the b etter in recentyears With the advent of ANSI standard Common Lisp several active vendors of implementations and one active university research group Carnegie Mel lon there has b een a signicantimprovement in the quality and eciency of the R J Fateman et al numeric facilities available in Lisp systems Based on our exp erience rep orted in part in this pap er we exp ect that co de from Common Lisp compilers can demon strate