number syntax and exactness

[David Bartley <bartley%home%ti-csl.csnet@RELAY.CS.NET>]

> 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
representational "types."

> 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
>     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 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
operation.

----------

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.  

--db--