Re: SRFI-77 with more than one flonum representation William D Clinger (26 Jun 2006 23:31 UTC)
|
Re: SRFI-77 with more than one flonum representation
Alan Watson
(29 Jun 2006 16:13 UTC)
|
Re: SRFI-77 with more than one flonum representation
John Cowan
(30 Jun 2006 15:03 UTC)
|
Re: SRFI-77 with more than one flonum representation
Alan Watson
(03 Jul 2006 16:16 UTC)
|
Re: SRFI-77 with more than one flonum representation
Michael Sperber
(05 Jul 2006 18:26 UTC)
|
Re: SRFI-77 with more than one flonum representation
Michael Sperber
(05 Jul 2006 18:28 UTC)
|
Re: SRFI-77 with more than one flonum representation
Alan Watson
(03 Jul 2006 16:17 UTC)
|
John Cowan wrote: > I read SRFI 77 as saying that a conforming Scheme system can have > more than one representation of inexact reals, but that one of these > must be labeled "flonums" for the purposes of the standard, and > the others are something else. SRFI 77 was intended to allow that kind of implementation. I believe SRFI 77 also allows an implementation to have flonums of various precisions, but I doubt whether many implementations will do this because it would introduce a case dispatch into the flonum-specific operations. It appears, however, that the R6RS library system will make it easier for optimizing compilers to infer the representations of arguments to standard procedures, which would make it more practical to have flonums of various precisions. Referring to John Cowan's interpretation, Alan Watson wrote: > Yes, that is a possible solution, but does anyone think it is a > satisfactory one? I do. I expect most implementations will designate their preferred or default precision of inexact reals as their set of flonums. > I don't like giving one representation > priviledged status and I especially do not like having a number > that is represented as a flonum (in the general sense of the > word) but which is not a flonum (in this restricted sense of the > word). SRFI 77 does not insist upon giving privileged status to any particular representation of inexact reals, but it does allow implementations to bestow privileged status upon a particular precision. You may not have realized it, but R5RS 6.2.4 had already given privileged status to some precision by saying "the exponent marker `e' specifies the default precision for the implementation. The default precision has at least as much precision as double, but implementations may wish to allow this default to be set by the user." SRFI 77 does not supersede that part of the R5RS, and the easiest way to implement SRFI 77 is to take flonums to be the inexact reals that are represented in the default precision. Implementations are free to implement SRFI 77 by taking flonums as the entire set of inexact reals, but that leads to a more complex implementation. > One solution that would avoid giving priviledged status to one > of the flonum representations would be to mandate modules for > short[*], single, double, and extended flonums. [...] Yes, but we should first take a look at current practice. A quick check of the eight implementations of Scheme that are installed on my primary machine shows that all eight implement just one precision of inexact real, and three of them are not even R5RS-conformant. (Contrary to R5RS 6.2.4, they fail to recognize the `s', `f', `d', and `l' exponents and to map those precisions onto the available precisions.) There is little to be gained by requiring implementations to provide modules for every precision when most systems provide only one precision. The fact that several popular implementations continue to ignore the relatively modest requirements of the R5RS also illustrates the difficulty of persuading implementors to provide even basic features of the standard to which some of them claim to conform. > One of the arguments for the flonum-specific procedures is > efficiency. real->flonum is generic, and undersome circumstances > will not be as efficient as as hypothetical > double-precision-flonum->single-precision-flonum procedure. Before we mandate some procedure on grounds of efficiency, we should measure the efficiency to be gained in some real implementation. At the moment, I am having trouble finding a system that supports more than one precision, so it seems to me that the efficiency to be gained by requiring this hypothetical procedure is hypothetical, especially when compared to the efficiency lost by diverting implementors' limited time from things that matter more. Will