From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4 Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/5/84; site ssc-vax.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!vax135!cornell!uw-beaver!ssc-vax!tjj From: tjj@ssc-vax.UUCP (T J Jardine) Newsgroups: net.ai,net.lang.lisp,net.lang.ada Subject: Re: Fortran better than Lisp for numerical code? Message-ID: <537@ssc-vax.UUCP> Date: Wed, 20-Mar-85 16:04:15 EST Article-I.D.: ssc-vax.537 Posted: Wed Mar 20 16:04:15 1985 Date-Received: Fri, 22-Mar-85 03:14:00 EST References: <253@bu-cs.UUCP> <320@cmu-cs-k.ARPA> <3829@mit-eddie.UUCP> Organization: Boeing Aerospace Co., Seattle, WA Xref: watmath net.ai:2651 net.lang.lisp:410 net.lang.ada:249 List-Id: > There has been much discussion of late about comparing Lisp and Fortran > for numerical code. Many people have either stated or implied that > Fortran should be better for number crunching than Lisp. Why do people > believe that? Why should a Fortran compiler produce any better code for > A=B*C > than a Lisp compiler would produce for > (setq a (* B C)) > (assuming, in the latter case, appropriate declarations or use of > non-generic functions)? ... I won't try to speak about what others mean, but I know that what I mean when I say that Fortran is "better" for numeric computations has nothing to do at all with a=b*c or its ilk. Certainly with appropriate attention to detail Lisp can handle (setq a (* b c)) with just as much efficiency. Fortran (or Pascal, ...) is a more appropriate choice if the numeric computations are at a higher level, such as the computations involved in simulating the flight dynamics of an air vehicle, or in solving celestial navigation problems. In such a case the optimum is that the problem solution already exists and one must "link" to the solution and obtain its results. In a slightly less optimal situation a library of subroutines/functions exists which need to be coupled in some obvious way and then this coupling "linked" to the Lisp environment to obtain the solution. The point is, I believe, that just because we have Lisp, or a new "AI problem solving approach" does not mean that we should reinvent all problem solutions using this new approach. Decision tables still provide an effective problem solving tool for certain classes of problems -- why not use such a capability when it is applicable? It may be the case that other factors will influence us to rewrite a solution using our new tool or approach -- I hope I don't ever have to write another communications control program in COBOL, for example, although COBOL was indeed capable of handling the particular problem at the time. By the way, double precision floating point is the default in Franz Lisp (I haven't yet found a way to create a single precision variable, but haven't pursued it that far), and I know double precision is also available in Zetalisp. The list very likely larger than just those two -- Common Lisp probably has it. Ted Jardine TJ (with Amazing Grace) The Piper Boeing Artificial Intelligence Center ...uw-beaver!ssc-vax!bcsaic!ted -- TJ (with Amazing Grace) The Piper Boeing Artificial Intelligence Center ...uw-beaver!ssc-vax!bcsaic!ted