Re: various: arithmetic; commonlisp broadcasts

[Guy.Steele at CMU-10A]

I sent the mail to the specified representatives of Berkeley and Utah
not because they were "token" but because they were the ones that had
actually contributed substantially to the discussion of outstanding issues.
I assumed that they would pass on the news.  I'll be glad to add you to
the mailing list if you really want that much more junk mail.

It should be noted that the InterLISP representative's report is just that:
the report of the InterLISP representative.  I think it is an excellent
report, but do not necessarily agree with all of its value judgements
and perspectives.  Therefore the motivations induced by vanMelle and
suggested in his report are not necessarily the true ones of the other
people involved.  I assume, however, that they accurately reflect vanMelle's
*perception* of people's motives, and as such are a valuable contribution
(because after all people may not understand their own motives well, or
may not realize how well or poorly they are communicating their ideas!).

You ask why Common LISP should support ratios and complex numbers, given
that MacLISP did not and yet MACSYMA got built anyway.  In response,
I rhetorically ask why MacLISP should have supported bignums, since
the PDP-10 does not?  Ratios were introduced primarily because they are
useful, they are natural for novices to use (at least as natural as
binary floating-point, with all its odd quirks, and with the advantage
of calculating exact results, such as (* 3 1/3) => 1, *always*), and
they solve problems with the quotient function.  Complex numbers were
motivated primarily by the S-1, which can handle complex floating-point
numbers and "Gaussian fixnums" primitively.  They need not be in Common
LISP, I suppose, but they are not much work to add.

The results of elementary functions are not being invented in a vacuum,
as you have several times insinuated, nor are the Common LISP implementors
going off and inventing some arbitrary new thing.  I have researched
the implementation, definition, and use of complex numbers in Algol 68,
PL/I, APL, and FORTRAN, and the real elementary functions in another
half-dozen languages.  The definitions of branch cuts and boundary cases,
which are in general not agreed on by any mathematicians at all (they tend
to define them *ad hoc* for the purpose at hand), are taken from a paper
by Paul Penfield for the APL community, in which he considers the problem
at length, weighs alternatives, and justifies his results according to
ten general principles, among which are consistency, keeping branch cuts
away from the positive real axis, preserving identities at boundaries,
and so on.  This paper has appeared in the APL '81 conference.  I agree that
mistakes have been made in other programming languages, but that does not
mean we should hide our heads in the sand.  A serious effort is being made
to learn from the past.  I think this effort is more substantial than will
be made by the dozens of Common LISP users who will have to write their
own trig functions if the language does not provide them.

Even if a mistake is made, it can be compensated for.  MACSYMA presently
has to compensate for MacLISP's ATAN function, whose range is 0 to 2*pi
(for most purposes -pi to pi is more appropriate, and certainly more
conventional).

[Could I inquire as to whether (FIX 1.0E20) still produces a smallish
negative number in Franz LISP?]

I could not agree more that all of this is relevant, not to *algebraic*
manipulation, but to *arithmetic* manipulation (although certainly the
presence of rational arithmetic will relieve MACSYMA of that particular
small burden).  But there is no good reason why LISP cannot become a
useful computational and well as symbolic language.  In particular,
certain kinds of AI work such as vision and speech research require
great amounts of numerical computation.  I know that you advocate
methods for linking FORTRAN or C programs to LISP for this purpose.
That is well and good, but I (for one) would like it also to be
practical to do it all in LISP if one so chooses.  LISP has already
expanded its horizons to support text editors and disk controllers;
why not also number-crunching?

--Guy