Re: RfD: IEEE-FP

Okay, the new draft is copied below.

Please note the qualification in the introduction that it does
not intend to cover full IEEE 754-2008. Several sections are
marked as UNDER CONSTRUCTION, and several places where a
separate RfD may be in order are noted.

Even without separate RfD's, it seems the discussion would
benefit from separate threads on some of the topics, like
Anton's "State in reusable code".

I'm not suggesting that the current direction of the discussion
be diverted.

-- David



PROPOSAL FOR AN OPTIONAL IEEE 754, BINARY
FLOATING-POINT WORD SET

version 0.5.1
dnw 7-Jun-09

TABLE of CONTENTS

1 INTRODUCTION
2 TERMINOLOGY AND NOTATION
3 IMPLEMENTATION
4 DATA TYPES
5 ENVIRONMENTAL QUERIES
6 TEXT INPUT
6.1 Decimal input
6.2 Hexadecimal input
7 GLOSSARY
7.1 Conversion
7.2 Output
7.3 Comparison
7.4 Classification
7.5 Arithmetic
7.6 Math functions
7.7 Sign bit operations
7.8 Nearest integer functions
7.9 Number manipulation
7.10 Exceptions
7.11 Rounding modes
8 REFERENCES AND FOOTNOTES


1 INTRODUCTION

This is a proposal for an optional Forth 200x word set that
supports the binary part of the IEEE 754-2008 standard for
floating-point arithmetic [1]. The most recent, freely
available, but less comprehensive version is IEEE 754 draft
1.2.9, January 27, 2007 [2]. There is also a Wikipedia summary
[3].

This specification requires that ISO Forth [5,6] floating-point
and floating-point extension words in the optional
Floating-Point word set, when present, satisfy additional IEEE
754-2008 requirements. Words in that word set and this that
correspond to operations or functions in IEEE 754-2008 adopt the
behavior required or recommended there by reference, as far as
that is possible and makes sense, unless otherwise stated.

The specification is compatible with, rather than conformant to,
IEEE 754-2008, because not all IEEE requirements are to be
implemented, and some are qualified here by "should" rather than
an IEEE "shall".

The current C99 standard [4-7] has a comprehensive treatment of
IEEE 754-1985, which offers a route to implementation, for those
Forth systems that can call C libraries.

[**Bracketed statements like this are for editorial questions
and comments, eventually to be removed.]


2 TERMINOLOGY AND NOTATION

"IEEE 754" or "IEEE": IEE 754-2008. Section numbers in the
standard [1] are indicated by IEEE <section number>.

"C99": ISO/IEC 9899:1999 C [4].

"DPANS94": American National Standard for Forth, ANSI
X3.215-1994, final draft [8]. The final draft is believed to
be the same as the published version, which is now ISO/IEC
15145:1997 [9]. This document adopts the official terminology
of DPANS94 unless otherwise stated. Section numbers in that
document are indicated by DPANS94 <section number>.

"fp" or "bfp": Short for "binary floating point". The Forth
floating-point stack is called the "fp stack".

"special number": Signed zero, a quiet or signaling signed nan,
or signed infinity.

"full set of numbers": For an IEEE binary format, the set of
normal, subnormal, and special numbers that it represents.

"IEEE number": Any member of a full set of numbers.

"IEEE arithmetic": Arithmetic defined by IEEE 754-2008 for IEEE
numbers.

"nan load" or "nan payload": The value of the fractional bits
in the binary format of a nan, excluding the quiet bit,
considered as a positive integer. The smallest signaling load
is unity, and the smallest quiet load is zero.

"qnan", resp., "snan": Any quiet or signaling nan,
respectively, of any sign or load.

"single": In the context of Forth fp, the IEEE 754-2008 32-bit
interchange format.

"double": In the context of Forth fp, the IEEE 754-2008 64-bit
interchange format.

"default": In the context of Forth fp, the default, DPANS94
float format for numbers that can appear on the fp stack.

"exception": Used in the IEEE sense, rather than the throw
sense. [**Anton suggests a new terminology is needed for
this.]

[**Other terminology defined by IEEE probably has been used in
the document that needs to be spelled out.]

