numbers

[willc%tekchips.tek.csnet@CSNET-RELAY.ARPA]

Abstract:  Scheme numbers are still inadequately specified in several
respects.  I propose several improvements.  Some are minor enough to
deserve incorporation in the SIGPLAN Notices publication of the Revised^3
Report, but the others probably deserve more debate.

Some problems that I perceive with Scheme numbers are:

1.  The quotient procedure is not adequately specified.
2.  The floor etc procedures are not adequately specified.
3.  The syntax for numbers has a redundancy.
4.  The integer? procedure may not be adequately specified.
5.  Valid indexes may not be adequately specified.
6.  The read and string->number procedures are not adequately specified.

(David Bartley has also suggested that the syntax should be made more
compatible with Common Lisp and has proposed that the report be clearer
on which parts of the number syntax are essential and which are not
essential.)

1.  Norman Adams pointed out to me that it is unclear from the description
of quotient in 6.5.4 whether (quotient -13 4) should be -3 or -4; likewise
(quotient 13 -4).  I propose that the sentence beginning "For positive
integers n1 and n2" be followed by the sentence

    For all integers n1 and n2 with n2 not equal to 0,

      (= n1 (+ (* n2 (quotient n1 n2)) (remainder n1 n2)))   ==> #t

2.  In the description of floor, ceiling, truncate, round, and rationalize,
the sentence "Their results are not exact---in fact, their results are
clearly inexact, though they can be made exact with an explicit exactness
coercion" is incorrect.  I propose that the sentence be replaced by "Their
results are exact if and only if their arguments are exact."

3.  The third production for <ureal R> is redundant.

4.  In MacScheme and a few other implementations, (integer? 4.0) evaluates
to #f.  Even assuming that 4.0 is inexact, this seems wrong.  I would like
to see an example in the report to show that it's wrong.

5.  I believe the index or size arguments to list-tail, list-ref,
make-string, string-ref, string-set!, substring-fill!, make-vector,
vector-ref, and vector-set! should be required to be exact integers
instead of just integers.

6.  It isn't clear from the report whether 3.0 reads as an exact or inexact
number.  Indeed the same can be said of 3, or 3/1, or 3###-4###i.  I propose
that this sort of thing be specified more formally, as in the following
example---which does not match up very well with the syntax and is not my
favorite proposal anyway.

    exactness [ <real> + <ureal> i ] = exactness [ <real> - <ureal> i ]
        = minexact (exactness [ <real> ], exactness [ ureal ])
    exactness [ <real_1> @ <real_2> ]
        = minexact (exactness [ <real_1> ], exactness [ <real_2> ]
    exactness [ <sign> <ureal> ] = exactness [ <ureal> ]
    exactness [ <prefix> <x> <suffix> ]
        = if explicit [ <prefix> ]
            then prexact [ <prefix> ]
            else if empty [ <suffix> ]
                    then exactness [ <x> ]
                    else #f                     ; this is what I don't like
    exactness [ <uinteger> <suffix> ]
        = if empty [ <suffix> ] then exactness [ <uinteger> ] else #f
    exactness [ <digit>+ #+ ] = #f
    exactness [ <digit>+ ] = #t
    exactness [ <uinteger_1> / <uinteger_2> ]
        = minexact (exactness [ <uinteger_1> ], exactness [ <uinteger_2> ])
    exactness [ <digit>+ #+ ] = #f
    exactness [ <digit>+ ] = #t
    exactness [ <digit>* . <digit>+ #* ] = #f
    exactness [ <digit>* . #+ ] = #f
    exactness [ <digit>+ . ] = #t
    exactness [ <digit>+ #+ . ] = #f

    minexact (b1, b2) = if b1 then b2 else #f

    explicit [ ... #i ... ] = explicit [ ... #e ... ] = #t
    explicit [ ... <empty exactness> ... ] = #f

    prexact [ ... <exactness> ... ] = prexact [ <exactness> ]
    prexact [ #i ] = #f
    prexact [ #e ] = #t


Peace, Will