Issue: REAL-NUMBER-TYPE (version 2)

[Marc Le Brun <MLB@WHITE.SWW.Symbolics.COM>]

    Date: Sun, 8 Jan 89 11:29 EST
    From: 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):

I apologize for the size of this response, but since this is sort of a "dissenting opinion" I
felt it would be good to document the arguments as carefully as I could.

There are dangers in introducing the term REAL.  It encourages the widespread confusion
between a computer type, REAL, which of necessity denotes a countable class of symbols, with
the mathematical object (which I'll call R), which is non-denumerable.  This identification of
incommensurables has many unfortunate consequences, including ambiguous and inconsistent use
of "intuitive" models.  Further, members of these sets which are commonly identified with
eachother (ie real numbers and their computer images) often have incompatible semantics.

The original Common Lisp specification did the world a service by eliminating this source of
potential confusion.  If the term is to be reintroduced for pragmatic reasons, then it should
at least done very carefully, so as not to result in further propagation, even amplification,
of these problems.  It doesn't seem either responsible or forward-looking to gloss over these
difficult issues.

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

The Discussion section below implies that future extensions should be considered here.

Suppose an implementation introduces new types which model members of R but which do not
satisfy this predicate.  (For example, quadratic fields, or symbols denoting rational
multiples of (mathematical) pi, say).  Is the implementation allowed to extend the type REAL
or not?  I'd vote to allow extension, but in any case this should be stated.  (Further, must
it so extend it?)

      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).

Suppose an implementation introduces new types which could considered numeric but which do not
satisfy this predicate.  (For example, quaternions, as mentioned in the Discussion).  Is the
implementation allowed to extend the type NUMBER or not?  I'd vote to allow extension, but in
any case this should be stated.  (Further, must it so extend it?)

      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".

No.  

1. As noted above R contains many "useful" elements (eg surds, mathematical pi or e) which can
have discrete symbolic representations but whose behavior is not accurately modeled by any
REAL element.

2. Under many circumstances the semantics of "typical" elements of REAL are quite distinct
 from the elements of R with which they are commonly identified, leading to a variety of
situational interpretations as "intervals", "fuzzy numbers", etc which clearly do not belong
to the theory of R.

3. Conversely operations on elements of R conform to a semantics of "infinite precision"
obviously unattainable by REALs.

4. REAL also may contain specific entities (such as -0.0) not in R.

5. Because of finite range limitations REAL further does not consistently "cover" R.
Sometimes this is dealt with as an error, sometimes with the introduction of non-analytic
semantics (eg setting underflows to zero), sometimes by introducing non-standard entities
partially or wholly outside R (eg the various "infinities", or the IEEE "Not-A-Number"s which
(at least in Symbolics CL) paradoxically satisfy NUMBERP!).

6. Since there is no "floating canonicalization", the type REAL contains multiple distinct
images of certain elements of R (notably zero, many rationals, and many flonums which exist in
more than one so-called "precision").

      This class is important because it is all the numbers which can be ordered.

Agreed that the ordering property of R is important.  It might be possible to have CL so
define REAL specifically as some kind of maximal well-ordered set (though this might be
tricky, in order to exclude characters as potential numbers, for example).

(And, mathematically anyway, one might even ask for more rigor regarding the term "ordered",
considering, for example, Conway numbers.  This would be a gratuitous comment except for IEEE
having already opened the Pandora's box of non-standard numbers.)

      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."

Presumably this is to be read as a proposal to substitute "real" for "non-complex number"?
Note that these restrictions are apparently motivated by different properties: in some cases
ordering, in others an aversion to imaginary algebra (eg the mystifying restrictions on CIS,
COMPLEX et al).  Depending on the extension policy adopted that substitution might or might
not retain its validity under an extension (eg symbols for rational multiples of mathematical
pi aren't (OR RATIONAL FLOAT) but might be an acceptable, indeed useful, subdomain for CIS).

    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.

Arguable.

      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]

As noted above, the policy regarding possible extensions, either as future CL standards or
per-implementation, should be clarified in several respects.

      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.

This needs clarification.  If by "equivalent Fortran program" is meant a FORTRAN program that
was specifically (heroically?) written to carefully model a CL program, then this begs the
question.  If it means "a naive translation" between languages, then this is far from obvious
(eg a CL implementation might generate rationals, thereby maintain different information
through subsequent operations, and finally get results diverging significantly from the
FORTRAN program).

One could also easily imagine some careful conventional flonum-based numerical analysis being
thrown off by the introduction of a non-zero rational smaller than CL "epsilon", for example.
The assignation of "more accurate" is application-dependent and implementation-dependent.

      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.

Agreed, the proposed type is an extension of what's commonly meant by the name REAL.
(Although there exist unusual systems where REALs are implemented by decimal rationals!)
While the "average programmer" may be comfortable, the differences between CL REALs and
conventional REALs and their implications should be carefully and thoroughly documented in the
standard (leaving aside the quagmire of confusion with regards to R).