Each IEEE bfp format has two fixed parameters, p > 0 (precision)
and emax > 0 (maximum exponent), and defines emin = 1 - emax
(minimum exponent). Each such format represents all real
numbers of the form

r = (-1)^s * 2^e * b_0.b_1 ... b_{p-1}

where

s = 0 or 1, emin <= e <= emax,
b_i = 0 or 1, p = #significand bits.

IEEE 754-2008 defines three basic binary fp formats, binary32,
binary64, and binary128, plus three corresponding extended
binary formats, whose parameters are shown in Tables 1 and 2
below. It also defines four binary interchange formats, of
which only three are shown in Table 3 (IEEE binary16 is
omitted).


Table 1: Parameters for IEEE 754-2008
basic binary formats.

binary32 binary64 binary128
---------------------------------------
p = 24 53 113
emax = 127 1023 16383


Table 2: Parameters for IEEE 754-2008
extended binary formats.

binary32 binary64 binary128
---------------------------------------
p >= 32 64 128
emax >= 1023 16383 65535


Table 3: Parameters for IEEE 754-2008
binary interchange formats
(k is the storage width in
bits).

binary32 binary64 binary128
---------------------------------------
k = 32 64 128
p = 24 53 113
emax = 127 1023 16383


Note that the intel 80-bit format corresponds to binary64
extended, with p = 64 and emax = 16383. Its precision is
greater than that of basic binary64 and less than that of basic
binary128, with exponent range the same as basic binary128.
Although it is not defined as a basic IEEE binary format, we
call this the "binary80" basic format.

Note that the binary128 interchange format is the only one in
Table 3 that can contain the binary80 basic format.


3 IMPLEMENTATION

According to DPANS94, Section 3, "Usage requirements":

A system shall provide all of the words defined in 6.1 Core
Words. It may also provide any words defined in the optional
word sets and extension word sets.

The DPANS94 Floating-Point word set is an optional word set,
and so is the word set described by this document.

The word "shall" in the remainder of this document states a
requirement when the environmental query for IEEE-FP returns
true. "Should" means "strongly recommended".

The internal fp representation of default fp numbers, i.e.,
numbers that can appear on the fp stack, shall correspond to one
of the IEEE basic, or extended, full binary formats.


4 DATA TYPES

The DPANS94 r type is extended to include the special numbers.


5 ENVIRONMENTAL QUERIES

[**UNDER CONSTRUCTION]

A true result for the IEEE-FP environmental query shall mean
that at least the DPANS94 floating-point words are present, and
that all new [**required] words in this document are present.
Those and any DPANS94 floating-point words that are present,
shall obey the specifications of this document.

Value
String Data Type Constant? Meaning
----------------------------------------------------------------
IEEE-FP n no binary float format:
n=0, extended and not listed below
n=32, binary32
n=64, binary64
n=80, binary80
n=128, binary128
----------------------------------------------------------------

[**Case n=0 seems unlikely. Better way to handle it? How can a
portable application know its parameters when n=0?]


6 TEXT INPUT

6.1 Decimal input
-----------------

IEEE requires that conversion between text and binary fp formats
shall include signed zero, signed infinity, and signed nans,
with and without loads. See IEEE 5.4.2, "Conversion operations
for floating-point formats and decimal character sequences", and
IEEE 5.12, "Details of conversion between floating-point data
and external character sequences".

The syntax specification in DPANS94 12.3.7, "Text input
number conversion", shall be replaced by

Convertible string := { <significand><exponent> | <special> }
[**Separate RfD to allow
[<sign>]<digits0>.<digits> as well.]

<significand> := [<sign>]{ <digits>[.<digits0>] | .<digits> }
[**Note the extra .<digits> option.]
<exponent> := { <e-char>[<sign>]<digits>|<e-char> }
[**Note that a sign with no digits is not allowed.]
<digits> := <digit><digits0>
<digits0> := <digit>*
<sign> := { + | - }
<e-char> := { E | e }
<special> := [<sign>]{ <inf> | <nan-form> }
<inf> := { Inf | inf | INF |Infinity | infinity | INFINITY }
<nan-form> := <nan>[:<digits>]
<nan> := { NaN | nan | NAN }

