[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: inexactness vs. exactness
On Jul 28, 2005, at 12:34 AM, William D Clinger wrote:
... the R5RS semantics of arithmetic
was designed to allow systems to implement the computable reals...
This is a very interesting comment that expands my understanding of
numerics in Scheme. I had realized earlier that Scheme's exact numbers
could be extended, e.g., to quadratic fields (with certain fixed m,
numbers are of the form a + b*sqrt(m), with a and b rational), but it
hadn't crossed my mind that the inexacts could be the computable reals.
I'm a "numerical" guy in the traditional sense, so most of my computing
is with floating-point (or fixed-point) arithmetic in Gambit. Late in
the beta series for 4.0, the Gambit compiler was improved to generate
much faster "safe" code, so for some applications I've just used
standard Scheme code, perhaps with a few top-level declarations, so
some of that code should be easily run on any R5RS system. (Maybe I'm
just getting older and prefer flexibility, safety, and "debugability"
over maximum speed for some applications.) It had never occurred to me
before that calling exact->inexact on some Scheme systems would invoke
arithmetic in the computable reals.
There was a somewhat related discussion in comp.lang.lisp this spring
prompted by a newbie's complaint that
(- 0.9 0.5)
did not evaluate to 0.4 in the Common Lisp REPL. Let me quote from
After pointing out that in Maxima, an application (now) written in
Common Lisp, 0.9-0.5 really *does* evaluate to 0.4, Fred Gilham
Seems like the issue is to distinguish between applications, which
have user-related specs, and language-level representations, which
have programmer-related specs. The point is that there are floating
point numbers which behave a certain way. These numbers are intended
for programmer use. They behave the way they do because people have
sat down and figured out that it's a good idea for them to behave that
The fact that some person might type at the lisp REPL and expect it to
act like a pocket calculator is not a good reason to change the way
these numbers are represented. It might be a good reason to write a
"pocket calculator emulator" in common lisp, or to point someone at
So I think the question is, "Do we want to separate user-related specs
from program-related specs?" Do we want Scheme to be a language where
a conforming implementation could specify the computable reals as the
default inexact representation for all applications, or do we want
Scheme to be a language where inexact arithmetic is implemented by
floating-point arithmetic by default and the use of the computable
reals for inexact arithmetic can be specified (by loading a module, for
example) for certain applications?
From my limited knowledge of Common Lisp, it seems that that community
has chosen the second path (going so far as to forbid the re-definition
of functions in the standard "Common Lisp" package, so you would have
to work in a new package before the arithmetic functions could be
shadowed by versions that use the computable reals).
Perhaps in Scheme we want to take a slightly different path---specify
floating-point as the default implementation but continue to allow
redefinition of standard functions.