[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: inexactness vs. exactness

This page is part of the web mail archives of SRFI 70 from before July 7th, 2015. The new archives for SRFI 70 contain all messages, not just those from before July 7th, 2015.

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

http://groups-beta.google.com/group/comp.lang.lisp/msg/ d452669476b6b4ea?hl=en

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 writes:

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.