[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: CL-Cleanup@Sail.Stanford.EDU*Subject*: Issue: REAL-NUMBER-TYPE (version 1)*From*: Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>*Date*: Fri, 6 Jan 89 17:36 EST*Cc*: DySak@STONY-BROOK.SCRC.Symbolics.COM, JGA@STONY-BROOK.SCRC.Symbolics.COM, Common-Lisp-Implementors@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 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). 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: Occassional inconvenience and/or inefficiency. Benefits: Mathematical clarity. Ability to define CLOS class by the same name for the purpose of method dispatch. 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.

**Follow-Ups**:**Issue: REAL-NUMBER-TYPE (version 1)***From:*Jon L White <jonl@lucid.com>

- Prev by Date:
**Issue FUNCTION-COMPOSITION** - Next by Date:
**Re: Issue MACRO-FUNCTION-ENVIRONMENT, v1** - Previous by thread:
**** BALLOT ** BALLOT ** BALLOT ** BALLOT **** - Next by thread:
**Issue: REAL-NUMBER-TYPE (version 1)** - Index(es):