[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
gaussian rationals, transcendental functions, etc.
- To: Common-Lisp @ SU-AI
- Subject: gaussian rationals, transcendental functions, etc.
- From: Alan Bawden <ALAN @ MIT-MC>
- Date: Sun, 05 Jun 1983 22:58:00 -0000
Date: 5 Jun 83 11:13:57 PDT (Sun)
From: fateman%UCBKIM at Berkeley (Richard Fateman)
Frankly, complex arithmetic should not be designed by a consensus of Lisp
hackers. The difference between mathematical theory and computation
is perhaps not clear to Alan, but there is a difference between thinking
mathematically and computationally.
I believe I have now argued this point from both mathematical and
computational standpoints, and have demonstrated how to fit the two
together acceptably. I'll not continue to argue the issue. If a degree in
mathematics and several years experience as a "Lisp hacker" don't qualify
me to have an intelligent opinion on this subject in fateman's eyes, so be
it. If anyone else would like to say something new on the subject...
The issue raised by Fahlman about needing a rule that says that that
putting in a real gets you a real answer if possible, is dealt with by
specifying appropriate ranges for the transcendental functions. In the
laser manual, GLS has already suggested ranges that have this property.
(This is nothing new really, mathematicians have always chosen the
principle values of such functions to satisfy Fahlman's rule.) Let me
reiterate what I said yesterday: the only new behavior exhibited by that
handful of transcendental functions, when given a pure real argument, would
be the generation of a complex number in some cases, rather than an error.
BTW, I accidentally excluded the EXPT function from my list of
transcendental functions that have "questionable" (from a user-interface,
or "computational" viewpoint) regions in the real part of their domains.
So make that 7 functions with the "problem".
The suggestion that numbers like #C(3/4 3.14159) be eliminated has a
certain appeal. Would the proposal extend to eliminating numbers like
#C(1.0S0 1.0L0)? Eliminating such mixed floating types might frowned upon
by the masters of floating point, although I can also imagine that
converting this to #C(1.0L0 1.0L0), (that is, converting to the maximum of
the two precisions), would be acceptable to them.