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

*To*: GJS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU*Subject*: number syntax and exactness*From*: David Bartley <bartley%home%ti-csl.csnet@RELAY.CS.NET>*Date*: Thu, 18 Jun 87 18:59:25 cdt*Cc*: bartley%home%ti-csl.csnet@RELAY.CS.NET, RRRS-Authors@mc.lcs.mit.edu*In-Reply-To*: Gerald Jay Sussman's message of Fri 12 Jun 87 02:45:08-EDT <12309831704.6.GJS@OZ.AI.MIT.EDU>

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

**References**:**Re: number syntax and exactness***From:*"Gerald Jay Sussman" <GJS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>

- Prev by Date:
**Session chair** - Next by Date:
**sundry** - Prev by thread:
**Re: number syntax and exactness** - Next by thread:
**Better late than never** - Index(es):