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

*To*: bartley%home%ti-csl.csnet@RELAY.CS.NET*Subject*: Re: number syntax and exactness*From*: "Gerald Jay Sussman" <GJS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>*Date*: Fri 12 Jun 87 02:45:08-EDT*cc*: RRRS-Authors@MC.LCS.MIT.EDU*In-Reply-To*: <8706052216.AA18999@home>

Let's look through your points one-by-one. B: (1) Complex numbers in Scheme look like 3+4i; in Common Lisp they look like #c(3 4). And I'm persuaded that 3+4i is a worthwhile improvement over #c(3 4). Actually, I am no longer so persuaded myself. The problem is that 3+4i indicates to the reader that we are adding a real 3 to an imaginary 4. Thus it is not obvious why the syntax will not accept 4i, but requires 0+4i. I still like 5@.927 for polar numbers, but I would rather have something like 3&4 for the rectangular variety than 3+4i. On the other hand I think that the #C syntax is quite ugly. I see no reason why we shouldn't accept it, for compatability reasons, in addition to something more pretty. B: (2) The + or - sign in Scheme precedes everything else in a real number; in Common Lisp the sign may be preceded by a radix indicator. Common Lisp does not have the #D (decimal) indicator but has a general purpose #nnR indicator. Allowing the radix indicator and sign to appear in either order seems to be a reasonable extension for both languages. I agree. B: (3) Scheme separates the concept of exactness from type; Common Lisp does not. No... Exactness is intended to be a statement about the mathematical type of a quantity. Scheme tries to separate the mathematical type from the implementation representation. This is not a complete separation, but it is important to make it as separate as possible. B: I don't understand how to make exactness orthogonal to precision, however (see point 4). What does #e#s123456789 mean if an implementation can't represent the value 123456789 exactly in a short FLONUM? Your problem here is that you have conflated the size of the flonum, a property of the representation, not the mathematical type, with a mathematical exactness property. It seems to me that the example you show is just an error -- to be caught by the reader -- as it would complain about #d() or 3.4e5.6. B: (4) Scheme specifies the precision of a real number using #S(short) or #L (long); Common Lisp specifies the precision of a floating point number with an <exponent-marker> of S, F, D, or L (for Short, Single, Double, and Long). The Scheme syntax in 7.1.1 allows a precision specification for rational numbers; Common Lisp does not. I see nothing wrong with the Scheme specification. The Common Lisp one is an extension of an ancient Fortran kludge. I would not be adverse to accepting the Common Lisp syntax for compatability, in addition to our (preferred) syntax. B: In Common Lisp, precision is an attribute of (inexact) FLONUMs only. The last paragraph of 6.5.3 of R3RS says essentially the same thing, clarifying the syntax in 7.1.1. This seems inconsistent to me, though, since it relates "precision" to the FLONUM representation type whereas I see "precision" as an attribute of "inexactness." If we can speak of inexact integers, then we should perhaps be able to speak of short or long ones without requiring that they be implemented as FLONUMs. Again, David, I think that you are confusing representation type with the mathematical status of a quantity. In fact, the shortness or longness of a flonum says nothing about the precision of a numeric quantity so represented. For example, 3.14159232145678 is a rather imprecise value for pi, but it is represented in a medium of potentially large precision. Exactness is intended to be a property of the precision of a quantity, not a property of the potential precision of a representation. I don't think that there is any good reason to mix up such ideas as SHORT, LONG, FLONUM, FIXNUM, etc. with ideas such as INTEGER, REAL, EXACT, INEXACT, RATIONAL. It is to be expected that these ideas are not orthogonal. Surely the mathematical type constrains the applicable representations -- it is hard to argue for stuffing a complex number into a FIXNUM. B: I see two alternatives. We could tie the specification of precision to FLONUMs only, as we do now, or we could relate precision to exactness. I prefer the latter. I do not think that this is a matter of preference... (potential) precision is indeed only a property of the representation -- FLONUMs -- you may extend the idea to FIXNUMs/BIGNUMs, if it appears to be useful, but do not confuse the potential precision of a representation with the actual precision of a particular number. -------

**Follow-Ups**:**number syntax and exactness***From:*David Bartley <bartley%home%ti-csl.csnet@RELAY.CS.NET>

**References**:**number syntax and exactness***From:*David Bartley <bartley%home%ti-csl.csnet@RELAY.CS.NET>

- Prev by Date:
**on-campus accommodations** - Next by Date:
**no free lunch** - Prev by thread:
**number syntax and exactness** - Next by thread:
**number syntax and exactness** - Index(es):