numerics and common-lisp

[Kim.fateman at Berkeley]

The following stuff was sent a while back to GLS, and seemed to
provoke no comment; although it probably raises more questions
than answers, here goes:

*** Issue 81: Complex numbers. Allow SQRT and LOG to produce results in
whatever form is necessary to deliver the mathematically defined result.

RJF:  This is problematical. The mathematically defined result is not
necessarily agreed upon.  Does Log(0) produce an error or a symbol?
(e.g. |log-of-zero| ?)  If a symbol, what happens when you try to
do arithmetic on it? Does sin(x) give up after some specified max x,
or continue to be a periodic function up to limit of machine range,
as on the HP 34?  Is accuracy specified in addition to precision?
Is it possible to specify rounding modes by flag setting or by
calling specific rounding-versions e.g. (plus-round-up x y) ? Such
features make it possible to implement interval arithmetic nicely.
Can one trap (signal, throw) on underflow, overflow,...
It would be a satisfying situation if common lisp, or at least a
superset of it, could exploit the IEEE standard. (Prof. Kahan would
much rather that language standardizers NOT delve too deeply into this,
leaving the semantics  (or "arithmetics") to specialists.)

Is it the case that a complex number could be implemented by
#C(x y) == (complex x y) ?  in which case  (real z) ==(cadr z),
(etc); Is a complex "atomic" in the lisp sense, or is it
the case that (eq (numerator #C(x y)) (numerator #C(x z)))?
Can one "rplacâ??numerator"?
If one is required to implement another type of atom for the
sake of rationals and another for complexes,
and another for ratios of complexes, then the
utility of this had better be substantial, and the implementation
cost modest.  In the case of x and y rational, there are a variety of
ways of representing x + i*y.  For example, it
is always possible to rationalize the denominator, but is it
required?
If  #R(1 2)  == (rat 1 2), is it the case that
(numerator r) ==(cadr r) ?  what is the numerator of (1/2+i)?

Even if you insist that all complex numbers are floats, not rationals,
you have multiple precisions to deal with.  Is it allowed to
compute intermediate results to higher precision, or must one truncate
(or round) to some target precision in-between operations?

.......
Thus (SQRT -1.0) -> #C(0.0 1.0) and (LOG -1.0) -> #C(0.0 3.14159265).
Document all this carefully so that the user who doesn't care about
complex numbers isn't bothered too much.  As a rule, if you only play
with integers you won't see floating-point numbers, and if you only
play with non-complex numbers you won't see complex numbers.
.......
RJF: You've given 2 examples where, presumably, integers
are converted not only into floats, but into complex numbers. Your
rule does not seem to be a useful characterization.
Note also that, for example, asin(1.5) is complex.

*** Issue 82: Branch cuts and boundary cases in mathematical
functions. Tentatively consider compatibility with APL on the subject of
branch cuts and boundary cases.
.......
RJF:Certainly gratuitous differences with APL, Fortran, PL/I etc are
not a good idea!
.....

*** Issue 83: Fuzzy numerical comparisons. Have a new function FUZZY=
which takes three arguments: two numbers and a fuzz (relative
tolerance), which defaults in a way that depends on the precision of the
first two arguments.

.......
RJF: Why is this considered a language issue (in Lisp!), when the primary
language for numerical work (Fortran, not APL) does not?  The computation
of absolute and relative errors are sufficiently simple that not much
would be added by making this part of the language.)  I believe the fuzz business is used to cover
up the fact that some languages do not support integers. In such systems,
some computations  result in 1.99999 vs. 2.00000 comparisons, even though
both numbers are "integers".

Incidentally, on "mod" of floats, I think that what you want is
like the "integer-part" of the IEEE proposal.  The EMOD instruction on
the VAX is a brain-damaged attempt to do range-reductions.
.......

*** Issue 93: Complete set of trigonometric functions? Add ASIN, ACOS,
and TAN.


*** Issue 95: Hyperbolic functions. Add SINH, COSH, TANH, ASINH, ACOSH,
and ATANH.
.....
also useful are log(1+x) and exp(1+x).


*** Issue 96: Are several versions of pi necessary? Eliminate the
variables SHORT-PI, SINGLE-PI, DOUBLE-PI, and LONG-PI, retaining only
PI.  Encourage the user to write such things as (SHORT-FLOAT PI),
(SINGLE-FLOAT (/ PI 2)), etc., when appropriate.
......
RJF: huh?  why not #.(times 4 (atan 1.0)),  #.(times 4 (atan 1.0d0)) etc.
It seems you are placing a burden on the implementors and discussants
of common lisp to write such trivial programs when the same thing
could be accomplished by a comment in the manual. Constants like e could
be handled too...

.......
.......
RJF: Sorry if the above comments sound overly argumentative.  I realize they
are in general not particularly constructive.
I believe the group here at UCB will be making headway in many
of the directions required as part of the IEEE support, and that Franz
will be extended.