Issue: REAL-NUMBER-TYPE (version 2)

[Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>]

Issue:        REAL-NUMBER-TYPE
Forum:	      CLEANUP
References:   Table 4-1.
Category:     ADDITION
Edit history: 04-JAN-89, Version 1 by Bob Cassels, Don Sakahara, Kent Pitman,
                         and John Aspinall
              08-JAN-89, Version 2 by Bob Cassels -- incorporate
                         Masinter's suggestion and make REAL a CLOS class
Status:	      For Internal Discussion

Problem Description:

  There is no standard type specifier symbol for the CL type
  '(OR RATIONAL FLOAT). 

Proposal (REAL-NUMBER-TYPE:REAL):

  Add a standard type specifier
   (REAL low high)
  which means
   (OR (RATIONAL low high) (FLOAT low high))

  As with other such type specifiers, define that if the low and high
  are omitted, the atomic specifier REAL may be used.

  Clarify that NUMBER is equivalent to (OR REAL COMPLEX).

  Make REAL a built-in CLOS class.

Proposal (REAL-NUMBER-TYPE:REALP):

  Add a specific data type predicate REALP which tests for membership in
  this type.  [By analogy with NUMBERP.]

Test Case:

  If a programmer wishes to test for "a number between 1 and 10", the
  only current CL types would be '(or (rational 1 10) (float 1 10)) or
  something like '(and numberp (not complexp) (satisfies range-1-10))
  with (defun range-1-10 (real) (<= 1 real 10)).  Both of these are
  likely less efficient, and certainly less expressive than '(real 1 10).

Rationale:

  Mathematics has a name for (OR RATIONAL FLOAT) -- it is "real".
  This class is important because it is all the numbers which can be
  ordered.

  Throughout the "Numbers" chapter, the phrase "non-complex number" is
  used.
  MAX, MIN, p. 198 "The arguments may be any non-complex numbers."
  CIS p. 207 "The argument ... may be any non-complex number."

Current Practice:

  Probably nobody does this.
  
Cost to Implementors:

  Some work is necessary to add this name.  But since the underlying
  type already exists the amount of work should be minimal.
  
Cost to Users:

  Since this is an upward-compatible extension, it may be ignored by
  users.

Cost of Non-Adoption:

  Occasional inconvenience and/or inefficiency.

Benefits:

  Mathematical clarity.

  Ability to do CLOS method dispatch on the type.

Aesthetics:

  As mentioned under "rationale," this would be a more concise way to
  express a common programming idiom.

Discussion:

  The name "non-complex number" is incorrect because future
  implementations may wish to include numerical types which are neither
  complex nor real.  [e.g. pure imaginary numbers or quaternions]
  
  The name "scalar" is incorrect because the mathematical concept of
  scalar may indeed include complex numbers.

  Fortran and Pascal use the name "real" to mean what CL calls
  SINGLE-FLOAT.  That should cause no significant problem, since a Lisp
  program written using the type REAL will do mathematically what the
  equivalent Fortran program would do.  This is because Fortran's "real"
  data-type is a subtype of the CL REAL type.  The only differences
  might be that the Lisp program could be less efficient and/or more
  accurate.

  A survey of several Fortran and Pascal books shows that the distinction
  between INTEGER and REAL is that REAL numbers may have fractional
  parts, while INTEGERs do not.  Later discussions explain that REALs
  cover a greater range.  Much later discussions cover precision
  considerations, over/underflow, etc.  So the average Fortran or Pascal
  programmer should be completely comfortable with the proposed Lisp
  concept of REAL.