[r6rs-discuss] flonum operations?

From: William D Clinger <will>
Date: Tue Sep 19 13:41:11 2006

I am posting this as an individual member of the Scheme
community. I am not speaking for the R6RS editors.

Peter Gavin wrote:
> Why doesn't the report include procedures like flonum-mantissa,
> flonum-exponent, flonum-sign, etc. that return the mantissa, exponent,
> and sign, etc.? The implementation should already be able to determine
> the mantissa width (at least for denormalized numbers, see section
> 3.2.7, page 14, second column). These are all pretty trivial
> operations, especially if the implementation's flonums are IEEE
> doubles.

The report does not assume that implementations use
floating point representations, nor does it assume
that those implementations that do use floating point
representations use a binary base.

The report does propose that implementations be required
to support the bytes-ieee-single-set! and bytes-ieee-double-set!
procedures. I think it would be reasonable to add the
following procedures, which could be implemented by
storing the best IEEE floating point approximation to their
argument into a bytes object and extracting the appropriate
bit fields:

 ieee-single-mantissa
 ieee-single-exponent
 ieee-single-sign
 ieee-double-mantissa
 ieee-double-exponent
 ieee-double-sign

Consider, for example, an implementation that represents
inexact reals as floating point numbers with base pi,
with the mantissa represented as an exact ratio whose
denominator is less than or equal to 999999. Although
the native mantissa of 10.0 would be 997/984, and the
native exponent 2, the six procedures listed above would
convert to IEEE single or double and return results that
would be less surprising than 997/984 and 2.

> Also, since it looks like the report leaves room for implementation to
> support inexacts with arbitrary precision, we have a relationship
> between inexacts and flonums that is similar to exact integers and
> fixnums. Since fixnums have operations such as fixnum-width, etc.,
> similar operations for flonums would seem to be appropriate.
>
> In addition, functions like flonum-epsilon, flonum-min-exp,
> flonum-max-exp, etc. would be useful.

These operations would seem to assume a floating point
representation, which the draft does not assume.

Will
Received on Tue Sep 19 2006 - 13:40:11 UTC