[R6RS] Draft of arithmetic SRFI
William D Clinger
will
Mon Aug 1 16:28:54 EDT 2005
Here are my comments and corrections on today's draft.
Will
IMPORTANT!
The notes that I regard as particularly important are flagged
as such. Most of my other notes correct typos or suggest
clarifications to the wording of this SRFI.
IMPORTANT!
By allowing flonums to be a proper subset of the inexact reals,
this SRFI adds "flonum-hood" to Scheme's already rich set of
numeric type distinctions. We need to be upfront about that,
and we need to incorporate discussion of the flonum type into
all of the specifications it affects.
Rationale, last paragraph:
Since "continuity" could be read in the sense of calculus,
"with the advantage of continuity" should be
"with the advantage of historical continuity".
Also, "transparancy" (whatever it might mean :) should be "transparency".
Shouldn't "The section describing exact arithmetic begins with a more
detailed rationale" be "The section describing generic exact arithmetic
begins with a more detailed rationale"?
IMPORTANT!
External Representations:
When I wrote this section originally, I intended for "flonum" to be
synonymous with "inexact real". Now that the SRFI has been rewritten
to drop that assumption, we must add requirements that will ensure
that the flonum subset of the inexact reals is adequate to support
a practical implementation of the full numeric tower. The easiest
way to do that is to require certain of the external representations
for inexact reals to evaluate and/or parse as flonums. I suggest the
following language be added to this section:
Implementations are not required to use floating-point
representations, but every implementation is required to
designate a subset of its inexact reals as flonums, and
to convert certain external representations into flonums.
If a <decimal 10> does not contain a non-empty <mantissa width>
and does not contain one of the exponent markers s, f, d, or l,
but does contain a decimal point or the exponent marker e, then
it is an external representation for a flonum.
Furthermore inf.0, +inf.0, -inf.0, nan.0, +nan.0, and -nan.0 are
external representations for flonums. Some or all of the other
external representations for inexact reals may also represent
flonums, but that is not required by this SRFI.
If a <decimal 10> contains a non-empty <mantissa width> or one
of the exponent markers s, f, d, or l, then it represents an
inexact number, but does not necessarily represent a flonum.
External Representations, fifth bullet:
I'm not so sure about the x|53 interpretation because it discriminates
against implementations that default to unusually good representations,
such as IEEE extended precision. Are there any such implementations?
Do we expect such implementations in the near future?
External Representations, second note:
I don't know what the words "cannot" and "must" mean in this note.
In this SRFI (as opposed to the 2004 paper by Egner et al), the
<mantissa width> is used only for the external representation of
inexact numbers, and the rule for interpreting those external
representations allows implementations to use more or less precision
than is called for by the <mantissa width>. I'd recommend removal
of the second note.
External Representations, context-free grammar:
The grammar for <mantissa width> is wrong: its second production
omits the vertical bar.
Integer Division, specification of div+mod etc:
If "x2 should be non-zero", then why is (div x1 0) specified to
return 0?
"div returns an integer" should be
"div returns an integer; mod returns a real; div+mod returns two
values, an integer and a real".
Integer Division, specification of quotient+remainder etc:
">From this" should be
"From this".
In the Scheme equality following that typo, "(remainder x1 x2)"
should be "(remainder n1 n2)".
In the definition of quotient, there is an extra space in
"(quotient n1 n2)".
Numerical Type Predicates, examples:
The following examples appear twice in the list of examples:
(real? -inf.0) ==> #t
(real? +nan.0) ==> #t
(rational? +nan.0) ==> #f
The following examples both appear, but one should be enough:
(rational? -inf.0) ==> #f
(rational? +inf.0) ==> #f
Throughout this SRFI, some of the examples use ==> while others
use =>. This should be made consistent.
IMPORTANT!
Generic Conversions, specification of number->flonum:
This procedure has terrible closure properties because it is
defined on an extremely narrow subset of the complex numbers.
It should be defined only on reals, and its name should be
changed to real->flonum. To convert a complex number z to a
flonum, programmers should be required to write
(real->flonum (real-part z))
IMPORTANT!
Generic Conversions, rationale and note for number->flonum:
The rationale as written is misleading, because it speaks of the
traditional flonum representation, where flonum has become a type
in this SRFI, and is no longer merely an informal name for a
common representation. Assuming the number->flonum procedure is
renamed to real->flonum, I suggest that the "Rationale:" and
"Note:" be reworded as follows:
Rationale: The flonums are a subset of the inexact reals, but
may be a proper subset. The real->flonum procedure converts
an arbitrary real to the flonum type required by flonum-specific
procedures.
Note: If flonums are represented in binary floating point,
then implementations are strongly encouraged to break ties
by preferring the floating point representation whose least
significant bit is zero.
IMPORTANT!
Numerical input and output:
I think the name of this section should be "Numerical Input and Output".
As was noted in the section on "External Representations", the
number->string procedure should be generalized to support the x|p
notation. Here is one possible generalization, which is biased
toward writing numbers that will be read with the greatest possible
accuracy into some other implementation of known precision.
================
<P>
<DL>
<DT><U>procedure:</U> <CODE>number->string</CODE> <var>z</var>
<DT><U>procedure:</U> <CODE>number->string</CODE> <var>z</var> <var>radix</var>
<DT><U>procedure:</U> <CODE>number->string</CODE> <var>z</var> <var>radix</var> <var>precision</var>
<DD>
<P>
<VAR>Radix</VAR> must be an exact integer, either 2, 8, 10, or 16.
If omitted, <VAR>radix</VAR> defaults to 10.
If a <VAR>precision</VAR> is specified, then it must be an exact
positive integer, and the <VAR>radix</VAR> must be 10.
The procedure <CODE>number->string</CODE> takes a
number and a radix and returns as a string an external representation of
the given number in the given radix such that
<PRE>
(let ((number <VAR>number</VAR>)
(radix <VAR>radix</VAR>))
(eqv? number
(string->number (number->string number
radix)
radix)))
</PRE>
<P>
is true. It is an error if no possible result makes this expression true.
<P>
If a <VAR>precision</VAR> is specified, then the result specifies an
explicit <mantissa width> <VAR>p</VAR>, and <VAR>p</VAR> is the
least <VAR>p</VAR> ≥ <VAR>precision</VAR> for which the above
expression is true. If no <VAR>precision</VAR> is specified, then
the result does not specify an explicit <mantissa width>.
<P>
If <VAR>z</VAR> is inexact, the radix is 10, and the above expression
and condition
can be satisfied by a result that contains a decimal point,
then the result contains a decimal point and is expressed using the
minimum number of digits (exclusive of exponent, trailing
zeroes, and mantissa width) needed to make the above expression and
condition true
[<A HREF="#burger-dybvig-1996">Burger, Dybvig 1996</A>; <A HREF="#clinger-1990">Clinger 1990</A>];
otherwise the format of the result is unspecified.
<P>
The result returned by <CODE>number->string</CODE>
never contains an explicit radix prefix.
================
Specification of fxdiv+mod etc:
"integer division congruent mod hi-lo+1" should be
"integer division modulo hi-lo+1".
Specification of fxgcd and fxlcm:
"congruent mod hi-lo+1" should be
"modulo hi-lo+1".
Specification of fxbitwise-not:
"congruent mod hi-lo+1" should be
"modulo hi-lo+1".
Specification of fxbitwise-and etc:
"congruent mod hi-lo+1" should be
"modulo hi-lo+1", all three times.
Specification of fxarithmetic-shift:
"congruent mod hi-lo+1" should be
"modulo hi-lo+1".
Flonums, definition that opens the section:
This definition is too ambiguous: I had intended for it to mean
that "flonum" is synonymous with "inexact real", and now it is
being used to mean that "flonum" is a (possibly proper) subtype
of "inexact real". I suggest that the definition and the "Please
note" paragraph that follows it be replaced by the following
language, which starts with a paragraph I suggested above for the
section on external representations:
Implementations are not required to use floating-point
representations, but every implementation is required to
designate a subset of its inexact reals as flonums, and
to convert certain external representations into flonums.
IMPORTANT!
IEEE Binary Floating Arithmetic:
The name of this section should be "IEEE Binary Floating Point
Arithmetic".
Following the examples that are "strongly recommended but not
required by the R6RS", we should add:
Furthermore
(numerator? -0.0) => -0.0
is recommended but not required by the R6RS.
IMPORTANT!
Since flonums may be only a proper subset of the inexact reals,
the specification of eqv? must become more complicated. In my
opinion, it deserves its own section in this SRFI. I suggest
the following language:
Equivalence of Objects
The R6RS specification of eqv? for numbers should be changed
as follows.
The `eqv?' procedure returns #t if:
* obj1 and obj2 are both exact numbers, and are numerically
equal (see `=', section see section 6.2 Numbers).
* obj1 and obj2 are both inexact numbers, are numerically
equal (see `=', section see section 6.2 Numbers), and
yield the same results (in the sense of eqv?) when passed
as arguments to any other procedure that can be defined
as a finite composition of Scheme's standard arithmetic
procedures.
The eqv? procedure returns #f if:
* one of obj1 and obj2 is an exact number but the other is
an inexact number.
* one of obj1 and obj2 is a flonum but the other is not.
* obj1 and obj2 are numbers for which the `=' procedure
returns #f.
* obj1 and obj2 yield different results (in the sense of
eqv?) when passed as arguments to any other procedure
that can be defined as a finite composition of Scheme's
standard arithmetic procedures.
Generic Exact Arithmetic, opening paragraphs:
"Each inexact number, except for infinities and NaNs, is taken to
represent a unique exact rational number or exact complex number
with exact rational real and imaginary parts, namely the one
produced by inexact->exact." What about -inf.0+nan.0 ? It is
inexact, is not an infinity, and is not a NaN.
Generic Exact Arithmetic, fifth and seventh paragraphs:
These paragraphs appear to claim that (+ 1e23) will deliver the
same results in all implementations, which isn't true. I think
the SRFI should clarify that "inexact inputs" includes inexact
literals.
Lucier's Proposal:
The paragraph breaks and bullet items got lost in the conversion
to html.
Lucier's Proposal:
We probably ought to go back to Lucier's proposal and check the
branch cuts, which I haven't done. Maybe Mike did.
Closure Properties:
To avoid confusion with algebraic groups, it would be better to
change "group" to "set" throughout these two paragraphs (two
changes).
"(although we must make special cases for (expt 0 0)" is irrelevant,
and should be deleted.
Representation Types, domain equation for integer:
"flonum" should be "(subset of flonum)". This is a nit.
Flow Analysis:
The parenthetical last paragraph should be deleted, because its
content is repeated in the following section.
[end of comments on this draft]
More information about the R6RS
mailing list