[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: srfi-77@xxxxxxxxxxxxxxxxx*Subject*: Re: SRFI-77 with more than one flonum representation*From*: Michael Sperber <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx>*Date*: Wed, 05 Jul 2006 20:26:45 +0200*Delivered-to*: srfi-77@xxxxxxxxxxxxxxxxx*In-reply-to*: <44A7455F.10205@xxxxxxxxxxxxxxxx>*References*: <E1Fv0YU-0000mn-OV@xxxxxxxxxxxxxxxxx> <44A33752.9000906@xxxxxxxxxxxxxxxx> <20060630150334.GC31002@xxxxxxxx> <44A7455F.10205@xxxxxxxxxxxxxxxx>*User-agent*: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.5-b26 (darwin)

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

**Follow-Ups**:**Re: SRFI-77 with more than one flonum representation***From:*Michael Sperber

**References**:**Re: SRFI-77 with more than one flonum representation***From:*William D Clinger

**Re: SRFI-77 with more than one flonum representation***From:*Alan Watson

**Re: SRFI-77 with more than one flonum representation***From:*John Cowan

**Re: SRFI-77 with more than one flonum representation***From:*Alan Watson

- Prev by Date:
**number->string should use either no exponent or an e-exponent** - Next by Date:
**Re: SRFI-77 with more than one flonum representation** - Previous by thread:
**Re: SRFI-77 with more than one flonum representation** - Next by thread:
**Re: SRFI-77 with more than one flonum representation** - Index(es):