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

*To*: common-lisp@su-ai*Subject*: numerics and common-lisp*From*: Kim.fateman at Berkeley*Date*: Wed, 20 Jan 1982 20:29:00 -0000

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.

- Prev by Date:
**Re: Suggestion** - Next by Date:
**Keyword style sequence functions** - Previous by thread:
**Suggestion** - Next by thread:
**Keyword style sequence functions** - Index(es):