Article View: comp.lang.misc
Article #2534Re: Lisp vs APL for numeric work (was Re: Fortran vs. C for numerical work)
From: Dave Gillett
Date: Fri, 21 Dec 1990 08:13
Date: Fri, 21 Dec 1990 08:13
35 lines
2692 bytes
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!dgilReferences:
<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