Interpretation shall convert to the default IEEE format, with
roundTiesToEven for real numbers, and subject to overflow and
underflow exceptions. See IEEE 7.4 for overflow and IEEE 7.5
for underflow. The special number produced for an unloaded NaN
without a sign or with a plus sign is the positive, quiet nan
with zero load, and that produced by unloaded negative NaN is
its negative.

[**Make overflow/underflow ambiguous conditions?]

Nan loads shall be encoded as if they are binary integers
fitting into the trailing significand field of the default fp
format, with corresponding least signficant bits. An ambiguous
condition exists if the input load is too large for the default
format.

[**IEEE is not specific about the least significant bit, AFAICT,
but this makes sense to me.]

[**Separate RfD for some of this? If so, which part?]

6.2 Hexadecimal input
---------------------

IEEE requires a text format for numbers with a hexadecimal
significand, and decimal radix two exponent, with exact
conversion to and from binary fp formats where possible. See
IEEE 5.12.3, "External hexadecimal-significand character
sequences representing finite numbers".

The following syntax with mixed hexadecimal significand and
decimal radix two exponent is based on IEEE 5.12.3, and is
believed to be the same as C99. The definition of <dec-digit>
is the natural one, and that of <hex-digit> is also natural,
with both upper and lower case allowed.

Convertible string := <significand><exponent>

<significand> := [<sign>]{ <hex-prefix><hex-digits>[.<hex-digits0>]
| <hex-prefix>.<hex-digits> }

<exponent> := { <e-char>[<sign>]<dec-digits>|<e-char> }
[**Note that a sign with no digits is not allowed.]
<hex-digits> := <hex-digit><hex-digits0>
<hex-digits0> := <hex-digit>*
<dec-digits> := <dec-digit><dec-digits0>
<dec-digits0> := <dec-digit>*
<sign> := { + | - }
<e-char> := { P | p }
<hex-prefix> := { 0X | 0x }

Interpretation shall convert real numbers expressed with the
above syntax to the default fp format, subject to rounding via
roundTiesToEven, and subject to overflow/underflow exceptions.
See IEEE 7.4 for overflow and IEEE 7.5 for underflow. When the
input number is exactly representable in the default format,
the conversion shall be exact.

[**Make overflow/underflow ambiguous conditions?]

[**Separate RfD? The sentiment in comp.lang.forth seemed to be
yes, but I'm not sure that took into account the IEEE
requirement.]


7 GLOSSARY

Unless otherwise stated, all fp words that do computations or
comparisons shall obey the requirements and recommendations of
IEEE 5 and IEEE 6, for binary formats.

From IEEE 4, "Attributes and rounding", this specifiction adopts
only IEEE 4.3, "Rounding-direction attributes", including
roundTiesToEven, with the following caveat. The directed
rounding modes, roundTowardPositive, roundTowardNegative, and
roundTowardZero, need be implemented only if supported by the
underlying cpu. The roundTiesToAway mode, which IEEE does not
require, need not be implemented. See Sec. 7.x "for rounding".

7.1 Conversion
--------------

D>F ( d -- f: r )
F>D ( f: r -- s: d )

The DPANS94 specification is amended to include the
specification of IEEE 5.8, "Details of conversions from
floating-point to integer formats". In particular, when an
input r is signed zero, the output integer is zero; and when
the input integer is zero, the output r is +0.
[**IEEE mentions nan input, not that clear to me.]

>FLOAT ( c-addr u -- r: r s: flag )

The DPANS94 specification is extended to include special
numbers, with modified syntax. Conversion shall be governed
by IEEE 5.12, "Details of conversion between floating-point
data and external character sequences", except for paragraph 4
on hexadeximal conversions.
[**Separate Rfd for hex? A separate word, say, MIX>FLOAT ?]

A string of blanks [**or the empty string?] shall be treated
as +0. [**Allow formatting blanks or characters?]

Syntax of a convertible string := { <significand>[exponent]
| <special> }

