[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: REAL-NUMBER-TYPE (version 2)
- To: Cassels@STONY-BROOK.SCRC.Symbolics.COM
- Subject: Issue: REAL-NUMBER-TYPE (version 2)
- From: Marc Le Brun <MLB@WHITE.SWW.Symbolics.COM>
- Date: Mon, 9 Jan 89 17:57 PST
- Cc: CL-Cleanup@Sail.Stanford.EDU, DySak@STONY-BROOK.SCRC.Symbolics.COM, JGA@STONY-BROOK.SCRC.Symbolics.COM, Common-Lisp-Implementors@STONY-BROOK.SCRC.Symbolics.COM, rwg@WHITE.SWW.Symbolics.COM
- In-reply-to: <19890108162936.5.CASSELS@GROUSE.SCRC.Symbolics.COM>
Date: Sun, 8 Jan 89 11:29 EST
From: Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>
References: Table 4-1.
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
There is no standard type specifier symbol for the CL type
'(OR RATIONAL FLOAT).
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
Add a standard type specifier
(REAL low high)
(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.
Add a specific data type predicate REALP which tests for membership in
this type. [By analogy with NUMBERP.]
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).
Mathematics has a name for (OR RATIONAL FLOAT) -- it is "real".
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
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).
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
Cost of Non-Adoption:
Occasional inconvenience and/or inefficiency.
Ability to do CLOS method dispatch on the type.
As mentioned under "rationale," this would be a more concise way to
express a common programming idiom.
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
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
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).