[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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?
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.
Is it permissible for an exact 3.5 to print (by default) as 7/2 or an
inexact 2 to print as 2.0?
It depends on the format specification. For the explicit ones, there
should be no question. I think, however, that if the format is (HEUR)
it should print as #i2 .
Has anyone implemented the -1+2i or 5@7 syntax for complex numbers?
Is there strong resistance to Common Lisp's #c(-1 2) representation?
CPH has implemented the r^3rs complex notation for MIT Scheme. Having the #c
notation should be optional. I don't think the syntax becomes
ambiguous if it is added, but there is no need for it.
In general, is there anyone strongly opposed to the idea that Scheme
number representations should be made to look more like Common Lisp's?
Not I, as long as it does not run counter to what the report already
- number syntax
- From: David Bartley <bartley%home%ti-csl.csnet@RELAY.CS.NET>