[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: #\a octothorpe syntax vs SRFI 10
| Date: Tue, 4 Jan 2005 17:24:38 -0800
| From: "Bradd W. Szonye" <bradd+srfi@xxxxxxxxxx>
| 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.
This confusion makes f,s,d,l a poor choice even though they are short.
| 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.
Those widths were quoted directly from R5RS 6.2.3 Implementation
This report recommends, but does not require, that the IEEE 32-bit
and 64-bit floating point standards be followed by implementations
that use flonum representations, and that implementations using
other representations should match or exceed the precision
achievable using these floating point standards [IEEE].
Since R5RS used widths rather than IEEE terms here, at least we are
clear about the size of these floats.
| 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."
The phrases "single precision" and "double precision" do not appear in
R5RS. The only appearance of "SHORT, SINGLE, DOUBLE, and LONG"
referring to numbers is in 6.2.4 Syntax of numerical constants.
| Note that a system could have a 64-bit "single extended" format,
| which would make the current SRFI 58 names ambiguous.
We already know they are ambiguous. People thought the full names
were too long.
| 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.
Difficult at the moment, since I don't know what their sizes are, or
| 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.
Okay, what's the correspondence?
| 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
(define A:real-64 ar64)
(define A:real-32 ar32)
SRFI-47 should be modified (if that is possible) or replaced after we
are finished with SRFI-58.