Re: SRFI-77 with more than one flonum representation
Michael Sperber 05 Jul 2006 18:26 UTC
I have been thinking about how to implement single-precision and
double-precision versions of the SRFI 77 flonum-specific procedures as
implementation-defined extensions. I am particularly interested in
seeing whether there might be conflicts with the existing SRFI 77.
An illustrative case is implementing single-precision arithmetic in an
implementation that uses double-precision for all inexact reals. One
approach is the following:
(a) The reader, read, and string->number read an f-exponent literal as a
single-precision, and then represent the result as a double-precision.
(b) The single-precision real->flonum converts its double-precision
argument to single-precision, and then represent the result as a
double-precision.
(c) The other single-precision flonum procedures convert their
double-precision arguments to single-precision, perform the
single-precision operation, and then then represent the result as a
double-precision.
(d) When called in a "single-precision context", number->string,
display, and write generate f-exponent literals when their argument is
an inexact real.
The only problem seems to be determining the context the conversion
routines, but it might be possible to use the module system to supply this.
Now, provided the only arguments to the flonum procedures are f-exponent
literals, the results of real->flonum, or the result of other flonum
procedures, this implementation behaves as if there were a
single-precision representation. However, no explicit single-precision
internal representation is needed.
This would not be any faster than calculating everything in double
precision, but I doubt would not be significantly slower. The main idea
is to control precision.
One can do the same sort of thing for an explicit double-precision
version of SRFI 77. And one can see the obvious extension to
implementations that really do have different precision representations,
which might be faster because they might not need to box values.
Can anyone see any way in which this clashes with the existing SRFI 77?
Regards,
Alan