NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/lang/lisp/2229

Internet Message Format | 1992-08-14 | 2.7 KB

Path: sparky!uunet!dove!cam!ARTEMIS
From: [e-mail] (Bruce R. Miller)
Newsgroups: comp.lang.lisp
Subject: Re: floating point precision
Message-ID: <[e-mail]>
Date: 14 Aug 92 18:29:26 GMT
References: <[e-mail]>
Sender: [e-mail]
Organization: NIST - Computing and Applied Mathematics Laboratory
Lines: 50


In article <[e-mail]>, Barry Margolin writes:
> In article <[e-mail]> [e-mail] (ken yip) writes:
> >How can one specify the floating point precision of a numerical
> >routine?
>
> All the mathematical functions in CL are generic, and will operate on any
> floating point types, returning results of the same type (if multiple
> arguments of different types are provided, it will coerce them all to the
> largest one).  So, if you want to see the result of performing the
> computation in double-float, provide double floats as the initial input.

That's completely true --- as far as it goes.

But, you do pay a performance price for generic arithmetic, especially
in inner loops.  This is complicated by numerical constants which appear
in any non-trivial numerical code.

Even in a system with efficient dispatch which ignores type
declarations, the cost of repeatedly converting rational constants to
floats is significant (I dont have figures handy, though).  If you code
them as single precision constants you loose accuracy when you give
double-float inputs.  On the other hand, coding double-float constants
infect the results and you'll double-float answers; they'll be
expensive but most likely no more accurate than your single float
results!

Of course, if run time is not a concern, then code it in generic, using
rational constants.

I recently asked advice here  on a similar problem and got some good help
from Barry, Chris McConnel, Bob Kern and others (thanks!).

The most elegant solution proposed involved code-walkers. Unfortunately,
to do it right requires knowledge of _all_ functions to be encountered
(ie. dependence of output types on input types). It would probably be
easily piggybacked onto an inference scheme & database like Python, but
I didn't feel like developing the database myself.

My solution was to develop a macro which extended the abstraction of
generic arith.  It checks the types of some of the args and branches to
the duplicate of the body which has been `optimized' for that type.
There's a second macro to be used within the outer one which coerces a
number or named constant to the appropriate type.
The code that you write using this is a bit on the verbose side :< but
it does work.
[My version does no declarations, though.]

bruce
[e-mail]