[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: REAL-NUMBER-TYPE (version 2)
- To: CL-Cleanup@Sail.Stanford.EDU
- Subject: Issue: REAL-NUMBER-TYPE (version 2)
- From: Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Sun, 8 Jan 89 11:29 EST
- Cc: DySak@STONY-BROOK.SCRC.Symbolics.COM, JGA@STONY-BROOK.SCRC.Symbolics.COM, Common-Lisp-Implementors@STONY-BROOK.SCRC.Symbolics.COM
- Supersedes: <19890106223654.4.CASSELS@GROUSE.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).
Add a standard type specifier
(REAL low high)
(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.
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".
This class is important because it is all the numbers which can be
Throughout the "Numbers" chapter, the phrase "non-complex number" is
MAX, MIN, p. 198 "The arguments may be any non-complex numbers."
CIS p. 207 "The argument ... may be any non-complex number."
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]
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
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.