🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.lang.misc
Article #2534

Re: Lisp vs APL for numeric work (was Re: Fortran vs. C for numerical work)

#2534
From: Dave Gillett
Date: Fri, 21 Dec 1990 08:13
35 lines
2692 bytes
In <1990Dec20.050320.23027@Think.COM> barmar@think.com (Barry Margolin) writes:

>In article <1990Dec19.201059.16458@bernina.ethz.ch> mrys@bernina.UUCP (Michael Rys) writes:
>>What do you mean with multiple floating point formats? IEEE and such?

>It's been a long time since I've used APL, but I don't recall it having a
>way to specify single- vs. double-precision.

     That's because it's a high-level language!  In APL, "numeric" means "in
the minimum available precision sufficient to represent the value in question.

     There are occasional exceptions.  If you subtract the fractional part of 
A from A, the result may not collapse to integer internal representation
because either (a) the floating-point subtraction might not leave an exact 
integer result (hardware dependent) and/or (b) the interpreter, unless it is
doing some unusual optimiization, cannot know when it starts the subtraction
that the results will, in fact, be representable as integers.  The built-in
floor and ceiling primitives, though, know that their results will be integer,
and so can collapse the representation unless an element has a magnitude
outside the machine's integer range.
     This is the next best thing to arbitrary precision, but provides
considerably better performance over the most common data ranges.  (Yes, I
do understand that arbitrary precision allows exact representations over 
humonguous ranges; implementing it in APL is probably easier than in any
other language which doesn't have it built in, and the question comes down
to whether you need it or not.  If it were added to APL, it would transparently
replace double-precision, probably if the print-precision setting werre beyond
a certain threshold.)

     One way to look at it is that APL hides numeric representation from all but
the nosiest programmers.  Resort to an extended or arbitrary precision
representation is left as an implementation issue rather than a language
issue, and the fact that implementors have not provided this is no reflection
on the design of the language.
                                                   Dave
Technical Details
Message-ID: <634@saxony.pa.reuter.COM>
Path: arc1-ca.pugleaf.net!utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!uunet!saxony!dgil
References: <13615@chaph.usc.edu> <1990Dec12.175323.8958@Think.COM> <1990Dec19.201059.16458@bernina.ethz.ch> <1990Dec20.050320.23027@Think.COM>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!uunet!saxony!dgil
From: dgil@pa.reuter.COM (Dave Gillett)
Newsgroups: comp.lang.misc
Subject: Re: Lisp vs APL for numeric work (was Re: Fortran vs. C for numerical work)
Message-ID: <634@saxony.pa.reuter.COM>
Date: 21 Dec 90 08:13:45 GMT
References: <13615@chaph.usc.edu> <1990Dec12.175323.8958@Think.COM> <1990Dec19.201059.16458@bernina.ethz.ch> <1990Dec20.050320.23027@Think.COM>
Organization: Reuter:file Inc  (A Reuter Company) Palo Alto, CA
Lines: 35