Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!husc6!ut-sally!utah-cs!utah-orion!shebs
From: shebs@utah-orion.UUCP
Newsgroups: comp.lang.lisp
Subject: Re: LISP floating point performance
Message-ID: <150@utah-orion.UUCP>
Date: Thu, 12-Mar-87 18:14:39 EST
Article-I.D.: utah-ori.150
Posted: Thu Mar 12 18:14:39 1987
Date-Received: Fri, 13-Mar-87 22:40:36 EST
References: <1368@hplabsc.UUCP> <31800002@ccvaxa>
Reply-To: shebs@utah-orion.UUCP (Stanley T. Shebs)
Organization: PASS Research Group
Lines: 37

In article <31800002@ccvaxa> aglew@ccvaxa.UUCP writes:

>Using foreign functions as an excuse for not providing efficient floating
>in LISP is a cop-out.

There's one place where I'd definitely want to use foreign functions -
to call the irrational and transcendental functions in the 4.3 BSD libraries.
They are *hot*.  Certified performance and everything - wasn't clear to
me that a Lisp version could be done as good, given the current state of
compiler technology.

>Reusing existing code is fine - but if you're writing
>a new numeric algorithm (and not all numeric analysis was finished by
>the 60s) it would be nice to use a decent language, with decent macro
>facilities, and the ability to manipulate the program as data. I mean,
>have you ever tried to develop a generic interface to integration routines
>that work over arbitrary regions in N-space?

I haven't noticed numerical analysts beating down the doors of Lisp
implementors begging them to make floating point fast.  The only Lisp users
around here who care about floating point are graphics hackers.
But then Lisp isn't *that* different from Fortran; you've still got to
sequentialize your problem and write loops and do all those other nasty
programming things.  Gries & co at Cornell are working on a system called
Gibbs which is supposed to be a sort of numerical analysis tool that doesn't
involve programming directly - you give it some equations and it works out
a program to calculate on them in some specified way.  Macsyma does similar
things, and it writes Fortran programs as output instead of Lisp programs,
so efficiency of Lisp floating point is not as important.

Don't think Lisp; think non-procedural languages!

>Andy "Krazy" Glew. Gould CSD-Urbana.    USEnet:  ihnp4!uiucdcs!ccvaxa!aglew
>1101 E. University, Urbana, IL 61801    ARPAnet: aglew@gswd-vms.arpa

							stan shebs
							shebs@cs.utah.edu