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

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

**Follow-Ups**:**Issue: REAL-NUMBER-TYPE (version 2)***From:*Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

**Issue: REAL-NUMBER-TYPE (version 2)***From:*Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>

**References**:**Issue: REAL-NUMBER-TYPE (version 2)***From:*Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>

- Prev by Date:
**Re: Issue: REAL-NUMBER-TYPE (version 2)** - Next by Date:
**Re: Issue: OUTPUT-STREAM-P-EXAMPLE** - Previous by thread:
**Issue: REAL-NUMBER-TYPE (version 2)** - Next by thread:
**Issue: REAL-NUMBER-TYPE (version 2)** - Index(es):