Issue: REAL-NUMBER-TYPE (version 2)

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

    Date: Mon, 9 Jan 89 17:57 PST
    From: 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
        [...]

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

CL currently does not try to carefully restrict extensions to itself.
Overall, this is probably good although there are reasons to want a
strict language, too.  I think that the best we can do for any given
point in the development of the language is to describe what it *is* and
pick the sharpest possible terms for all the concepts, so that we don't
*preclude* interesting extensions.

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

... in the existing language.

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

Again, I don't think we should try to guess what extensions might be
interesting.  An extension should be made "the right way."

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

        [...]
	Benefits:

	  Mathematical clarity.

    Arguable.

	  Ability to do CLOS method dispatch on the type.

	[...]
	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.

As noted above, there should be no "policy" on future extensions.

	  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.

Any program which depends in any significant way on range or precision
must *always* be translated carefully -- even when moving from one
Fortran implementation to another.  Experts always need to know
*exactly* how a particular computation will be done, and will always
have to read reference manuals carefully.

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

We're not adamant about the name "real".  We do believe strongly that
the concept should be a part of the language as a distinct named type.
Suggestions for a better name are welcome.

You can't seriously expect a language definition to "carefully and
thoroughly" document all the differences between all other uses of a
word and the use in that language.  You are certainly right that a
"compatibility note" of the sort already in CLtL is warranted.  A
distilled version of your comments here would be quite appropriate.