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.
Thank you for your reply.In what follows, I will use "floating-point representation" to refer to the low-level representation used internally for certain inexact numbers and "flonum" to mean the subset of inexacts supported by the flonum-specific parts of SRFI 77.
William D Clinger wrote:
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 agree that most implementations will continue to use a single floating-point representation and so will have no problems implementing SRFI 77.
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.
If an implementation uses more than one floating point representation, when implementing SRFI 77, the implementor must choose between defining flonum to refer to only one representation (and thus prejudicing the others) or to all representations (and thus being less efficient). Thus, if you have more than one representation, it is difficult to obtain efficiency without prejudicing certain representations. The only motivation for the flonum-specific part of SRFI 77 seems to be efficiency. Thus, in implementations that have more than one floating-point representation, one either has to sacrifice efficiency orpriviledge one representation. Thus, the motivation of SRFI 77 would in this case encourage an implementor to bestow priviledged status on a particular representation.
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."
I know, but I do not regard this as an especially important form of prejudice. When you use "e", you mean "d" or "l" and you don't care which. (And I think I can guess the historical basis for this.)
One solution that would avoid giving priviledged status to one ofthe 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.)
Forgive me if I put words into your mouth, but you seem to be saying that existing implementations use only one floating-point representation, therefore it is okay to standardize interfaces that are well-adapted to such implementations but ill-adapted to implementations that might use more than one floating-point representation.
This seems to be an argument for eliminating s, f, d, l, and forcing all future Schemes to use only one floating-point representation. Furthermore, it also seems to be an argument for forcing all future Schemes to use only floating-point representations for inexacts.
There is little to be gained by requiring implementations to provide modules for every precision when most systems provide only one precision.
Perhaps, but there also seems to be little cost: simply make the short, single, double, and long floating-point modules aliases for the default module.
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.
If you are going to promote interfaces on the basis of efficiency (and there seems to be no other justification for the flonum-specific part of SRFI 77), you should expect people to use the same arguments against you.
Regards, Alan -- Dr Alan Watson Centro de Radioastronomía y Astrofísica Universidad Astronómico Nacional de México