Fast Floating-Point Processing in Common Lisp

Fast Floating-Point Processing in Common Lisp (1995)

Cached

Download Links

[http.cs.berkeley.edu]

by Richard J. Fateman , Kevin A. Broughan , Diane K. Willcock , Duane Rettig , Franz Inc

Venue:	ACM Trans. on Math. Software
Citations:	5 - 1 self

Versions

Version History

Metadata Version 3

User correction supplied by SystemCorrections

Datum	Value	Source
TITLE	Fast Floating-Point Processing in Common Lisp	user correction - Legacy Corrections
AUTHOR NAME	Richard J. Fateman	SVM HeaderParse 0.1
AUTHOR AFFIL	University of California, Berkeley; and	SVM HeaderParse 0.2
AUTHOR NAME	Kevin A. Broughan	SVM HeaderParse 0.1
AUTHOR AFFIL	University of Waikato; and	SVM HeaderParse 0.2
AUTHOR NAME	Diane K. Willcock	SVM HeaderParse 0.1
AUTHOR AFFIL	University of Waikato; and	SVM HeaderParse 0.2
AUTHOR NAME	Duane Rettig	SVM HeaderParse 0.1
AUTHOR NAME	Franz Inc	SVM HeaderParse 0.1
ABSTRACT	this paper we explore an approach which enables all of the problems listed above to be solved at a single stroke: use Lisp as the source language for the numeric and graphical code! This is not a new idea --- it was tried at MIT and UCB in the 1970's. While these experiments were modestly successful, the particular systems are obsolete. Fortunately, some of those ideas used in Maclisp [37], NIL [38] and Franz Lisp [20] were incorporated in the subsequent standardization of Common Lisp (CL) [35]. In this new setting it is appropriate to re-examine the theoretical and practical implications of writing numeric code in Lisp. The popular conceptions of Lisp's inefficiency for numerics have been based on rumor, supposition, and experience with early and (in fact) inefficient implementations. It is certainly possible to continue to write inefficient programs: As one example of the results of de-emphasizing numerics in the design, consider the situation of the basic arithmetic operators. The definitions of these functions require that they are generic, (e.g. "+" must be able to add any combination of several precisions of floats, arbitrary-precision integers, rational numbers, and complexes), The very simple way of implementing this arithmetic -- by subroutine calls -- is also very inefficient. Even with appropriate declarations to enable more specific treatment of numeric types, compilers are free to ignore declarations and such implementations naturally do not accommodate the needs of intensive number-crunching. (See the appendix for further discussion of declarations). Be this as it may, the situation with respect to Lisp has changed for the better in recent years. With the advent of ANSI standard Common Lisp, several active vendors of implementations and one active universi...	user correction - Legacy Corrections
YEAR	1995	INFERENCE
VENUE	ACM Trans. on Math. Software	INFERENCE
VENUE TYPE	JOURNAL	INFERENCE
PAGES	26--62	INFERENCE
VOLUME	21	INFERENCE
CITATIONS	41 found	ParsCit 1.0