[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
number syntax and exactness
> Let's look through your points one-by-one. [...]
> 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.
I meant that Scheme separated exactness from type in the sense that
"exactness is independent of the position of the number on the tower
[of numeric types]" (6.5.2). Isn't this also what you are saying?
I agree that it certainly is easy to get confused about whether we're
talking about mathematic types, "types" in the language, or
> 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.
Although the notation #e3 means that we are talking about exactly the
abstract number 3, our purpose in using the notation is to communicate
that to a program. Thus, we must consider whether our representation
"types" suffice to do so. Of course this is conflating a property of
the representation with a mathematical property---that's what I/O of
numbers has to deal with.
>From 6.5.2: "Some operations, such as the square root (of non-square
numbers), must be inexact because of the finite precision of our
representations." I'm saying that another such operation is input,
when obeying a precision specification prevents the reader from
correctly representing an exact number. Is this an error, as you
suggest, or no worse than having (SQRT #e3) return an inexact result?
> 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 shouldn't have said that I see "precision" as an ++attribute++ of
"inexactness," as that is an overstatement. I'm trying to say that
fixed precision can impair our ability to represent some exact numbers
correctly. The shortness or longness of a flonum DOES say something
about the likelihood of being able to represent an exact value
(consisting of many digits) correctly, because #e1.5 can probably be
represented exactly as either a short or long flonum, but
#e1.000000000000000000000005 may fit correctly only in a long [I'm
assuming a decimal flonum here]. Thus, #e#s1.000000000000000000000005
involves a contradiction.
Part of my discussion following my point (4) was in error because I
didn't notice this sentence in the last paragraph of 6.5.3: "In either
case, we are specifying an explicit way to represent an inexact
number." This tells me that #e#s123456789 is incorrect because the #S
directly contradicts the #E.
However, I still would like some clarification on whether a number
like #e1.000000000000000000000005 (no #S) is an error or is quietly
represented as an inexact number because READ is sometimes an inexact
I can see that there are enough flaws in my presentation that I need
to start over on it. However, I will be on vacation from this
Saturday until I show up at the Scheme meeting next Saturday, so I'll
just wait and see if there is any interest when I get there.