[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: number syntax and exactness
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
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.
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
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
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.