Re: number syntax

[willc%tekchips.tek.com@RELAY.CS.NET]

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