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

*To*: bradd+srfi@xxxxxxxxxx*Subject*: Re: #\a octothorpe syntax vs SRFI 10*From*: Aubrey Jaffer <agj@xxxxxxxxxxxx>*Date*: Wed, 5 Jan 2005 00:54:13 -0500 (EST)*Cc*: srfi-58@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-58@xxxxxxxxxxxxxxxxx*In-reply-to*: <20050105012438.GD6573@xxxxxxxxxxxxxxx> (bradd+srfi@xxxxxxxxxx)*References*: <Pine.LNX.4.44.0412262207080.10074-100000@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <20041230222337.3D7BD1B7711@xxxxxxxxxxxxxxxx> <Pine.LNX.4.58.0412301550550.3862@xxxxxxxxxxxxxx> <20050105012438.GD6573@xxxxxxxxxxxxxxx>

| 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 restrictions: 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 their ordering. | 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 | those. (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.

**Follow-Ups**:**Floating-point formats and standards***From:*Bradd W. Szonye

**Re: #\a octothorpe syntax vs SRFI 10***From:*David Van Horn

**Re: #\a octothorpe syntax vs SRFI 10***From:*David Van Horn

**References**:**Re: #\a octothorpe syntax vs SRFI 10***From:*campbell

**Re: #\a octothorpe syntax vs SRFI 10***From:*Aubrey Jaffer

**Re: #\a octothorpe syntax vs SRFI 10***From:*bear

**Re: #\a octothorpe syntax vs SRFI 10***From:*Bradd W. Szonye

- Prev by Date:
**Re: #\a octothorpe syntax vs SRFI 10** - Next by Date:
**Re: #\a octothorpe syntax vs SRFI 10** - Previous by thread:
**Re: #\a octothorpe syntax vs SRFI 10** - Next by thread:
**Floating-point formats and standards** - Index(es):