This page is part of the web mail archives of SRFI 77 from before July 7th, 2015. The new archives for SRFI 77 contain all messages, not just those from before July 7th, 2015.
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