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

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.

*To*: bradd+srfi@xxxxxxxxxx*Subject*: Re: Floating-point formats and standards*From*: Aubrey Jaffer <agj@xxxxxxxxxxxx>*Date*: Wed, 5 Jan 2005 12:03:42 -0500 (EST)*Cc*: srfi-58@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-58@xxxxxxxxxxxxxxxxx*In-reply-to*: <20050105122227.GC9007@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> <20050105055413.5FA901B7717@xxxxxxxxxxxxxxxx> <20050105114809.GB9007@xxxxxxxxxxxxxxx> <20050105122227.GC9007@xxxxxxxxxxxxxxx>

| Date: Wed, 5 Jan 2005 04:22:27 -0800 | From: "Bradd W. Szonye" <bradd+srfi@xxxxxxxxxx> | | A couple of corrections to the 754R description: | | Bradd W. Szonye wrote: | > New name Sig Exp Old name Currently implemented by | > | > binary16 11 5 | > binary32 23 8 single all systems (hardware) | > binary64 52 11 double all systems (hardware) | > binary80 64 15 extended all x86-based systems (hardware) | > binary128 112 15 quad most RISC systems (software) | | In the current draft, the extended format is called "binaryx" | instead of "binary80." Implementations are supposed to provide at | least one high- precision format for intermediate calculations, | either binary128 (a basic format) or binaryx (an | implementation-defined format about 50% more precise than its best | basic format). Can these intermediate formats be stored in memory? Can vectored instructions read and store the intermediate formats? | One proposal recommends specifying binaryx as the x86 extended | format. I have no way of knowing for certain, but I suspect that it | will succeed, since x86 and quad are the only /de facto/ standards | for high-precision IEEE 754 flonums. | | That proposal also states which formats a system should support. | | For high-performance technical systems: | | Binary64 is mandatory for computation and storage. | Binary32 is recommended for low-precision, high-density storage. | Binaryx is recommended for computation on x86-compatible systems. | Binary128 is recommended for expression evaluation (i.e., temps). | | For commercial and financial systems: | | Decimal128 is mandatory for computation and storage. | Decimal32 and decimal64 are recommended for storage. | | The binary requirements match reality pretty well, except for the | binary128 recommendation. (Currently, only x86 systems use high- | precision temps, and they use binaryx instead of binary128.) Since these proposed names have sizes in bits, I see little cause to replace those sizes with the longer names or the cryptic abbreviations. While reading through 6.2 Numbers: Machine representations such as fixed point and floating point are referred to by names such as fixnum and flonum. So here is a possible naming based on that. Since flonum and fixnum are machine representations, they specify attributes other than the numerical type. With this encoding rational fixnums could be added (a la PL/1). These abbreviations are pronounceable. The fourth letter of the type name is C for complex, R for real, (Q for rational?,) I for integer, and N for nonnegative integer or natural number. The "-" between the type name and precision could be removed. Are fixnums and flonums necessarily binary? Adding in a radix indicator would gum up the works. -=-=-=-=- prototype exact- prefix procedure ness element type (rank = n) ========= ===== ============ ========== vector any #nA A:floc-64 inexact IEEE 64.bit binary flonum complex #nA:floc-64 A:floc-32 inexact IEEE 32.bit binary flonum complex #nA:floc-32 A:flor-64 inexact IEEE 64.bit binary flonum real #nA:flor-64 A:flor-32 inexact IEEE 32.bit binary flonum real #nA:flor-32 A:fixi-64 exact 64.bit binary fixnum #nA:fixi-64 A:fixi-32 exact 32.bit binary fixnum #nA:fixi-32 A:fixi-16 exact 16.bit binary fixnum #nA:fixi-16 A:fixi-8 exact 8.bit binary fixnum #nA:fixi-8 A:fixn-64 exact 64.bit nonnegative binary fixnum #nA:fixn-64 A:fixn-32 exact 32.bit nonnegative binary fixnum #nA:fixn-32 A:fixn-16 exact 16.bit nonnegative binary fixnum #nA:fixn-16 A:fixn-8 exact 8.bit nonnegative binary fixnum #nA:fixn-8 A:boolean boolean #nA:boolean A two-by-three array of nonnegative 16.bit integers is written: #2A:fixn-16((0 1 2) (3 5 4)) Note that this is the external representation of an array, not an expression evaluating to a array. Like vector constants, array constants must be quoted: '#2a:FIXN-16((0 1 2) (3 5 4)) ==> #2A:fixn-16((0 1 2) (3 5 4)) Rank 0 arrays: #0a sym #0A:flor-32 237.0 Semantics (array-dimensions '#2A:fixn-16((0 1 2) (3 5 4))) ==> (2 3) An equivalent array could have been created by (define ra (make-array (A:fixn-16) 2 3)) (array-set! ra 0 0 0) (array-set! ra 1 0 1) (array-set! ra 2 0 2) (array-set! ra 3 1 0) (array-set! ra 5 1 1) (array-set! ra 4 1 2) Literal array constants are immutable objects. It is an error to attempt to store a new value into a location that is denoted by an immutable object. The following equivalences will be defined to alias SRFI-47 names to the new ones. SRFI-47 should be amended or replaced to make these be the array-prototype-procedures: (define A:floc-64 ac64) (define A:floc-32 ac32) (define A:flor-64 ar64) (define A:flor-32 ar32) (define A:fixi-64 as64) (define A:fixi-32 as32) (define A:fixi-16 as16) (define A:fixi-8 as8) (define A:fixn-64 au64) (define A:fixn-32 au32) (define A:fixn-16 au16) (define A:fixn-8 au8) (define A:boolean at1)

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

**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

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

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

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

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