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

*To*: MLB@WHITE.SWW.Symbolics.COM, Cassels@STONY-BROOK.SCRC.Symbolics.COM*Subject*: Issue: REAL-NUMBER-TYPE (version 2)*From*: Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>*Date*: Tue, 10 Jan 89 13:40 EST*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*: <19890110015752.6.MLB@METAL-FLAKE.SWW.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.

**References**:**Issue: REAL-NUMBER-TYPE (version 2)***From:*Marc Le Brun <MLB@WHITE.SWW.Symbolics.COM>

- Prev by Date:
**Issue: COPY-SYMBOL-COPY-PLIST** - Next by Date:
**Re: Issue: SETF-SUB-METHODS (Version 5)** - Previous by thread:
**Issue: REAL-NUMBER-TYPE (version 2)** - Next by thread:
**Re: Issue: REAL-NUMBER-TYPE (version 2)** - Index(es):