Formal comment #40 (defect)

Exactness is orthogonal to type
Reported by:	Aubrey Jaffer

Component:	arithmetic
Version:	5.91

Page 2: 2.1. Numerical Types

    In order to catch uses of inexact numbers where exact numbers are
    required, Scheme explicitly distinguishes exact from inexact
    numbers.  This distinction is orthogonal to the dimension of type.

To my ear this says that each numerical type must be present in both
exact and inexact varieties.  If that is the case, then the functions
of sections "16.5. Exact arithmetic" and "16.6. Inexact arithmetic"
are largely pointless; numeric code must dispatch to any of the
numeric types whether restricted to exacts or inexacts.

I propose that either

 * "This distinction is orthogonal to the dimension of type."  be
   removed or modified; or

 * Sections "16.5. Exact arithmetic" and "16.6. Inexact arithmetic"
   be removed.

RESPONSE:

With the draft R6RS, it is true "that each numerical type
must be present in both exact and inexact varieties."
Integers may be exact or inexact; rationals may be exact
or inexact; reals may be exact or inexact; complex numbers
may be exact or inexact.

From this fact, formal comment #40 somehow concludes that the
(r6rs arithmetic exact) and (r6rs arithmetic inexact)
libraries are largely pointless.

The basis for that suggestion is unclear, but it may be
based upon an assumption that the primary motivation for
the (r6rs arithmetic exact) and (r6rs arithmetic inexact)
libraries is efficiency.  Even if that were so, the
(r6rs arithmetic exact) library would not be entirely
pointless, since it defines bitwise operations whose
efficient operation would depend upon access to the
underlying representation of large integers.

In reality, efficiency has never been a motivation for
including those two libraries within the R6RS.

It has been observed that most calls to Scheme's arithmetic
procedures pass arguments that are either all exact or all
inexact; the (r6rs arithmetic exact) and (r6rs arithmetic
inexact) libraries provide programmers with a convenient
way to assert that this is deliberate, with the safety that
may result from raising an exception if the assertion does
not hold.

As specified in the draft R6RS, however, the (r6rs arithmetic
inexact) library is not consistent with the generic operations
restricted to inexact arguments because some procedures return
an inexact real result (typically a NaN) when the corresponding
generic operation would return a more useful inexact complex
result.

Neither library has been tested in the field.  Except
for the bit-diddling operations on exact integers, both
libraries could be described by a SRFI and provided by
portable reference implementations that would be just as
efficient as if the libraries were part of the R6RS.

The editors have decided to remove both libraries from
the report, along with the (r6rs arithmetic fixnum)
library.  The following procedures will be renamed by
changing the "exact-" prefix to "bitwise-", and will be
placed within a new (r6rs arithmetic bitwise) library:

    exact-not
    exact-and
    exact-ior
    exact-xor
    exact-if
    exact-bit-count
    exact-length
    exact-first-bit-set
    exact-bit-set?
    exact-copy-bit
    exact-bit-field
    exact-copy-bit-field
    exact-arithmetic-shift
    exact-arithmetic-shift-left
    exact-arithmetic-shift-right
    exact-rotate-bit-field
    exact-reverse-bit-field

The exact-sqrt procedures will be renamed exact-integer-sqrt and moved
to the (r6rs base) library.