Re: SRFI-77 with more than one flonum representation

[William D Clinger <will@xxxxxxxxxxx>]

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