<significand> := [<sign>]{ <digits>[.<digits0>] | .<digits> }
<exponent> := <marker><digits0>
<marker> := { <e-form> | <sign> }
<e-form> := <e-char>[<sign>]
<sign> := { + | - }
<e-char> := { D | d | E | e }
<special> := [<sign>]{ <inf> | <nan> }
<inf> := { Inf | inf | INF | infinity | Infinity }
<nan> := { NaN | nan | NAN }

[**mh prefers a mandatory <sign> in <special>. dnw favors
keeping it optional, in line with the omnivorous philosophy of
DPANS94 A.12.6.1.0558.]

REPRESENT ( f: r s: c-addr u -- n flag1 flag2 )

The DPANS94 specification is extended to include special
numbers. The valid-result flag, flag2, is false if r is
infinity or a nan.

[**This needs discussion.
1. Should the current rounding mode be used, instead of
roundTiesToEven?
2. Marcel says "It should be possible to format/output +Inf or
+NaN, also with the existing REPRESENT." Other opinions?
If nan is output, should its load be output as well?]

SF! ( f: r s: sf-addr -- )
SF@ ( sf-addr -- f: f )
DF! ( f: r s: df-addr -- )
DF@ ( sf-addr -- f: f )

The specification for these DPANS94 words is amended to
explicitly require conversion to or from the respective IEEE
binary32 or binary64 interchange formats, with exact
conversion in either direction for signed zero, signed
infinity, and real numbers to a wider format, and with
roundTiesToEven for conversion of real numbers to a narrower
format (see IEEE Sec. 5.4.2, formatOf-convertFormat). The
conversion of nans shall preserve the sign and signaling bit,
shall not signal an exception, and should treat payloads
according to IEEE 6.2.3.

[**Should the current rounding mode be used, instead of
roundTiesToEven?]

7.2 Output
----------

F. ( f: r -- )
FE. ( f: r -- )
FS. ( f: r -- )

The DPANS94 specification is extended to include the special
numbers, with output text of the appropriate form below, up to
implementation-dependent case sensitivity:
[**Default rounding? Or use the current rounding mode?]

[<sign>]0{ E | e }<space>
[<sign>]<inf><space>
[<sign>]<nan>[:<digits>]<space>

7.3 Comparison
--------------

[**Much of the following might go into a rationale section.]

IEEE has twenty-two required comparisons which apply to the full
set of numbers in any implemented fp format. Twelve of these
are quiet, and ten are signaling. See IEEE 5.6.1, "Comparisons",
and IEEE 5.11, "Details of comparison predicates".

This proposal requires only the quiet comparisons, which do not
raise exceptions.

IEEE identifies four fundamental, mutually exclusive
comparisons: less than ("<"), equal ("="), greater than (">"),
and unordered ("?"). Each of these is true iff all of the
others is false. We call these comparisons "fundamentals".
Together with logical negation and combinations, the
fundamentals can be used to express all twelve required
comparisons.

The basic rules are the following:

* The sign of zero is ignored.
* The sign of infinity is not ignored, and is treated in the
natural way for the "ordinary" comparisons with real numbers
or infinity, namely <, =, and >. In particular, either signed
infinity is equal to itself.
* The r1 ? r2 unordered comparison is true iff at least one of
r1 and r2 is a nan. That implies that any of the other
three, "ordinary" comparisons involving a nan is false.

The twelve required comparisons are the following, where "N"
indicates logical negation:

< = > ? N< N= N> N? <= >= <? >?

The four comparisons that involve two fundamentals, such as
"<=", are defined as the OR of the fundamentals, the usual
notation. The "<=" and ">=" comparisons are no longer simple
negations of ">" and "<", but are rather the AND's of those with
"N?", so fp stack gymnastics cannot be avoided if they are to be
expressed in terms of fundamentals.

It can be shown that <? is N(>=), and >? is N(<=). See IEEE
Table 5.3, "Required unordered-quiet predicates and negations".

DPANS94 has only F< and F~. Since IEEE "=" is semantically
different from 0E F~, adding F= is inevitable.

IEEE ">" is not expressible in terms of "<" and "=" plus logical
operations, but F> is expressible in Forth as FSWAP F<.

