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

Re: #\a octothorpe syntax vs SRFI 10

This page is part of the web mail archives of SRFI 58 from before July 7th, 2015. The new archives for SRFI 58 contain all messages, not just those from before July 7th, 2015.

Aubrey Jaffer wrote:
>> English doesn't much help remember Scheme exponent markers:
>>   The letters `s', `f', `d', and `l' specify the use of SHORT, SINGLE,
>>   DOUBLE, and LONG precision, respectively. [R5RS]
>> I don't usually think of a DOUBLE as shorter than a LONG.  And where
>> did `f' for SINGLE come from?  Maybe it is a C-ism.  In any case, it
>> is one of five characters (with 'e') rather than one of five longer
>> sequences to remember.

bear wrote:
> Actually, scheme exponent markers other than default-precision 'e' are
> 's' 'f' 'd' and 'l', for  'short', 'float', 'double', and 'long',
> which only makes sense if you are a C programmer.

First, some background stuff:

IEEE 754 specifies two basic and two extended floating-point formats. C
specifies three floating-point types, usually mapped to two or three of
the IEEE 754 formats. R5RS specifies four floating-point precisions and
recommends the use of IEEE 754, but its types don't quite match IEEE
754 or C:

    IEEE 754 format     C type          Scheme precision
    single              float           f/single
    single extended     N/A             s/short (?)
    double              double          d/double
    double extended     long double     l/long

The f/single and d/double precisions map neatly to IEEE 754 and C. The
l/long precision maps neatly to C and should usually use the IEEE 754
"double" or "double extended" format. However, it's not clear what to
use for s/short. The R5RS description suggests that "short" is less
precise than "single," but the most obvious translation into IEEE 754
formats suggests just the opposite.

Next, some issues for SRFI 58:

The current names for flonum arrays are "real-64" and "real-32,"
corresponding to "IEEE 64.bit floating point real" and "IEEE 32.bit
floating point real." There are a few problems with this.

First, the SRFI should cite IEEE 754 specifically, since the IEEE has
standardized more than one system of floating-point formats. The correct
full name of the standard is "ANSI/IEEE Std 754–1985, IEEE Standard for
Binary Floating-Point Arithmetic."

Second, the format names are properly "single" and "double," not
"32.bit" and "64.bit." Note that a system could have a 64-bit "single
extended" format, which would make the current SRFI 58 names ambiguous.

Third, both IEEE 754 and R5RS Scheme specify four floating-point
formats, but SRFI 58 currently supports only two. It should probably
support the other two types.

Fourth, if the SRFI requires IEEE 754 representations, it should also
mandate a particular correspondence between IEEE 754 formats and Scheme
precisions (e.g., f=single, s=single extended, etc). Otherwise, users
won't be able to match literal reals to array types reliably.

Finally, the array element prefix should match IEEE 754 (single,
double), Scheme (f/single, d/double), or SRFI 47 (ar32, ar64). The
current "real-32" and "real-64" prefixes don't quite match any of those.
Bradd W. Szonye