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

Re: SRFI-77 with more than one flonum representation

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

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 or
priviledge 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

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 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.)

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

Perhaps, but there also seems to be little cost: simply make the short,
single, double, and long floating-point modules aliases for the default

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.


Dr Alan Watson
Centro de Radioastronomía y Astrofísica
Universidad Astronómico Nacional de México