Furthermore, IEEE "?" is expressible as the AND of the
negations of the other three.

Thus there is an absolute minimum of two Forth words, say F< and
F=, which are sufficient to express all twelve IEEE comparisons,
with the help of 0=, AND, OR, and fp stack gymnastics. The
stack gymnastics, however, is already pretty bad for
combinations of two fundamentals, like F<=.

The upshot is that we propose two required and six recommended
Forth words, which can express the twelve IEEE comparisons with
the help of negations. As negations of the recommended F>= and
F<=, F<? and F>? could have been left out. They are included
because their names have more intuitive meaning than the
corresponding 0= phrases.

Implementation of the recommended words can be either primitive
or high level.

The same discussion applies to the F0< family owords.

F< ( f: r1 r2 -- s: [r1<r2]? )
F= ( f: r1 r2 -- s: [r1=r2]? )
F> ( f: r1 r2 -- s: [r1>r2]? ) rec
F? ( f: r1 r2 -- s: [r1?r2]? ) rec
F<= ( f: r1 r2 -- s: [r1<=r2]? ) rec
F>= ( f: r1 r2 -- s: [r1>=r2]? ) rec
F<? ( f: r1 r2 -- s: [r1<?r2]? ) rec
F>? ( f: r1 r2 -- s: [r1>?r2]? ) rec

F0< ( f: r1 r2 -- s: [r<0]? )
F0= ( f: r1 r2 -- s: [r=0]? )
F0> ( f: r1 r2 -- s: [r>0]? ) rec
F0? ( f: r1 r2 -- s: [r?0]? ) rec
F0<= ( f: r1 r2 -- s: [r<=0]? ) rec
F0>= ( f: r1 r2 -- s: [r>=0]? ) rec
F0<? ( f: r1 r2 -- s: [r<?0]? ) rec
F0>? ( f: r1 r2 -- s: [r>?0]? ) rec

The DPANS94 specification for F<, F0<, and F0= is extended to
the IEEE comparison semantics for the special numbers, with
the indicated predicate flag. The remaining words implement
the indicated IEEE comparisons. Words marked with "rec" are
recommended. The others are required.

[**The "?" for "unordered" can of course be confused with flag
notation, although it does have a bit of the right connotation.
Maybe FU and F0U, etc.?]

[**High level reference implementations of the recommended
words to be added later.]

[**Personally, I would add recommended words for the negations
of the four fundamentals, FN<, etc. :-) ]

F~ ( f: r1 r2 r3 -- s: flag )

If the sign of r3 is plus, flag is true iff the absolute value
of r1 minus r2 is less than r3, taking into account IEEE
arithmetic and comparison rules.

If r3 is signed zero, flag is true iff r1 and r2 have
identical formats.

If the sign of r3 is minus, flag is true iff the absolute
value of r1 minus r2 is greater than r3, taking into account
IEEE arithmetic and comparison rules.

[**Double check that the middle case is identical to the other
two when r3 is signed zero.]

7.4 Classification
------------------

IEEE 5.7.2, "General operations", requires a large number of
classification operations. This documents defines only those
corresponding to:

isSignMinus
isNormal
isFinite
isZero
isSubnormal
isInfinite
isNaN
isSignaling

Actually isSignMinus corresponds to FSIGNBIT, and isZero
corresponds to F0=, which leaves the following:

FINITE? ( r: r -- s: [normal|subnormal]? )
FNORMAL? ( r: r -- s: normal? )
FSUBNORMAL? ( r: r -- s: subnormal? )
FINFINITE? ( r: r -- s: [+|-]Inf? )
FNAN? ( r: r -- s: nan? )
FSIGNALING? ( r: r -- s: snan? )

[**Should FQUIET? be recommended.]

7.5 Arithmetic
--------------

See IEEE 5.4.1, "Arithmetic operations".

F* ( f: r1 r2 -- r1*r2 )
F*+ ( f: r1 r2 r3 -- [r2*r3]+r1 ) new
F+ ( f: r1 r2 -- r1+r2 )
F- ( f: r1 r2 -- r1-r2 )
F/ ( f: r1 r2 -- r1/r2 )
FSQRT ( f: r -- sqrt[r] )

