Issue COMPLEX-RATIONAL-RESULT, version 2

[gls@Think.COM]

This was a good thing for Moon to bring up, but I think a couple
of desirable details were left uncovered.  Here is a new version
to consider in June.

Detail 1 is that a mathematically rational or complex rational
value might result from arguments that are a mixture of rational
and complex rational; or a complex rational value might result
 from arguments that are rational only.

Detail 2 is that the version 1 proposal mentions (complex float)
where I believe the more specific (complex single-float) is appropriate.

Detail 3 is that in some cases the option of an ordinary float
result is desirable or required rather than a (complex single-float);
consider the ABS function, for example.

Detail 4 is that if the true mathematical result is not rational
or complex rational, I think we want to specify that the returned
value is single-float or (complex single-float).

----------------------------------------------------------------
Issue:         COMPLEX-RATIONAL-RESULT

References:    CLtL p.203

Category:      CLARIFICATION

Edit history:  Version 1, 20-Mar-89, by Moon
               Version 2, 08-Apr-89, by Steele

Problem description:
  
  Referring to irrational and transcendental functions, CLtL says:
    
    When the arguments to a function in this section are all rational and
    the true mathematical result is also (mathematically) rational, then
    unless otherwise noted an implementation is free to return either an
    accurate result of type rational or a single-precision floating-point
    approximation.  If the arguments are all rational but the result cannot
    be expressed as a rational number, then a single-precision
    floating-point approximation is always returned.

  Referring to EXPT, CLtL says:

    If the base-number is of type RATIONAL and the power-number is an
    INTEGER, the calculation will be exact and the result will be of
    type RATIONAL; otherwise a floating-point approximation may result.

  What about arguments of type (complex rational)?

Proposal (COMPLEX-RATIONAL-RESULT:EXTEND):

  Extend the paragraph quoted above as follows to cover the components
  of complex numbers.  If the arguments to a function are all of type
  (OR RATIONAL (COMPLEX RATIONAL)) and the true mathematical result is
  (mathematically) a complex number with rational real and imaginary
  parts, then unless otherwise noted an implementation is free to return
  either an accurate result of type (OR RATIONAL (COMPLEX RATIONAL)) or
  a single-precision floating-point approximation of type SINGLE-FLOAT
  (permissible only if the imaginary part of the true mathematical
  result is zero) or \cd{(COMPLEX SINGLE-FLOAT). If the arguments are
  all of type (OR RATIONAL (COMPLEX RATIONAL)) but the result cannot be
  expressed as a rational or complex rational number, then the returned
  value will be of type SINGLE-FLOAT (permissible only if the imaginary
  part of the true mathematical result is zero) or (COMPLEX SINGLE-FLOAT).

  For EXPT of a (COMPLEX RATIONAL) to an integer power, the
  calculation must be exact and the result will be of type
  (OR RATIONAL (COMPLEX RATIONAL)).

Examples:

  (log #c(-16 16) #c(2 2)) => 3 or approximately #c(3.0 0.0)
			        or approximately 3.0 (unlikely)
  (abs #c(3/5 4/5)) => 1 or approximately 1.0
  (expt #c(2 2) 3) => #c(-16 16)
  (expt #c(2 2) 4) => -64 

Rationale:
  
  This seems most consistent with the treatment of real numbers.

Current practice:
  
  Symbolics Genera 7.4 returns a (complex float) for the first example
  and returns the specified answers for the second and third examples.
  Other implementations were not surveyed.

Cost to Implementors:

  Only EXPT would have to change, since the type of the other results
  is at the discretion of the implementation.

Cost to Users:

  Probably none, but it is hard to predict.

Cost of non-adoption:
  
  Slightly less self-consistent language.

Performance impact:

  None of any significance.

Benefits/Esthetics:

  More self-consistent language.

Discussion:

  None.