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

*To*: rrrs-authors@MC.LCS.MIT.EDU*Subject*: Re: number syntax*From*: willc%tekchips.tek.com@RELAY.CS.NET*Date*: 10 Apr 87 16:18:11 PDT (Fri)*Cc*: bartley%home%ti-csl.csnet@RELAY.CS.NET, willc%tekchips.tek.com@RELAY.CS.NET, jinx%geneva.ai.mit.edu@RELAY.CS.NET*In-Reply-To*: Your message of Thu, 9 Apr 87 19:11:01 est. <8704100011.AA22486@geneva>

Bartley: Has anyone implemented exactness using a mechanism substantially different from the one Kent Dybvig describes in his new book? (Quoting his page 111: "In practice, the internal representation for an exact quantity is as an integer or ratio, and the internal representation for an inexact quantity is as a floating point number, although other representations are possible." Also, "The exactness of a complex numeric object depends on the exactness of its real and imaginary parts.") How do people feel about this approach? Does this fulfill the spirit of exactness? Does anyone want to pay for a more orthogonal exactness attribute for numbers? The passage quoted says "integer" and "ratio" and "floating point number" when the proper R3RS terminology is "fixnum or bignum" and "ratnum" and "flonum". I feel like I'm being overly picky by pointing this out, since all of these terms (except integer) are implementation-dependent and the book describes only Chez Scheme, but Jinx's response shows why precision is important in words as well as numbers. Jinx: That is very much against the proposal. We have not implemented it at MIT, but the original proposal is such that both exact and inexact flonums are possible (and desirable), and similarly for the other types. Although we have not implemented it, we have an implementation in mind, and it is orthogonal: for each type of number, there is a bit specifying whether it is exact or not. I have to disagree with Jinx's first two sentences above. R3RS makes clear that exact reals and inexact integers are both possible and desirable, but it says nothing at all about exact flonums and inexact fixnums. Though their semantics are poorly defined in R3RS, "exact" and "inexact" are intended to be significant concepts in the language. By contrast, "flonum" and "fixnum" are names for internal representation strategies that have no standing in the language. Thus "exact flonum" is at best an implementation concept, and at worst a category error. Suppose I implement Scheme (without complex numbers, to keep things simpler) by representing all numbers as ratnums, augmented by a bit that tells whether the number is exact or inexact. This is perfectly legitimate, right? Now suppose people complain about its performance on certain numerical programs, and my investigations show that the reason for the poor performance is that it takes too long to add and to multiply inexact reals. Suppose I tweak my implementation by arranging for inexact reals to be represented as flonums, augmented by a bit that tells whether the number is exact or inexact. That's a perfectly legitimate efficiency hack, right? Suppose I then notice that the exactness bit for a real represented as a flonum always says that the real is inexact, because I'm still representing exact reals as ratnums. So I flush the exactness bit for reals represented as flonums, because the fact that the real is represented as a flonum implies that it's inexact. I would be silly not to, right? If I then add two more efficiency hacks by representing exact integers as bignums, and by representing small exact integers as fixnums, I arrive at an implementation similar to that hinted at by Dybvig's book. Not only do I see nothing wrong with this, it seems the obvious way to go. In terms of Jinx's remarks, you can be orthogonal at the language level without being orthogonal at the implementation level. I would oppose any attempt to mandate particular implementation strategies. Cadence Research and TI and Tektronix have no more right to impose their favorite implementation strategy on MIT than MIT has to impose its favorite strategy on us. Bartley: Is it permissible for an exact 3.5 to print (by default) as 7/2 or an inexact 2 to print as 2.0? Fine with me. I'm more concerned about whether "7/2" reads as an exact 3.5 and whether "2.0" reads as an inexact 2. The examples in section 6.8 of R3RS are sufficient to imply that "1" and "5" read as exact integers, assuming that the same reader is used to read both programs and data. Peace, Will

**Follow-Ups**:**Re: number syntax***From:*Warren Harris <harris%hplwhh@hplabs.HP.COM>

**References**:**number syntax***From:*jinx@GENEVA.AI.MIT.EDU (Guillermo J. Rozas)

- Prev by Date:
**number syntax** - Next by Date:
**towards an agenda - yeller pages** - Prev by thread:
**number syntax** - Next by thread:
**Re: number syntax** - Index(es):