The DPANS94 specification is extended to IEEE arithmetic. See
IEEE 5.1, "Overview" for precision, rounding, special number
treatment, and exceptions. See IEEE 5.4.1, "Arithmetic
operations", for the arithmetic words.

[** F*+ is the Forth name for the IEEE required
fusedMultiplyAdd operation.]

7.6 Math functions
-------------------

The Forth words FABS, FMAX, FMIN, and FSQRT are covered
elsewhere.

The DPANS94 specification for the following words is extended to
adopt the corresponding IEEE behavior. See IEEE 9.2, "Recommended
correctly rounded functions", and 9.2.1, "Special values".

F** FACOS FACOSH FALOG FASIN FASINH FATAN FATAN2
FATANH FCOS FCOSH FEXP FEXPM1 FLN FLNP1 FLOG FSIN
FSINCOS FSINH FSQRT FTAN FTANH

IEEE recommends additional functions, whose recommended Forth
names are:

FEXP2 FEXP2M1 FEXP10 FEXP10M1
FLOG2 FLOGP1 FLOG2P1 FHYPOT 1/FSQRT
FCOMPOUND FROOTN F**N |F|**
FSINPI FCOSPI FATANPI FATAN2PI

[**Separate RfD?]

7.7 Sign bit operations
-----------------------

FSIGNBIT ( f: r -- s: minus? ) C99:7.12.3.6

The following are all required by IEEE. See IEEE 5.5.1, "Sign
bit operations". The IEEE copy() function is superfluous in
Forth [**IIUC].

FNEGATE ( f: r -- -r )
FABS ( f: r -- |r| )

The DPANS94 specification is extended to the special numbers.

FCOPYSIGN ( f: r1 r2 -- r3 )

The output r3 is r1 with its sign bit replaced by that of r2.

7.8 Nearest integer functions
-----------------------------

FCEIL ( f: r1 -- r2 ) new
FLOOR ( f: r1 -- r2 )
FROUND ( f: r1 -- r2 )
FNEARBYINT ( f: r1 -- r2 ) new
FTRUNC ( f: r1 -- r2 ) new

These words correspond to the respective IEEE required
operations:

roundToIntegralTowardPositive
roundToIntegralTowardNegative
roundToIntegralTiesToEven
roundToIntegralExact
roundToIntegralTowardZero

See IEEE 5.3.1, "General operations" and 5.9, "Details of
operations to round a floating-point datum to integral value".
The names are based on C99. FTRUNC has already passed a CfV.
FNEARBYINT performs the function of whichever of the other
four corresponds to the current rounding mode [**IIUC].
No word is defined for IEEE roundToIntegralTiesToAway.

[**Separate RfD for the new words?]

7.9 Number manipulation
------------------------

FMAX ( f: r1 r2 -- r3 )
FMIN ( f: r1 r2 -- r3 )

The DPANS94 specification is extended to IEEE behavior for
the special numbers. See minNum and maxNum in IEEE 5.3.1,
"General operations" and 6.2, "Operations with NaNs".

[**IEEE also requires the equivalent of |F|MAX and |F|MIN.
Should we? It also requires an FREMAINDER.]

FNEXTUP ( f: r1 r2 -- r3 )

FNEXTUP returns the next number after r1 in the r2
direction. See 5.3.1, "General operations". FNEXTDOWN
is not defined. According to IEEE, nextDown(x) is
-nextUp(-x).


FSCALBN ( f: r s: n -- f: r*2^n.r )

The output is efficiently scaled by 2^n. See IEEE 5.3.3,
"logBFormat operations".

FLOGB ( f: r -- e.r )

Leave the radix-two exponent e of the fp representation. If r
is subnormal, the exponent is computed as if r were
normalized, with e < emin. See IEEE 5.3.3, "logBFormat
operations".

7.10 Exceptions
---------------

[**UNDER CONSTRUCTION]

7.11 Rounding modes
-------------------

[**UNDER CONSTRUCTION]

From IEEE 9.3, "Operations on dynamic modes for attributes", we
define only words corresponding to 9.3.1, "Operations on
individual dynamic modes". As stated earlier, roundTiesToAway
is not defined.

[**This scheme is based on a suggestion by Andrew Haley in
comp.lang.forth, which emerged from a discussion with Anton
Ertl.]

NEAR-ROUNDING ( -- )
CEIL-ROUNDING ( -- )
FLOOR-ROUNDING ( -- )
TRUNC-ROUNDING ( -- )

NEAR-ROUNDING{ ( -- ) compilation only
CEIL-ROUNDING{ ( -- ) compilation only
FLOOR-ROUNDING{ ( -- ) compilation only
TRUNC-ROUNDING{ ( -- ) compilation only
}ROUNDING ( -- ) compilation only

The first four words set the current rounding mode to
roundTiesToEven, roundTowardPositive, roundTowardNegative, and
roundTowardZero, respectively.

The next four, compilation only words save the current
rounding mode first, then set the current mode as indicated.
They must occur in balanced pairs with }ROUNDING (within the
same word definition), which restores the mode saved by the
first member of the pair. The return stack may be used for
saving and restoring the mode, which entails the usual
restrictions on the use of these words with DO ... LOOP,
locals, etc.


8 FOOTNOTES AND REFERENCES

[1] "IEEE Standard for Floating-Point Arithmetic", approved June
12, 2008 as IEEE Std 754-2008:
http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4610935

[2] "DRAFT Standard for Floating-Point Arithmetic P754", IEEE
754 draft 1.2.9, January 27, 2007:
http://www.validlab.com/754R/nonabelian.com/754/comments/Q754.129.pdf

[3] Wikipedia, "IEEE 754-2008":
http://en.wikipedia.org/wiki/IEEE_754

[4] ISO/IEC 9899:1999 (December 1, 1999),
ISO/IEC 9899:1999 Cor. 1:2001(E),
ISO/IEC 9899:1999 Cor. 2:2004(E),
ISO/IEC 9899:1999 Cor. 3:2007(E):
http://www.open-std.org/jtc1/sc22/wg14/www/standards.html#9899

[5] C99 + TC1 + TC2 is included in WG14/N1124, May 6, 2005:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf

[6] TC3: http://www.iec.ch/cgi-bin/getcorr.pl/yab/iso/
isoiec9899-cor3{ed1.0}en.pdf?file=iso/isoiec9899-cor3{ed1.0}en.pdf

[7] Single UNIX 3: http://www.unix.org/single_unix_specification/

[8] ANSI X3.215-1994 final draft:
http://www.taygeta.com/forth/dpans.html

[9] ISO/IEC 15145:1997:
http://webstore.ansi.org/RecordDetail.aspx?sku=ISO%2fIEC+15145%3a1997
http://www.iso.org/iso/catalogue_detail.htm?csnumber=26479
.

Relevant Pages

  • Re: cobol data format!!! urgent!!!
    ... misunderstood what "conformance to a standard" means. ... Cobol people 'know' binary floating-point is ... The quotation above is from IEEE 754. ... same as the IBM System/390 format which isn't the same as the Unisys MCP ...
    (comp.lang.cobol)
  • Re: RfD: IEEE-FP
    ... above syntax to the default fp format, ... and subject to overflow/underflow exceptions. ... See IEEE 7.4 for overflow and IEEE 7.5 for underflow. ... constants on a default binary64 system. ...
    (comp.lang.forth)
  • RfD: IEEE-FP 0.5.2
    ... the default format can be any IEEE binary ... restored to *nearly* the same as DPANS94 ... IEEE comparisons reworked ... This is a proposal for an optional Forth 200x word set, ...
    (comp.lang.forth)
  • Re: RfD: IEEE-FP
    ... although not given a name in IEEE. ... >> if the input load is too large for the default format. ... Conversion operations for binary formats 5.4.3.0 ... >> roundToIntegralExact ...
    (comp.lang.forth)
  • Re: Testing if a real is NaN
    ... Note also that they apply *only* to IEEE single and double format. ... I'm not sure that the IEEE standard specifies how infinities and NaNs are ... > usenet postings to find compensation for whatever went wrong in their ...
    (comp.lang.fortran)