IEEE-FP 0.5.3
David N. Williams
into two optional word sets, the "IEEE FLoating-Point" word set and the
"IEEE Floating-Point Environment" word set.
That implements a suggestion by Charles Montgomery:
> Several smaller pieces may have better success than one large
> one. Along those lines, it seems to me that a core capability
> which might perhaps be separated is provision for the IEEE
> special numbers: the abilities to input, output, and identify
> them. This would have to include >FLOAT, at least something
> about REPRESENT and conversions, and something like the four
> fundamental comparisons, at a minimum.
The core capability is in the IEEE Floating-Point word set,
which still specifies rounding and special results for
exceptions, but with nondefault rounding and access to exception
flags only available when the optional IEEE FLoating-Point
Environment word set is present. The reason for the split is
not so much political -- it actually seems logical.
Part of the reason this draft took so long was the attempt to
make the requirements for rounding and exceptions coherent,
including the issues of "current rounding" and "correct
rounding", even when rounding mode and exception flag words are
unspecified.
Summary of changes:
* Renumbered sections.
* More verbose reference style.
* In the introduction, elaborated on "optional".
* Added terminology.
* In the floating-point formats section and elsewhere, stated
that format encoding and layout are unspecified.
* Implementation section elaborated into subsections on
requirements, default fp format, accuracy, rounding (with
roundTiesToEven as default), and IEEE exceptions.
* In the environmental query section, elaborated the description
of entitlements and shuffled the logic. Added IEEE-FP-ENV
query.
* In the decimal input section, restored text interpretation of
floats to DPANS94, except for e|E option, and specified
behavior on failure. Current rounding.
* In the conversion section:
- D>F uses current rounding instead of roundTiesToEven.
- Failure of F>D results in an ambiguous condition.
- >FLOAT is minimally changed from DPANS94 to return false for
nan or infinity, and >IEEEFLOAT is added. Sigh! :-(
- REPRESENT uses current rounding.
- SF@, etc., nan conversion implementation defined, current
rounding.
* In the output section, current rounding.
* FSIGNALING? removed, FQUIET? not added.
* Current rounding for math functions. Left out suggested names
for IEEE-recommended functions not in Forth.
* In the number manipulation section, added FNEXTDOWN and
FREMAINDER.
* Added fp status flag words.
* Rounding mode words still undefined.
-- David
-------------------------------------------
PROPOSAL FOR TWO, OPTIONAL IEEE 754, BINARY
FLOATING-POINT WORD SETS
version 0.5.3
16-Aug-09
drafted by dnw, with several c.l.f. contributors, especially
Andrew, Anton, Ed, and Marcel (alphabetical order)
TABLE of CONTENTS
1 INTRODUCTION
2 TERMINOLOGY AND NOTATION
3 BINARY FLOATING-POINT FORMATS
4 IMPLEMENTATION
4.1 Requirements
4.2 Default format
4.3 Accuracy
4.4 Rounding
4.5 IEEE Exceptions
5 DATA TYPES
6 ENVIRONMENTAL QUERIES
7 TEXT INPUT
7.1 Constants
7.2 Decimal input
7.3 Hexadecimal input
8 IEEE FLOATING-POINT WORD SET
8.1 Conversion
8.2 Output
8.3 Comparison
8.4 Classification
8.5 Arithmetic
8.6 Math functions
8.7 Sign bit operations
8.8 Nearest integer functions
8.9 Data manipulation
9 IEEE FLOATING-POINT ENVIRONMENT WORD SET
9.1 Status flags
9.2 Rounding modes
10 REFERENCES
A.3 BINARY FLOATING-POINT FORMATS
A.7.1 NaN signs and loads
A.8.3 Comparison (informative rationale)
1 INTRODUCTION
This is a proposal for two, optional Forth 200x word sets,
called the "IEEE floating-point word set" and the "IEEE
floating-point environment word set", that support 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].
The standard [1] is hereafter referred to as "IEEE 754-2008",
with section numbers indicated by IEEE 754-2008 <number>.
This specification requires that ISO Forth [4,5] floating-point
and floating-point extension words in the optional floating-
point word set, when present with the IEEE floating-point word
set, satisfy additional IEEE 754-2008 requirements. Words in
that word set and this that correspond to mathematical,
including logical, operations or functions in IEEE 754-2008
adopt the behavior required or recommended there by reference,
as far as that is possible and sensible, unless otherwise
stated.
The specification is compatible with, rather than conformant to,
IEEE 754-2008, because it includes only a subset of the IEEE
requirements. It also aims to make many of the remaining
requirements expressible in Forth.
Reference [4], the final draft of "ANSI X3.215-1994, American
National Standard for Information Systems--Programming
Languages--Forth", is hereafter referred to as "DPANS94". It is
believed to be the same as the published version, ISO/IEC
15145:1997 [5]. This document adopts the official terminology
of DPANS94 unless otherwise stated. Section numbers in that
document are indicated by DPANS94 <number>.
The meaning of "optional" for these word sets is defined by
following two paragraphs from DPANS94 A.1.3.1:
The basic requirement is that if the implementor claims to
have a particular optional word set the entire required
portion of that word set must be available. If the
implementor wishes to offer only part of an optional word set,
it is acceptable to say, for example, "This system offers
portions of the [named] word set", particularly if the
selected or excluded words are itemized clearly.
and
Optional word sets may be offered in source form or otherwise
factored so that the user may selectively load them.
The current C99 standard [6-8], ISO/IEC 9899:1999, has a
comprehensive treatment of IEEE 754-1985, which offers a route
to implementation for those Forth systems that can call C
libraries. Reference [7] is believed to faithfully reflect the
current C99 standard. Section numbers from reference [7] are
indicated by C99:WG14/N1256 <number>.
[**Bracketed statements like this are for editorial questions
and comments, eventually to be removed.]
2 TERMINOLOGY AND NOTATION
"fp": Short for "floating point". The Forth floating-point
stack is called the "fp stack". In this document, synonymous
with "binary floating point".
"IEEE special datum", or an "IEEE special": Signed zero, a
quiet or signaling signed nan, or signed infinity.
"full IEEE set": For an IEEE binary format, the set of normal
and subnormal numbers plus special data that it represents.
"IEEE datum": Any member of a full IEEE set.
"IEEE arithmetic": Arithmetic defined by IEEE 754-2008 for IEEE
data.
"affinely extended reals": Finite real numbers and +/-infinity,
with -infinity < {every finite number} < +infinity.
"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": A quiet or signaling nan, respectively,
of any sign or load.
"single": In the context of Forth fp, an IEEE 754-2008 32-bit
interchange format.
"double": In the context of Forth fp, an IEEE 754-2008 64-bit
interchange format.
"default": In the context of Forth fp, the float format for
data that can appear on the fp stack.
"fp exception": Unless otherwise stated, never used in this
document in the sense of Forth CATCH and TRHOW, but always in
the sense of IEEE 754-2008:
2.1.18 exception: An event that occurs when an operation on
some particular operands has no outcome suitable for every
reasonable application. That operation might signal one or
more exceptions by invoking the default or, if explicitly
requested, a language-defined alternate handling. Note that
"event", "exception", and "signal" are defined in diverse
ways in different programming environments.
"fp status flag": C99:WG14/N1256 7.6:
A floating-point status flag is a system variable whose
value is set (but never cleared) when a floating-point
exception is raised, which occurs as a side effect of
exceptional floating-point arithmetic to provide auxiliary
information.
"fp control mode": C99:WG14/N1256 7.6:
A floating-point control mode is a system variable whose
value may be set by the user to affect the subsequent
behavior of floating-point arithmetic.
Only rounding control modes are addressed in this document.
In particular, alternate exception handling modes are not
included.
"correct rounding": Conversion of an infinitely precise result
to a floating-point number or infinity according to the
current rounding mode.
3 BINARY FLOATING-POINT FORMATS
Each IEEE binary fp 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.
See Section A.3 for more information about IEEE binary fp formats.
The binary fp formats in this document are to be regarded as
logical formats defined only by p and emax, with unspecified
encoding or layout in memory or on the fp stack. In particular,
neither the presence or absence of an explicit integer bit, b_0,
nor endianness, is specified.
4 IMPLEMENTATION
4.1 Requirements
----------------
The DPANS94 Floating-Point word set is an optional word set,
and so are the word sets described by this document.
The word "shall" in the remainder of this document states a
requirement when the environmental query for IEEE-FP or
IEEE-FP-ENV returns true. "Should" means "strongly
recommended". The special terminology "nominally shall" may be
applied to the current rounding mode, as explained in Section 4.4.
4.2 Default format
------------------
Default fp data, i.e., data that can appear on the fp stack,
shall correspond to one of the IEEE basic or extended, full
logical binary formats.
Data stored in memory by F! shall have the default logical
format.
4.3 Accuracy
------------
Unless otherwise stated, the accuracy of floating-point
conversion or calculation is left to the implementation. This
is inevitable because of practical limitations on the
computational state of the art.
4.4 Rounding
------------
IEEE 754-2008 specifies the following settable rounding modes:
roundTiesToEven
roundTowardPositive
roundTowardNegative
roundTowardZero
roundTiesToAway
The last of these seems to be new, and is not addressed in this
document. The first four are commonly implemented in hardware
that claims IEEE compliance.
IEEE 754-2008 requires roundTiesToEven as the default mode for
binary rounding, and recommends that for decimal rounding. This
document adopts the same; roundTiesToEven shall be the default
for binary rounding and should be the default for decimal
rounding.
In DPANS94, a few words use "round to nearest" in the same sense
as roundTiesToEven. On the other hand, fp decimal to binary
conversion by the text interpreter, the printing words, and all
of the arithmetic and math function words use implementation-
defined rounding.
[**DPANS94 12.3.1.2:
...
Any rounding or truncation of floating-point numbers is
implementation defined.
]
Many IEEE floating-point operations specify that the current
rounding mode shall be used. This document adopts that where
relevant, but often makes it a "nominal shall", because of the
correct rounding issue mentioned below.
Using the current rounding mode affects text interpretation,
arithmetic operations, math functions except nearest integer
functions, and the following words, listed according to DPANS94
rounding:
REPRESENT DF! DF@ SF! SF@ round to nearest
>FLOAT F. FE. FS. implementation defined
In this specification, the words in the round to nearest list
remain compatible with DPANS94 programs when the current
rounding mode is the default mode.
The rounding mode can be changed from the default mode only by
words in the optional IEEE Floating-Point Environment word set.
Ideally, mathematical functions ought to be "correctly rounded",
i.e., computed with infinite accuracy and then rounded in the
current mode. Because accuracy is implementation defined,
correct rounding in this document is a "should", not a "shall",
except for the arithmetic functions in Section 8.5.
Because of the interaction between accuracy and rounding, when
use of the current rounding mode is required it may be specified
as a "nominal shall", which means that when accuracy is
sufficient for the rounding mode to make a difference, it is to
be regarded as a "shall", otherwise as a "should".
4.5 IEEE Exceptions
-------------------
IEEE floating-point exceptions have two aspects, signaling and
flags.
Signaling simply means handling the exception.
There are flags for five exceptions, all commonly implemented
in hardware that claims IEEE compliance: invalid, divideByZero,
overflow, underflow, and inexact.
Flags can be raised by an IEEE compliant system or by a user
program. The act of raising a flag does not cause any other
action. Reading a flag does not change it. A flag can be
lowered only by explicit user request.
IEEE specifies the fp operations and conditions that signal
exceptions. According to IEEE 754-2008 7.1, "Overview:
exceptions and flags", the default handling is nearly always to
produce a default datum, raise the corresponding flag, and keep
going.
IEEE recommends that a language standard should define
alternate, nondefault handling for fp exceptions, with
guidelines that allow stopping program execution and reporting
an error [**IIUC].
This document specifies the default to be IEEE default handling,
invoked under the conditions required by IEEE 754-2008 unless
otherwise stated, with the aim of restricting alternate handling
as little as possible. An interface for alternate handling is
not specified, but would have to interact with the system at a
low level to change the system default handling of exceptions in
general fp operations such as F+, F*, etc.
The exception flags can be accessed only by the optional IEEE
Floating-Point Environment word set. When those words are not
present, the IEEE system requirements for setting the flags are
moot, because the flags have no side effects. Then the only
noticeable effect of exceptions is to produce IEEE special data.
5 DATA TYPES
For the purpose of this document, the DPANS94 r type is extended
to include all IEEEE data for the default fp format.
5 ENVIRONMENTAL QUERIES
[**CHANGES
The entitlements of the two queries are revised to move the
MAX-FLOAT entitlement to the IEEE-FP query, and an IEEE-FP-ENV
query is added. The following additonal specification is
proposed, so that when an application receives true from one of
the queries, it can simply drop the "known" flag returned by
specified others.
]
If either of the first two queries returns true for the "known"
flag, then so shall the other. If the third query returns true,
then so shall the other two.
Value
String Data Type Constant? Meaning
------------------------------------------------------------------
IEEE-FP flag no IEEE and DPANS94 floating-point word
sets present
IEEE-FP-FORMAT d no in usual stack notation, the default
format has IEEE parameters ( emax p )
IEEE-FP-ENV flag no IEEE floating-point environment word
set present
------------------------------------------------------------------
A true result for the IEEE-FP environmental query shall mean
that any words that are present from the DPANS94 floating-point
word set, the DPANS94 floating-point extensions word set, or the
IEEE floating-point word set obey the specifications of this
document, and that generic specifications not related to the
presence or absence of particular words are satisfied.
It shall also mean that the DPANS94 MAX-FLOAT query shall return
true and the largest, finite number in the default format.
The data value for the IEEE-FP query is true if and only if all
words in the DPANS94 and IEEE floating-point word sets are
present.
Nothing in this document depends on the encoding of the logical
format corresponding to the values of emax and p returned as
data by the IEEE-FP-FORMAT query.
The data value for the IEEE-FP-ENV query is true if and only if
all words in IEEE floating-point environment word set are
present.
7 TEXT INPUT
7.1 Constants
-------------
+INF ( f: -- +Inf )
-INF ( f: -- -Inf )
+NAN ( f: -- +NaN )
-NAN ( f: -- -NaN )
These words return, respectively, IEEE signed infinity and the quiet
signed nan with zero load, in the default format.
See Section A.7.1 for more information about the encoding of NaN.
7.2 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 754-2008 5.4.2, "Conversion
operations for floating-point formats and decimal character
sequences", and 5.12, "Details of conversion between
floating-point data and external character sequences".
Conversion of nan loads is not included in this specification.
Signed infinity and signed, quiet, unloaded nans are covered by
the constants defined in Section 7.1. Signed zero is already
included in the syntax specification in DPANS94 12.3.7, "Text
input number conversion".
DPANS94 12.3.7 specifies that the number-conversion algorithm
used by the text interpreter is to be extended to recognize
floating-point numbers when the base is decimal, with an
implication that the behavior on failure is to be governed by
the introductory paragraphs in DPANS94 3.4, "The Forth
interpreter". This document slightly modifies the syntax
specification, and is more explicit about failure.
When IEEE-FP is present, the syntax specification in DPANS94
12.3.7 shall be replaced by:
Convertible string := <significand><exponent>
<significand> := [<sign>]<digits>[.<digits0>]
[**Note that a leading digit before any
decimal point is required, as in DPANS94.]
<exponent> := <e-char>[<sign>]<digits0>
[**Note that a sign with no digits is still
recognized, as in DPANS94.]
<digits> := <digit><digits0>
<digits0> := <digit>*
<sign> := { + | - }
<e-char> := { E | e }
[**Note the extra "e" option.]
<digit> := { 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 }
The only change in syntax is the additional "e" option in
<e-char>.
Interpretation shall convert to a finite, real number in the
default floating-point format, and nominally shall use the
current rounding mode. An ambiguous condition exists if
conversion overflows, or if the syntax is not satisfied and
causes unsuccessful text intepretation, in which case behavior
shall be governed by DPANS94 3.4.4, "Possible actions on an
ambiguous condition".
[**QUOTE
3.4.4 Possible actions on an ambiguous condition
When an ambiguous condition exists, a system may take one or
more of the following actions:
* ignore and continue;
* display a message;
* execute a particular word;
* set interpretation state and begin text interpretation;
* take other implementation-defined actions;
* take implementation-dependent actions.
The response to a particular ambiguous condition need not be the
same under all circumstances.
]
7.3 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".
Conversion of that format is not included in this specification.
8 IEEE FLOATING-POINT WORD SET
This is an optional word set.
Unless otherwise stated, all fp words that do computations or
comparisons shall obey the requirements and recommendations of
IEEE 754-2008 5 and 6, for binary formats.
8.1 Conversion
--------------
D>F ( d -- f: r )
The DPANS94 specification is amended to require that when d
cannot be represented precisely in the default fp format, r
shall be shall be rounded according to the current rounding
mode.
[**IEEE and C99 background:
IEEE does not seem to specify an equivalent. C99:WG14/N1256
6.3.1.4, paragraph 2 says:
When a value of integer type is converted to a real floating
type, if the value being converted can be represented exactly
in the new type, it is unchanged. If the value being
converted is in the range of values that can be represented
but cannot be represented exactly, the result is either the
nearest higher or nearest lower representable value, chosen in
an implementation-defined manner. If the value being
converted is outside the range of values that can be
represented, the behavior is undefined.
Note that d is always in range for any of the formats
binary32, binary64, binary80, and binary128.
]
F>D ( f: r -- s: d )
The DPANS94 specification is amended to state that an
ambiguous condition exists, not only when the integer part of
r is not representable by a signed, double number, but also
when r is a nan or infinity.
[**RATIONALE
The DPANS94 version corresponds to convertToIntegerTowardZero();
see IEEE 754-2008 5.8, "Details of conversions from
floating-point to integer formats". IEEE requires that the
invalid operation exception be signaled when r is a nan or
infinity or out of range of the destination format.
IEEE also requires
convertToIntegerTiesToEven()
convertToIntegerTowardPositive()
convertToIntegerTowardNegative()
convertToIntegerTiesToAway()
plus versions of the five conversions that signal inexact when
appropriate. Note that, except for convertToIntegerTiesAway,
the nonsignaling conversions are equivalent to Forth phrases
such as "FCEIL F>D".
]
>FLOAT ( c-addr u -- [r: r s: true]|[false] )
The phrase "the string represents a valid floating-point
number" in the DPANS94 12.6.1.0558 shall be interpreted to
mean that it represents a finite number in the range of the
default format.
>IEEEFLOAT ( c-addr u -- [r: r s: true]|[false] )
This word extends the functionality of >FLOAT to include IEEE
special data, with modified syntax.
The decimal to binary conversion nominally shall use the
current rounding mode.
Overflow, underflow, and inexact exceptions shall be treated
according to IEEE 754-2008 7.4, "Overflow", 7.5 "Underflow",
and 7.6 "Inexact".
If the string represents a real number in the syntax below,
the result of conversion to the default format (signed
infinity on overflow) and true are returned.
If the string represents an IEEE special datum in the syntax
below, the datum and true are returned, with no change in the
fp exception status. A string of blanks [**or the empty
string?] shall be treated as +0.
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 }
REPRESENT ( f: r s: c-addr u -- n flag1 flag2 )
The DPANS94 specification is extended to include IEEE
specials. Instead of "round to nearest", the decimal mantissa
string nominally shall use the current rounding mode instead
of "round to nearest".
If flag2 is true, r was a finite number; if false,
either r was infinity and n = 0, or r was a nan and n is an
nonzero, implementation-defined number. If flag1 is true,
then the sign bit of r was one; otherwise the sign bit was
zero.
[**RATIONALE
The IEEE extension of REPRESENT aims to change the DPANS94
specification as little as possible. When the current
rounding mode is the default, roundTiesToEven, and flag2 is
true, all results nominally coincide with DPANS94. When flag2
is false, DPANS94 makes n and flag1 implementation defined.
The implementation-defined value of n for nans could be used
in a future proposal to encode information about the signaling
bit and load.]
[**DPANS94 does not embed the sign in the mantissa string,
contrary to impressions in c.l.f.
There was a request to have REPRESENT produce strings for
infinity and nan, but I couldn't see a good way to do that,
given that u might be less than three. The presence of either
is easy to detect.]
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
754-2008 binary32 or binary64 logical interchange formats,
with implementation-defined memory layout. The conversion
shall be exact in either direction for signed zero, signed
infinity, and real numbers to a wider format, and shall use
the current rounding mode for conversion of real numbers to a
narrower format (see IEEE 754-2008 5.4.2, formatOf-convertFormat).
The conversion of nans is implementation defined, but should
not signal an exception, should preserve the sign bit, and
should treat payloads according to IEEE 754-208 6.2.3, "NaN
propagation".
[**CHANGES: current rounding, and nan conversion
implementation defined. IIUC these nan "shoulds" would be
automatic for the intel FLD and FST ops.]
8.2 Output
----------
F. ( f: r -- )
FE. ( f: r -- )
FS. ( f: r -- )
The DPANS94 specification is extended to include IEEE
specials, with output text of the appropriate form below, with
implementation-dependent case sensitivity:
[<sign>]0{ E | e }<space>
[<sign>]{ Inf | INF | inf }<space>
[<sign>]{ NaN | NAN | nan }<space>
The current rounding mode nominally shall be used.
[**CHANGE: current rounding mode. In DPANS94 it's
implementation defined.]
8.3 Comparison
--------------
IEEE has twenty-two required comparisons which apply to the full
set of IEEE data. Twelve of these are quiet, and ten are
signaling. See IEEE 754-2008 5.6.1, "Comparisons", and 5.11,
"Details of comparison predicates".
This proposal requires only quiet comparisons, which do not
signal exceptions, and of those, only a subset of five, which is
sufficient for expressing all twelve.
See Section A.8 for rationale and more information about the
remaining comparisons, with high-level implementation examples.
IEEE identifies four fundamental, mutually exclusive
comparisons: less than ("<"), equal ("="), greater than (">"),
and unordered (see rule 3 below). Each of these is true iff
each of the others is false.
The basic rules are the following:
1. The sign of zero is ignored.
2. 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.
3. The unordered comparison is true iff at least one of its two
arguments is a nan. That implies that any of the other
three, "ordinary" comparisons involving a nan is false.
The five required comparisons are "<", ">", "=", "<=", and ">=",
where "<=" and ">=" stand for the usual phrases "less than or
equal" and "greater than or equal". Note that familiar
identities for real numbers are generally not satisfied by IEEE
comparisons. For example, the negation of "<" is not the same
as ">=". See Section A.8.
F< ( f: r1 r2 -- s: [r1<r2]? )
F= ( f: r1 r2 -- s: [r1=r2]? )
F> ( f: r1 r2 -- s: [r1>r2]? )
F<= ( f: r1 r2 -- s: [r1<=r2]? )
F>= ( f: r1 r2 -- s: [r1>=r2]? )
F0< ( f: r -- s: [r<0]? )
F0= ( f: r -- s: [r=0]? )
F0> ( f: r -- s: [r>0]? )
F0<= ( f: r -- s: [r<=0]? )
F0>= ( f: r -- s: [r>=0]? )
The data stack outputs are DPANS94 flags corresponding to the
indicated IEEE predicates. In particular, the specifications
for the existing DPANS94 words F<, F0<, and F0= are extended
to include IEEE specials.
F~ ( f: r1 r2 r3 -- s: flag )
If r3 has positive sign and is neither a nan nor zero, 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 r3 has negative sign and is neither a nan nor zero, flag is
true iff the absolute value of r1 minus r2 is less than the
absolute value of r3 times the sum of the absolute values of
r1 and r2, taking into account IEEE arithmetic and comparison
rules.
If r3 is a nan, flag is false.
8.4 Classification
------------------
IEEE 754-2008 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
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? )
8.5 Arithmetic
--------------
See IEEE 5.4.1, "Arithmetic operations".
F* ( f: r1 r2 -- r1*r2 )
F*+ ( f: r1 r2 r3 -- [r2*r3]+r1 )
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.
These operations shall be correctly rounded. See IEEE
754-2008 5.1, "Overview", for precision, rounding, special
data treatment, and exceptions and 5.4.1, "Arithmetic
operations", for the arithmetic words.
8.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. These words should be
correctly rounded, and nominally shall use current rounding.
See IEEE 754-2008 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
8.7 Sign bit operations
-----------------------
FSIGNBIT ( f: r -- s: minus? )
This word corresponds to isSignMinus in IEEE 754-2008 5.7.2,
"General operations". The name is based on C99.
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 IEEE specials.
FCOPYSIGN ( f: r1 r2 -- r3 )
The output r3 is r1 with its sign bit replaced by that of r2.
8.8 Nearest integer functions
-----------------------------
All of the words in this section correspond to C99 functions
with similar names, including the already existing FLOOR and
FROUND from DPANS94 and FTRUNC from Forth 200x, except that the
C99 round() does roundToIntegralTiesToAway instead of
roundToIntegralTiesToEven.
FCEIL ( f: r1 -- r2 )
FLOOR ( f: r1 -- r2 )
FROUND ( f: r1 -- r2 )
FTRUNC ( f: r1 -- r2 )
These words correspond to the respective IEEE required
operations:
roundToIntegralTowardPositive
roundToIntegralTowardNegative
roundToIntegralTiesToEven
roundToIntegralTowardZero
See IEEE 754-2008 5.3.1, "General operations" and 5.9,
"Details of operations to round a floating-point datum to
integral value". No word is defined for IEEE
roundToIntegralTiesToAway.
FNEARBYINT ( f: r1 -- r2 )
This word corresponds to the IEEE required operation:
roundToIntegralExact
It performs the function of whichever of the other four
corresponds to the current rounding mode.
8.9 Data manipulation
---------------------
FMAX ( f: r1 r2 -- r3 )
FMIN ( f: r1 r2 -- r3 )
The DPANS94 specification is extended to IEEE specials. See
minNum and maxNum in IEEE 754-2008 5.3.1, "General operations"
and 6.2, "Operations with NaNs".
FNEXTUP ( f: r1 -- r2 )
FNEXTDOWN ( f: r1 -- r2 )
When r1 is a nonzero real number, FNEXTUP returns the next
affinely extended real in the default format that compares
larger than r1, and FNEXTDOWN returns the next one that
compares less than r1. See IEEE 754-2008 5.3.1, "General
operations" for the behavior when r1 is an IEEE special.
[**RATIONALE
FNEXTDOWN can be defined as:
: FNEXTDOWN ( f: r1 -- f2 ) FNEGATE FNEXTUP FNEGATE ;
For accuracy control, it is useful to have efficient
implementations of both words.
]
FSCALBN ( f: r s: n -- f: r*2^n )
The output is efficiently scaled by 2^n. See IEEE 754-2008 5.3.3,
"logBFormat operations".
FLOGB ( f: r -- e )
Leave the radix-two exponent e of the fp representation as an
fp integer. If r is subnormal, the exponent is computed as if
r were normalized, with e < emin. See IEEE 754-2008 5.3.3,
"logBFormat operations" for treatment of IEEE specials.
FREMAINDER ( f: x y -- r q )
When y is not 0, the remainder r = fremainder(x, y) is defined
for finite x and y regardless of the current rounding mode by
the exact mathematical relation r = x - y * q, where q is the
integer nearest the exact number x/y, with roundToIntegralTiesToEven.
If r = 0, its sign shall be that of x, and fremainder(x, inf)
is x for finite x. See IEEE 754-2008 5.3.1, "General
operations".
9 IEEE FLOATING-POINT ENVIRONMENT WORD SET
This is an optional word set.
9.1 Status flags
----------------
A floating-point status flag is raised, but never lowered, as a
side effect of an fp operation. The default side effect also
provides a default fp datum and does not interrupt program flow.
Floating-point status flags can be raised or lowered by
SET-FSTATUS, and read by GET-FSTATUS. Both words have normal
interpretation and compilation semantics.
In the following, "fmask" stands for "floating-point status
mask", and "fflags" stands for the bit-wise OR of flag data
corresponding to an fmask.
The fp status flags correspond to the following distinct,
nonzero fp flag masks:
FDIVBYZERO FINEXACT FINVALID FOVERFLOW FUNDERFLOW
Masks may be OR'd to form fmask's.
[**RATIONALE
The mask names correspond to the C99 macros FE_DIVBYZERO,
FE_INEXACT, FE_INVALID, FE_OVERFLOW, and FE_UNDERFLOW, based on
C99:WG14/N1256 7.6.2.
The masks have nothing to do with the corresponding cpu masks in
intel processors, which select the default or an alternate IEEE
fp exception handler.
]
GET-FSTATUS ( fmask -- fflags )
Return the bit-wise OR of the current fp status flags selected
by the nonzero bits of fmask, without changing the status. It
is an ambiguous condition if fmask is not the OR of a subset
of the five, named masks, or if the underlying system does not
support all five flags.
SET-FSTATUS ( fflags fmask -- )
Set the values of the fp status flags selected by fmask to the
values of the corresponding bits in fflags, without side
effects. It is an ambiguous condition if fmask is not the OR
of a subset of the five, named masks, or if the underlying
system does not support all five flags.
[**MORE RATIONALE
The spirit of IEEE 754-2008 exceptions is that processing
continues without interrupting program flow. A default fp datum
is returned, and an exception flag is set, along with other
possible status information. Applications can query such
results and react to them. This scheme provides great
flexibility.
IEEE 754-2008 also allows the implementation of nondefault
exception handlers, which may interrupt program flow. C99 has
provisions for switching to such a mode, but does not require
it, and seems vague about how it's to be done.
The proposed words implement the simplest model, where the only
information provided about the fp exception state is the flag
values. The C99 functions fegetexceptflag() and
fesetexceptflag() are models for GET-FPSTATUS and SET-FPSTATUS.
Extra words that allow more information could be proposed in the
future, if needed.
The following quote from the C99 standard describes the intended
programming style, both for fp status flags and rounding modes.
C99:WG14/N1256 7.6, "Floating-point environment <fenv.h>",
paragraph 2:
Certain programming conventions support the intended model of
use for the floating-point environment:175)
- a function call does not alter its caller's floating-point
control modes, clear its caller's floating-point status
flags, nor depend on the state of its caller's
floating-point status flags unless the function is so
documented;
- a function call is assumed to require default floating-point
control modes, unless its documentation promises otherwise;
- a function call is assumed to have the potential for raising
floating-point exceptions, unless its documentation promises
otherwise.
175) With these conventions, a programmer can safely assume
default floating-point control modes (or be unaware of
them). The responsibilities associated with accessing the
floating-point environment fall on the programmer or program
that does so explicitly.
]
9.2 Rounding modes
------------------
[**UNDER CONSTRUCTION
This section is currently under discussion in comp.lang.forth.
See IEEE 9.3, "Operations on dynamic modes for attributes". Only
words corresponding to 9.3.1, "Operations on individual dynamic
modes", are expected to be implemented, and among those,
roundTiesToAway is not expected to be implemented.
]
9 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] ANSI X3.215-1994 final draft:
http://www.taygeta.com/forth/dpans.html
[5] 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
[6] 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
[7] C99, TC1, TC2, and TC3 are included in the freely available
WG14/N1256, September 7, 2007 [**thanks to David Thompson]:
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf
[8] Single UNIX 3, AFAICS duplicates the C99 library spec, with
some things pinned down more tightly [**thanks to David
Thompson]:
http://www.unix.org/single_unix_specification/
A.3 BINARY FLOATING-POINT FORMATS
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 the four binary interchange formats
shown in Table 3, plus those with storage widths of more than
128 bits that are a multiple of 32 bits.
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).
binary 16 binary32 binary64 binary128
---------------------------------------------------
k = 16 32 64 128
p = 11 24 53 113
emax = 15 127 1023 16383
Note that the intel 80-bit format corresponds to one of the
extended binary64 formats, 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, it may be called the "binary80" basic format. Its
implementation normally differs from that of the other basic
formats by having an explicit leading bit for normal and
subnormal numbers.
Binary interchange formats are logical formats, with unspecified
memory layout. They all have an implicit leading bit for normal
and subnormal numbers.
Note that the binary128 interchange format is the only one in
Table 3 that can contain the binary80 basic format. IEEE does
not define a binary80 interchange format.
A.7.1 NAN SIGNS AND LOADS
IEEE allows the load for nan results like 0E 0E F/ to be
anything, so the following does not necessarily give a zero
load:
0E 0E F/ FABS FCONSTANT +NAN
Aside from the ambiguous load, the FABS (extended to nan) is
necessary here, because not only does IEEE not specify the sign,
both pfe and gforth actually give opposite signs for 0E 0E F/
under ppc (+) vs. intel (-) Mac OS X. They do both give quiet
nans with zero load.
As a matter of fact, the intel QNaN "floating-point indefinite"
is the qnan with zero load and negative sign, according to
"Intel(R) 64 and IA-32 Architectures Software Developer's
Manual, Volume 1: Basic Architecture", Table 4-3:
http://www.intel.com/Assets/PDF/manual/253665.pdf
A.8.3 COMPARISON (INFORMATIVE RATIONALE)
[**Any high-level definitions in this section assume a separate
floating-point stack.]
The twelve IEEE required comparisons are the following, where
"N" means logical negation, "?" stands for "unordered", and "<?"
and ">?" stand for "less than or unordered" and "greater than or
unordered":
< = > ? N< N= N> N? <= >= <? >?
Unfortunately, the common notation "?" for the unordered
predicate clashes with Forth practice, where "?" usually
[**always?] indicates a flag or test. The ? notation is used
here as a convenience for IEEE predicates, and does not appear
in any corresponding Forth names.
The <= and >= comparisons are no longer simple negations of >
and <, but are rather the AND's of those negations with N?. It
can be shown that <? is N(>=), and >? is N(<=). See IEEE Table
5.3, "Required unordered-quiet predicates and negations".
It is possible to implement all of the IEEE comparisons via
high-level definitions in terms of a few low-level words, even
fewer than the five required for this word set. The following
remarks are offered as a guide to possibilities for the choice
of low-level words.
DPANS94 has only F< and F~. Since IEEE "=" is semantically
different from 0E F~, low-level implementation of F= seems
inevitable. The two words F< and F= are probably a minimum set
for high-level implementation of the rest.
For example, IEEE ">" is not expressible in terms of "<" and "="
plus logical operations, but F> can be defined as:
: F> ( f: r1 r2 -- s: [r1>r2]? ) FSWAP F< ;
FUNORDERED is not required by this document; in particular, the
name is not reserved; but it can be defined as
: FUNORDERED ( f: r1 r2 -- s: [r1?r2]? )
FDUP F= FDUP F= AND 0= ;
The logical negations N<, N=, N>, and N? can be expressed with
the Forth phrases "F< 0=", etc.
Forth words for the <= and >= predicates can be defined as
: F2DUP ( f: r1 r2 -- r1 r2 r1 r2 ) FOVER FOVER ;
: F<= ( f: r1 r2 -- s: [r1<=r2]? ) F2DUP F< F= OR ;
: F>= ( f: r1 r2 -- s: [r1>=r2]? ) F2DUP F> F= OR ;
The <? and >? predicates can be expressed by the Forth
phrases "F>= 0=" and "F<= 0=".
Thus all twelve IEEE predicates can be expressed with the five
required words, and as few as two.
[**Treat the following as a footnote.]
It can be shown that the closure of the four fundamental IEEE
comparison predicates under AND, OR, and negation consists of
sixteen independent relations, including the twelve that IEEE
requires. Two additional elements are the trivial,
identically true and false relations, and the other two are
"less than or greater than" and its negation, "unordered or
equal". The five words of this word set, plus their five
negations, implement the only nontrivial, transitive relations
among the sixteen.
On the other hand, several current cpu's have efficient
operations for all four of the fundamental IEEE comparisons, <,
>, =, and ?. Low-level implementations of at least F<, F>, and
F=, would be natural for such systems.
All of the words in the F0< family can be defined by analogy to
: F0< ( f: r -- s: [r<0]? ) 0E F< ;
pet4th
Long time no see. I hope everybody doing well.
Forth used to be used in old computers, where there is no coprocessor.
Double takes form: xxxx.xxx
Float takes form: x.xE
One of my application use double, so the user needs to insert "." in
the command line:
xyz 1234.
Another use command line instruction:
calculate 1.0E 3.0E f/ f.
Don't you think it is better to have:
xyz 1234
calculate 1 3 / .
?
To do that:
- change integer and floating point prefix
dup -> idup
fdup -> dup
> -> i>
f> -> >
etc
- change parsing from
1. check defined?
2. test integer or double
3. test float
to
1. check defined?
2. test float except the number is prefix with $(hex),#integer or
double
Regards,
Petrus.
Krishna Myneni
> Here's draft 0.5.3 of the IEEE-FP proposal. It has been divided
> into two optional word sets, the "IEEE FLoating-Point" word set and the
> "IEEE Floating-Point Environment" word set.
>
Hi David,
It would be useful for the proposal to contain a summary of the
following:
a) list of all words which are covered by this proposal
b) list of words which are new, i.e. not present in the existing
(Forth-94) specification
Krishna
David N. Williams
> Hi all,
>
> Long time no see. I hope everybody doing well.
Good to see you're back!
> Forth used to be used in old computers, where there is no coprocessor.
> Double takes form: xxxx.xxx
> Float takes form: x.xE
>
> One of my application use double, so the user needs to insert "." in
> the command line:
> xyz 1234.
>
> Another use command line instruction:
> calculate 1.0E 3.0E f/ f.
>
> Don't you think it is better to have:
> xyz 1234
> calculate 1 3 / .
> ?
That would indeed save typing for me, because most of the
calculations I do from the command line are floating point. But
it wouldn't fly as part of this IEEE proposal for Forth 200x.
This experience has taught me that even much less invasive
changes to number syntax are controversial, and would require a
separate proposal.
> To do that:
> - change integer and floating point prefix
> dup -> idup
> fdup -> dup
> > -> i>
> f> -> >
> etc
> - change parsing from
> 1. check defined?
> 2. test integer or double
> 3. test float
> to
> 1. check defined?
> 2. test float except the number is prefix with $(hex),#integer or
> double
I understand your logic, but I'm mostly comfortable with the
existing style. :-)
-- David
David N. Williams
You're right. :-)
-- David
Ed
> Here's draft 0.5.3 of the IEEE-FP proposal. It has been divided
> into two optional word sets, the "IEEE FLoating-Point" word set and the
> "IEEE Floating-Point Environment" word set.
>
> That implements a suggestion by Charles Montgomery:
>
> > Several smaller pieces may have better success than one large
> > one. Along those lines, it seems to me that a core capability
> > which might perhaps be separated is provision for the IEEE
> > special numbers: the abilities to input, output, and identify
> > them. This would have to include >FLOAT, at least something
> > about REPRESENT and conversions, and something like the four
> > fundamental comparisons, at a minimum.
>
>
> REPRESENT ( f: r s: c-addr u -- n flag1 flag2 )
>
> The DPANS94 specification is extended to include IEEE
> specials. Instead of "round to nearest", the decimal mantissa
> string nominally shall use the current rounding mode instead
> of "round to nearest".
>
> If flag2 is true, r was a finite number; if false,
> either r was infinity and n = 0, or r was a nan and n is an
> nonzero, implementation-defined number. If flag1 is true,
> then the sign bit of r was one; otherwise the sign bit was
> zero.
>
> [**RATIONALE
> The IEEE extension of REPRESENT aims to change the DPANS94
> specification as little as possible.
>
>
> [**DPANS94 does not embed the sign in the mantissa string,
> contrary to impressions in c.l.f.
IIRC the discussions involving embedded sign pertained
only to non-number strings i.e. when flag2 = false.
> There was a request to have REPRESENT produce strings for
> infinity and nan, but I couldn't see a good way to do that,
> given that u might be less than three.
> ...
This conclusion appears based on a mis-reading of the Standard.
Nans/infs aren't numbers, don't have a significand, and can't be
rounded to "u ... significant digits". There is nothing in the spec
to support a view that 'u' applies to non-numbers.
If you're going to require implementers to make changes to
REPRESENT anyway, why not do the job properly. The spec
for it already exists:
ftp://ftp.taygeta.com/pub/Forth/Applications/ANS/Represent_21.txt
As it was intended for general ANS use, it doesn't yet specify
strings for nan/inf or the values for n2, flag1. Signed-zero
is allowed.
Andrew Haley
> REPRESENT ( f: r s: c-addr u -- n flag1 flag2 )
> The DPANS94 specification is extended to include IEEE
> specials. Instead of "round to nearest", the decimal mantissa
"significand", not "mantissa". It's not a mantissa.
> string nominally shall use the current rounding mode instead
> of "round to nearest".
> If flag2 is true, r was a finite number; if false,
> either r was infinity and n = 0, or r was a nan and n is an
> nonzero, implementation-defined number. If flag1 is true,
> then the sign bit of r was one; otherwise the sign bit was
> zero.
> [**RATIONALE
> The IEEE extension of REPRESENT aims to change the DPANS94
> specification as little as possible. When the current
> rounding mode is the default, roundTiesToEven, and flag2 is
> true, all results nominally coincide with DPANS94. When flag2
> is false, DPANS94 makes n and flag1 implementation defined.
> The implementation-defined value of n for nans could be used
> in a future proposal to encode information about the signaling
> bit and load.]
> [**DPANS94 does not embed the sign in the mantissa string,
> contrary to impressions in c.l.f.
This is rather underspecified. We need to make it explicit that this
is the binary to decimal conversion routine that can be used to
satisfy the requirement of exact conversion: conversion back to binary
recovers the original representation except that NaNs may be converted
to a canonical NaN. (This is a basic requirement. For example, a
Forth program might perform some calculations to generate fitted
polynomial coefficients, and we need some other Forth program to be
able to read such coefficients uncorrupted.) In order to do that, we
need MAX-FLOAT-DIGITS, as suggested by
ftp://ftp.taygeta.com/pub/Forth/Applications/ANS/Represent_21.txt.
The alternative is to define a word that prints "enough" characters to
recreate the original floating-point number, but I think the principle
of parsimony argues against that.
> There was a request to have REPRESENT produce strings for
> infinity and nan, but I couldn't see a good way to do that,
> given that u might be less than three. The presence of either
> is easy to detect.]
All other things being equal, it's best to try to minimize the burden
placed on application writers. While an application could in
principle contain its own logic to handle special values, u<3 in
REPRESENT is a pretty weird corner case, and it is surely sufficient
to say that the string "nan" or "inf" will be truncated in that case.
With u>3, blanks are appended. With that, a routine to handle all
values is easy to write, and could (should?) be added to the
rationale.
The best way to test a proposal is to try to write words that use it.
Something like this:
: .sign ( flag) if ." -" else ." +" then ;
: f.big ( r)
pad max-float-digits represent if
.sign ." ."
pad max-float-digits type
." e" 0 .r
else
over 0= ( inf) if dup .sign then
2drop pad max-float-digits type
then ;
Apart from the special handling for the sign of nan, this mostly works
on gforth.
0e0 0e0 f/ f.big +nan ok
1e0 0e0 f/ f.big +inf ok
Unfortunately, gforth 0.7 REPRESENT handles the sign of -inf itself:
-1e0 0e0 f/ pad max-float-digits represent
pad max-float-digits type -inf ok
Andrew.
Marcel Hendrix
> Here's draft 0.5.3 of the IEEE-FP proposal. It has been divided
> into two optional word sets, the "IEEE FLoating-Point" word set and the
> "IEEE Floating-Point Environment" word set.
Here is what strikes me as being changed.
I must have completely missed FREMAINDER before.
For exhaustive details see the original posting.
I've formulated the text provocatively in order to get responses.
-marcel
-- queries -----------------------------------------------------------
Value
String Data Type Constant? Meaning
------------------------------------------------------------------
IEEE-FP flag no IEEE and DPANS94 floating-point word
sets present
IEEE-FP-FORMAT d no in usual stack notation, the default
format has IEEE parameters ( emax p )
IEEE-FP-ENV flag no IEEE floating-point environment word
set present
------------------------------------------------------------------
-- number conversion changes -------------------------------------------
Interpretation converts to a finite, real number in the
default floating-point format, and nominally uses the
current rounding mode. An ambiguous condition exists if
conversion overflows, or if the syntax is not satisfied and
causes unsuccessful text interpretation.
[ I think this means that underflow and overflow ( which return -Inf,
+Inf ) should signal with GET-FSTATUS . Syntax errors do not signal
and ABORT. Signals are cleared on startup, COLD, BYE, ABORT, ABORT" -mhx]
-- changed words -------------------------------------------------------
D>F
( d -- ) ( F: -- r )
When d is too large, generate +/-Inf.
[ this can happen on a 64-bit system or on a 32-bit system with bin32
floats. Note that the required current rounding mode does not cover
the over/underflow case. The Standard does not specify D>F in that
case so iForth does as stated.
The same happens for the common S>F word. -mhx]
F>D
( F: r -- ) ( -- d )
When the integer part of r is not representable by a signed, double number,
or when it is a NaN or Inf, the following happens:
FORTH> +Inf F>D hex UD. 8000000000000000 ok
FORTH> -Inf F>D hex UD. 8000000000000000 ok
FORTH> +NaN F>D hex UD. 8000000000000000 ok
FORTH> -NaN F>D hex UD. 8000000000000000 ok
>FLOAT
( c-addr u -- [r: r s: true]|[false] )
The input string should represent a finite number in the range of the
default format. If it doesn't, FALSE is returned. This word cannot be
used to generate NaN or Inf (S" 1e2222222222" >FLOAT is not valid).
Rounds to nearest.
>IEEE-FLOAT
( c-addr u -- [r: r s: true]|[false] )
The differences with >FLOAT are that it
1. uses the current rounding mode,
2. raises exceptions on Overflow, Underflow, and Inexact,
3. recognizes text forms of Inf and NaN without changing
the fp exception status.
[ It guess it accepts 1e222222 as +Inf and sets overflow. -mhx]
REPRESENT
( F: r -- ) ( c-addr u -- n flag1 flag2 )
F.
( F: r -- )
FE.
( F: r -- )
FS.
( F: r -- )
IEEE specials are allowed and the current rounding mode
is used instead of "round to nearest".
SF!
( F: r -- ) ( sf-addr -- )
DF!
( F: r -- ) ( df-addr -- )
SF@
( sf-addr -- ) ( F: -- f )
DF@
( df-addr -- ) ( F: -- f )
Use the current rounding mode for conversion of real numbers
to a narrower format. NaN's are NaN's in any format.
F~
( F: r1 r2 r3 -- ) ( -- flag )
If r3 is a nan, flag is false.
-- new words -----------------------------------------------------------
+INF ( F: -- +Inf )
-INF ( F: -- -Inf )
+NAN ( F: -- +NaN )
-NAN ( F: -- -NaN )
FINITE? ( F: r -- ) ( -- [normal|denormal]? )
Test if r is a Normal or Denormal float.
See also: FNORMAL? FSUBNORMAL? FINFINITE? FNAN? FQUIET?
FNORMAL? ( F: r -- ) ( -- normal? )
Test if r is a Normal float.
See also: FINITE? FSUBNORMAL? FINFINITE? FNAN? FQUIET?
FSUBNORMAL? ( F: r -- ) ( -- denormal? )
Test if r is a Denormal float.
See also: FNORMAL? FINITE? FINFINITE? FNAN? FQUIET?
FINFINITE? ( F: r -- ) ( -- [+|-]Inf? )
Test if r is infinite.
See also: FNORMAL? FSUBNORMAL? FINITE? FNAN? FQUIET?
FNAN? ( F: r -- ) ( -- nan? )
Test if r is NaN (SNaN or QNaN).
See also: FINITE? FNORMAL? FSUBNORMAL? FINFINITE? FQUIET?
F*+ ( F: r1 r2 r3 -- [r2*r3]+r1 )
Return the product of r3 and r2, added to r1.
FSIGNBIT ( F: r -- ) ( -- minus? )
Returns the sign of r.
FCOPYSIGN ( F: r1 r2 -- r3 )
The output r3 is r1 with its sign bit replaced by that of r2.
FCEIL ( F: r1 -- r2 )
Returns the smallest fp integer larger than r1.
FNEARBYINT ( F: r1 -- r2 )
FNEARBYINT performs the function of whichever of FLOOR,
FTRUNC, FCEIL or FROUND corresponds to the current rounding
mode. This word corresponds to the IEEE required operation:
roundToIntegralExact.
FNEXTUP ( F: r1 -- r2 )
When r1 is a nonzero real number, FNEXTUP returns the next
affinely extended real in the default format that compares
larger than r1. See IEEE 5.3.1, "General operations" for the
behavior when r1 is an IEEE special.
FNEXTDOWN ( F: r1 -- r2 )
When r1 is a nonzero real number, FNEXTDOWN returns the next
affinely extended real in the default format that compares
smaller than r1. See IEEE 5.3.1, "General operations" for the
behavior when r1 is an IEEE special.
FSCALBN ( F: r -- r*2^n ) ( n -- )
The output is efficiently scaled by 2^n. See IEEE 754-2008
5.3.3, "logBFormat operations".
FLOGB ( F: r -- e )
Leave the radix-two exponent e of the fp representation as an
fp integer. If r is subnormal, the exponent is computed as if
r were normalized, with e < emin. See IEEE 754-2008 5.3.3,
"logBFormat operations" for treatment of IEEE specials.
FREMAINDER
( F: x y -- r q )
When y is not 0, the remainder r = fremainder(x, y) is defined
for finite x and y regardless of the current rounding mode by
the exact mathematical relation r = x - y * q, where q is the
integer nearest the exact number x/y, with roundToIntegralTiesToEven.
If r = 0, its sign shall be that of x, and fremainder(x, inf)
is x for finite x. See IEEE 754-2008 5.3.1, "General
operations".
-- exceptions ---------------------------------------------------------
The fp status flags correspond to the following distinct, nonzero,
fp flag masks:
FDIVBYZERO
FINEXACT
FINVALID
FOVERFLOW
FUNDERFLOW
GET-FSTATUS
David N. Williams
> David N. Williams wrote:
>> [...]
>> REPRESENT ( f: r s: c-addr u -- n flag1 flag2 )
>>
>> The DPANS94 specification is extended to include IEEE
>> specials. Instead of "round to nearest", the decimal mantissa
>> string nominally shall use the current rounding mode instead
>> of "round to nearest".
>>
>> If flag2 is true, r was a finite number; if false,
>> either r was infinity and n = 0, or r was a nan and n is an
>> nonzero, implementation-defined number. If flag1 is true,
>> then the sign bit of r was one; otherwise the sign bit was
>> zero.
>>
>> [**RATIONALE
>> The IEEE extension of REPRESENT aims to change the DPANS94
>> specification as little as possible.
>>
>> ...
>>
>> [**DPANS94 does not embed the sign in the mantissa string,
>> contrary to impressions in c.l.f.
>
> IIRC the discussions involving embedded sign pertained
> only to non-number strings i.e. when flag2 = false.
Okay.
>> There was a request to have REPRESENT produce strings for
>> infinity and nan, but I couldn't see a good way to do that,
>> given that u might be less than three.
>> ...
>
> This conclusion appears based on a mis-reading of the Standard.
> Nans/infs aren't numbers, don't have a significand, and can't be
> rounded to "u ... significant digits". There is nothing in the spec
> to support a view that 'u' applies to non-numbers.
The wording could certainly be better, not to mention it's
garbled. I'll try to fix it in my reply to Andrew.
> If you're going to require implementers to make changes to
> REPRESENT anyway, why not do the job properly. The spec
> for it already exists:
> ftp://ftp.taygeta.com/pub/Forth/Applications/ANS/Represent_21.txt
>
> As it was intended for general ANS use, it doesn't yet specify
> strings for nan/inf or the values for n2, flag1. Signed-zero
> is allowed.
I'll have to think about that...
-- David
Ed
> Ed wrote:
> > David N. Williams wrote:
> >> [...]
> >> infinity and nan, but I couldn't see a good way to do that,
> >> given that u might be less than three.
> >> ...
> >
> > This conclusion appears based on a mis-reading of the Standard.
> > Nans/infs aren't numbers, don't have a significand, and can't be
> > rounded to "u ... significant digits". There is nothing in the spec
> > to support a view that 'u' applies to non-numbers.
>
> The wording could certainly be better, not to mention it's
> garbled. I'll try to fix it in my reply to Andrew.
I suspect I wasn't clear. I'm not concerned with the wording of
your proposal. Rather the underlying assumption - namely that
REPRESENT places a string of "u" characters in the buffer
when flag2 = false.
This is a common interpretation of the Standard definition,
and indeed, some REPRESENT's have been implemented
that way. What I'm suggesting is that this is a) not borne
out by the text, and b) unhelpful.
A close reading of the Standard text shows that "u" is only
used in reference to "significant digits" and numbers - never
as a string length. The paragraph that relates to when flag2
= false, never mentions "u" at all. Readers simply assumed
that the resulting string would be limited to "u characters".
My spec isn't so much a change to the Standard definition
- but another interpretation of it (along with some necessary
extensions and clarification).
That's the background and context.
Ed
> ...
>
> Unfortunately, gforth 0.7 REPRESENT handles the sign of -inf itself:
>
> -1e0 0e0 f/ pad max-float-digits represent
> pad max-float-digits type -inf ok
As it should.
There are good reasons to have the sign embedded in the
nan/inf strings.
- Portable ANS apps demand it. They have no idea what's
in the string - they just display it. Flag1 is undefined.
- There's no advantage in handling the sign explicitly.
It's more work for the app, and non-portable.
- Apps can readily strip the sign out of the string should
it ever be needed.
- Flag1 is available for other uses.
Ed
> ...
>
> >FLOAT
> ( c-addr u -- [r: r s: true]|[false] )
> The input string should represent a finite number in the range of the
> default format. If it doesn't, FALSE is returned. This word cannot be
> used to generate NaN or Inf (S" 1e2222222222" >FLOAT is not valid).
> Rounds to nearest.
Why not the current rounding mode? It's easier to implement
and most likely you won't notice the difference anyway.
> -- number conversion changes -------------------------------------------
>
> Interpretation converts to a finite, real number in the
> default floating-point format, and nominally uses the
> current rounding mode. An ambiguous condition exists if
> conversion overflows, or if the syntax is not satisfied and
> causes unsuccessful text interpretation.
>
> [ I think this means that underflow and overflow ( which return -Inf,
> +Inf ) should signal with GET-FSTATUS . Syntax errors do not signal
> and ABORT. Signals are cleared on startup, COLD, BYE, ABORT, ABORT" -mhx]
I take it that you want the interpreter to accept numeric overflow
and not ABORT.
I'm curious as to where you intend to use this feature - surely
not in source code compilation or for testing apps? Wouldn't
it be as confusing and meaningless as using integer overflow
for compilation or testing?
I'll accept that underflows might quietly convert to zero - but
not to -Inf :)
Below is my take on what should happen when the interpreter
encounters a numeric "ambiguous condition". I had prepared
this as a response/query to David, but as you've raised the topic ...
> 7.2 Decimal input
> -----------------
> ...
> DPANS94 12.3.7 specifies that the number-conversion algorithm
> used by the text interpreter is to be extended to recognize
> floating-point numbers when the base is decimal, with an
> implication that the behavior on failure is to be governed by
> the introductory paragraphs in DPANS94 3.4, "The Forth
> interpreter". This document slightly modifies the syntax
> specification, and is more explicit about failure.
>
> ...
> An ambiguous condition exists if
> conversion overflows, or if the syntax is not satisfied and
> causes unsuccessful text intepretation, in which case behavior
> shall be governed by DPANS94 3.4.4, "Possible actions on an
> ambiguous condition".
>
> [**QUOTE
> 3.4.4 Possible actions on an ambiguous condition
>
> When an ambiguous condition exists, a system may take one or
> more of the following actions:
>
> * ignore and continue;
> * display a message;
> * execute a particular word;
> * set interpretation state and begin text interpretation;
> * take other implementation-defined actions;
> * take implementation-dependent actions.
>
> The response to a particular ambiguous condition need not be the
> same under all circumstances.
> ]
Reading the relevant sections suggests that not all these options
are necessarily available. The list encompasses possible actions
for all ambiguous conditions - not just those resulting from
failed interpretation.
A common view is that it is permissible to ignore numeric
overflow in the interpreter. Maybe not.
The text interpreter is bound up with the requirements of QUIT :
3.4 The Forth text interpreter
...
Text interpretation (see 6.1.1360 EVALUATE and 6.1.2050 QUIT)
shall repeat the following steps until either the parse area is empty
or an ambiguous condition exists:
...
6.1.2050 QUIT
...
Repeat the following:
Accept a line from the input source ... and interpret.
Display the implementation-defined system prompt if in
interpretation state, all processing has been completed,
and no ambiguous condition exists.
The last paragraph suggests that should an ambiguous condition
occur during interpretation, one is not permitted to say it's "OK"
when interpretation state is re-entered. That seems to rule out
the "ignore and continue" option.
David N. Williams
> David N. Williams <will...@umich.edu> wrote:
>
>> REPRESENT ( f: r s: c-addr u -- n flag1 flag2 )
>
>> The DPANS94 specification is extended to include IEEE
>> specials. Instead of "round to nearest", the decimal mantissa
>
> "significand", not "mantissa". It's not a mantissa.
Oops!
>> [...]
>
> This is rather underspecified. We need to make it explicit that this
> is the binary to decimal conversion routine that can be used to
> satisfy the requirement of exact conversion: conversion back to binary
> recovers the original representation except that NaNs may be converted
> to a canonical NaN. (This is a basic requirement. For example, a
> Forth program might perform some calculations to generate fitted
> polynomial coefficients, and we need some other Forth program to be
> able to read such coefficients uncorrupted.) In order to do that, we
> need MAX-FLOAT-DIGITS, as suggested by
> ftp://ftp.taygeta.com/pub/Forth/Applications/ANS/Represent_21.txt.
> The alternative is to define a word that prints "enough" characters to
> recreate the original floating-point number, but I think the principle
> of parsimony argues against that.
I agree that we need something like MAX-FLOAT-DIGITS, and have
been working on a revision of REPRESENT. The IEEE spec is
dense. I have to go out now, but hope to post it tomorrow.
Neither my ppc nor my intel Mac embed the sign for -inf. For
ppc, I get
----------
[jost:~/forth/IEEE-FP] dnwills% gforth
Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
17 constant max-float-digits ok
-1e0 0e0 f/ pad max-float-digits represent ok
pad max-float-digits type inf ok
-----------
-- David
Andrew Haley
> As it should.
Perhaps so. It seems illogical to embed the sign in "-inf" but not in
any other values, but I accept that it may slightly simplify users of
REPRESENT. I think it makes more sense (and therefore will be easier
to specify) if the sign of inf is returned in a flag just like the
sign of any other value, but I understand your argument.
Andrew.
Andrew Haley
> Marcel Hendrix wrote:
> > ...
> >
> > >FLOAT
> > ( c-addr u -- [r: r s: true]|[false] )
> > The input string should represent a finite number in the range of the
> > default format. If it doesn't, FALSE is returned. This word cannot be
> > used to generate NaN or Inf (S" 1e2222222222" >FLOAT is not valid).
> > Rounds to nearest.
> Why not the current rounding mode?
ANS compatibility.
> > -- number conversion changes -------------------------------------------
> >
> > Interpretation converts to a finite, real number in the
> > default floating-point format, and nominally uses the
> > current rounding mode. An ambiguous condition exists if
> > conversion overflows, or if the syntax is not satisfied and
> > causes unsuccessful text interpretation.
> >
> > [ I think this means that underflow and overflow ( which return
> > -Inf, +Inf ) should signal with GET-FSTATUS . Syntax errors do
> > not signal and ABORT. Signals are cleared on startup, COLD, BYE,
> > ABORT, ABORT" -mhx]
Good point: this needs to be clarified. It makes sense to clear FP
exceptions in these cases.
> I take it that you want the interpreter to accept numeric overflow
> and not ABORT.
This specification doesn't say either way. An interpreter is free to
ABORT if the conversion overflows.
> Reading the relevant sections suggests that not all these options
> are necessarily available. The list encompasses possible actions
> for all ambiguous conditions - not just those resulting from failed
> interpretation.
> A common view is that it is permissible to ignore numeric overflow
> in the interpreter. Maybe not.
That's the view of the chair of the TC.
> The text interpreter is bound up with the requirements of QUIT :
> 3.4 The Forth text interpreter
> ...
> Text interpretation (see 6.1.1360 EVALUATE and 6.1.2050 QUIT)
> shall repeat the following steps until either the parse area is empty
> or an ambiguous condition exists:
> ...
> 6.1.2050 QUIT
> ...
> Repeat the following:
> Accept a line from the input source ... and interpret.
> Display the implementation-defined system prompt if in
> interpretation state, all processing has been completed,
> and no ambiguous condition exists.
> The last paragraph suggests that should an ambiguous condition
> occur during interpretation, one is not permitted to say it's "OK"
> when interpretation state is re-entered.
An ambiguous condition, by definition, is:
A circumstance for which this Standard does not prescribe a
specific behavior for Forth systems and programs.
Andrew.
Andrew Haley
> >
> > Unfortunately, gforth 0.7 REPRESENT handles the sign of -inf itself:
> >
> > -1e0 0e0 f/ pad max-float-digits represent
> > pad max-float-digits type -inf ok
> Neither my ppc nor my intel Mac embed the sign for -inf. For
> ppc, I get
> ----------
> [jost:~/forth/IEEE-FP] dnwills% gforth
> Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
> Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
> Type `bye' to exit
> 17 constant max-float-digits ok
> -1e0 0e0 f/ pad max-float-digits represent ok
> pad max-float-digits type inf ok
That may be due to C library differences in the host OS.
I guessed that we'd find a ton of bugs and inconsistencies in existing
Forth systems as part of the process of standardizing IEEE FP. This
is going well, I think.
Andrew.
Marcel Hendrix
> Marcel Hendrix wrote:
...
>> >FLOAT
>> ( c-addr u -- [r: r s: true]|[false] )
>> The input string should represent a finite number in the range of the
>> default format. If it doesn't, FALSE is returned. This word cannot be
>> used to generate NaN or Inf (S" 1e2222222222" >FLOAT is not valid).
>> Rounds to nearest.
> Why not the current rounding mode? It's easier to implement
> and most likely you won't notice the difference anyway.
Compatibility. Current >FLOAT uses round-to-nearest.
You may have noticed the difference in the 18th digit for the recent
quadratic.fs thread. Some Forths (e.g. Win32Forth, iForth) properly round
0.66666... to 0.66...7, others don't (they chop).
[..]
>> [ I think this means that underflow and overflow ( which return -Inf,
>> +Inf ) should signal with GET-FSTATUS . Syntax errors do not signal
>> and ABORT. Signals are cleared on startup, COLD, BYE, ABORT, ABORT" -mhx]
> I take it that you want the interpreter to accept numeric overflow
> and not ABORT.
All the Forths I know return 0e for 1e-22222 and +Inf for 1e+222222. None
abort. So it's common practice.
> I'm curious as to where you intend to use this feature - surely
> not in source code compilation or for testing apps? Wouldn't
> it be as confusing and meaningless as using integer overflow
> for compilation or testing?
For all practical purposes 1e5000 *is* +Inf, and 1e-5000 *is* 0. These
are not errors in an engineering sense.
Some well-known programs (e.g. Matlab) generate NaNs and Infs in their
file output and accept them as input (e.g. for plotting), without extra
processing or testing and with very useful results. It's a benefit of
IEEE-FP that I'll gladly use.
> I'll accept that underflows might quietly convert to zero - but
> not to -Inf :)
Touchez!
> Below is my take on what should happen when the interpreter
> encounters a numeric "ambiguous condition". I had prepared
> this as a response/query to David, but as you've raised the topic ...
[..]
> The text interpreter is bound up with the requirements of QUIT :
[..]
> The last paragraph suggests that should an ambiguous condition
> occur during interpretation, one is not permitted to say it's "OK"
> when interpretation state is re-entered. That seems to rule out
> the "ignore and continue" option.
Nice try.
-marcel
David N. Williams
> David N. Williams <will...@umich.edu> wrote:
>
>> REPRESENT ( f: r s: c-addr u -- n flag1 flag2 )
> This is rather underspecified.
Sorry for the delay -- other things going on...
Here's a rewrite.
But first there's an extra environmental query,
MAX-FLOAT-DIGITS.
Value
String Data Type Constant? Meaning
------------------------------------------------------------------
IEEE-FP flag no IEEE and DPANS94 floating-point word
sets present
IEEE-FP-FORMAT d yes in usual stack notation, the default
format has IEEE parameters ( emax p )
MAX-FLOAT-DIGITS +n yes largest number of usable digits
available from REPRESENT
IEEE-FP-ENV flag no IEEE floating-point environment word
set present
------------------------------------------------------------------
The number +n is what I understand to be the IEEE number "M" in
Section 5.12.2, "External decimal character sequences
representing finite numbers"; which IIUC is the minimum number
of decimal digits necessary to provide reproducibility under
binary -> decimal -> binary conversion, with "correct rounding"
under roundTiesToEven in both directions. Actually it's also
supposed to work with rountTiesToAway, but we don't implement
that.
This number is required by IEEE to be
M = 1 + ceiling( p * log_10(2) ),
so there's no need for the query, unless we want to allow for
implementations that need more digits. A bit murky to me...
The following is a nan/inf-sign nonembedding version.
---------
REPRESENT ( f: r s: c-addr u -- n flag1 flag2 )
When flag2 is true, the floating-point datum r was a finite
number; when false, it was a nan or inifinity. In any case,
flag1 is true if and only if the sign bit of r was unity.
When r is a finite number, place the character-string
representation of its significand at c-addr, and return the
decimal-base exponent as n. The character string shall
consist of the u most significant digits of the significand
represented as a decimal fraction with the implied decimal
point to the left of the first digit, and the first digit zero
only if all digits are zero. The significand should be
correctly rounded to u digits; n is adjusted, if necessary, to
correspond to the rounded magnitude of the significand.
If u is greater than or equal to the number of digits M
returned by the MAX-FLOAT-DIGITS environmental query, and the
rounding mode is roundTiesToEven in both directions,
conversion back to binary with the algorithm of >FLOAT or the
text interpreter shall reproduce r. The string shall be
padded with u - M trailing zeroes if u is larger than M.
An ambiguous condition exists if the value of BASE is not
decimal ten.
When r is a nan or infinity, the character string shall be one
of the three-character options for <nan> or <inf>,
respectively, recognized by >FLOAT. If u is less than three,
the string is truncated; if more than three, it is padded with
trailing blanks. When r is infinity, the value n returned is
zero; when r is a nan, it is a nonzero, implementation-defined
number.
---------
[**RATIONALE
The implementation-defined value of n for nans could be used in
a future proposal to encode information about the signaling bit
and load.
The following example uses REPRESENT to define a word that
prints decimal floating-point output with the maximum usable
number of digits.
s" MAX-FLOAT-DIGITS ENVIRONMENT? DROP CONSTANT MAX-FLOAT-DIGITS
: .SIGN ( flag -- ) IF ." -" ELSE ." +" THEN ;
: F.BIG ( r -- )
PAD MAX-FLOAT-DIGITS REPRESENT IF
.SIGN ." ."
PAD MAX-FLOAT-DIGITS TYPE
." E" 0 .R
ELSE
OVER 0= ( INF) IF DUP .SIGN THEN
2DROP PAD MAX-FLOAT-DIGITS TYPE
THEN ;
]
-- David
Ed
> ...
> ppc, I get
Neither does Windows version of gforth.
It's nothing that gforth couldn't fix if it wanted to. The same
goes for any forth compiler built on C libraries.
Ed
"David N. Williams" <will...@umich.edu> wrote in message news:h6kfhc$j8p$1...@news.eternal-september.org...
Let's hope this is only the first revision and better one's
will follow :)
In the meantime, try this out on your forth:
2 SET-PRECISION ok
467.8E FE. 470.E0 ok
1E 0E F/ FE. +INF ok
Ed
> "Ed" <nos...@invalid.com> writes Re: IEEE-FP 0.5.3
>
> > Marcel Hendrix wrote:
> ...
> >> >FLOAT
> >> ( c-addr u -- [r: r s: true]|[false] )
> >> The input string should represent a finite number in the range of the
> >> default format. If it doesn't, FALSE is returned. This word cannot be
> >> used to generate NaN or Inf (S" 1e2222222222" >FLOAT is not valid).
> >> Rounds to nearest.
>
> > Why not the current rounding mode? It's easier to implement
> > and most likely you won't notice the difference anyway.
>
> Compatibility. Current >FLOAT uses round-to-nearest.
I see nothing in '94 that says >FLOAT uses round-to-nearest.
Given >FLOAT (or much of it) is likely to be used in the
core of >IEEE-FLOAT, it would be logical/easier if both
employed the same rounding mode.
> You may have noticed the difference in the 18th digit for the recent
> quadratic.fs thread. Some Forths (e.g. Win32Forth, iForth) properly round
> 0.66666... to 0.66...7, others don't (they chop).
'94 says nothing about accuracy. Nor does it dictate rounding of
the underlying math. Consequently what appears in the last digit
of an f/p number is anyone's guess!
> [..]
> >> [ I think this means that underflow and overflow ( which return -Inf,
> >> +Inf ) should signal with GET-FSTATUS . Syntax errors do not signal
> >> and ABORT. Signals are cleared on startup, COLD, BYE, ABORT, ABORT" -mhx]
>
> > I take it that you want the interpreter to accept numeric overflow
> > and not ABORT.
>
> All the Forths I know return 0e for 1e-22222 and +Inf for 1e+222222. None
> abort. So it's common practice.
All the forths I know can't detect integer overflow. That doesn't
make it right.
BTW, not all IEEE-based forths ignore errors:
Forth-94
80387 15-digit floating point (common stack)
1e+222222
Error: "1e+222222" is undefined
When I need Inf , I enter it directly:
inf ok
f. +INF ok
I don't rely on a compiler that can't catch errors to compile
my Inf or Nan's. I use the dictionary.
> > I'm curious as to where you intend to use this feature - surely
> > not in source code compilation or for testing apps? Wouldn't
> > it be as confusing and meaningless as using integer overflow
> > for compilation or testing?
>
> For all practical purposes 1e5000 *is* +Inf, and 1e-5000 *is* 0. These
> are not errors in an engineering sense.
A forth compiler/text interpreter isn't an engineering application.
> Some well-known programs (e.g. Matlab) generate NaNs and Infs in their
> file output and accept them as input (e.g. for plotting), without extra
> processing or testing and with very useful results. It's a benefit of
> IEEE-FP that I'll gladly use.
This describes an application. An application may do whatever
it likes with numbers.
The role of the forth interpreter is to compile and debug apps.
Consequently its emphasis is error detection.
If you wish to turn your forth into an interactive matlab
application, that's fine. However there must be better ways
of doing that than by breaking the interpreter so that it can't
catch errors.
> > The text interpreter is bound up with the requirements of QUIT :
> [..]
> > The last paragraph suggests that should an ambiguous condition
> > occur during interpretation, one is not permitted to say it's "OK"
> > when interpretation state is re-entered. That seems to rule out
> > the "ignore and continue" option.
>
> Nice try.
'94 simply asserts what is a fact. Namely, that there is never
a reason for the text interpreter to ignore errors.
Ed
> Ed <nos...@invalid.com> wrote:
> ...
> > Reading the relevant sections suggests that not all these options
> > are necessarily available. The list encompasses possible actions
> > for all ambiguous conditions - not just those resulting from failed
> > interpretation.
>
> > A common view is that it is permissible to ignore numeric overflow
> > in the interpreter. Maybe not.
>
> That's the view of the chair of the TC.
The Standard text suggests otherwise.
> ...
> An ambiguous condition, by definition, is:
>
> A circumstance for which this Standard does not prescribe a
> specific behavior for Forth systems and programs.
The requirements of the text interpreter are described elsewhere.
Andrew Haley
> Andrew Haley wrote:
> > Ed <nos...@invalid.com> wrote:
> > ...
> > > Reading the relevant sections suggests that not all these options
> > > are necessarily available. The list encompasses possible actions
> > > for all ambiguous conditions - not just those resulting from failed
> > > interpretation.
> >
> > > A common view is that it is permissible to ignore numeric overflow
> > > in the interpreter. Maybe not.
> >
> > That's the view of the chair of the TC.
> The Standard text suggests otherwise.
Maybe. I don't interpret it that way, and I'm sure the TC didn't
intend it to be read that way.
> > ...
> > An ambiguous condition, by definition, is:
> >
> > A circumstance for which this Standard does not prescribe a
> > specific behavior for Forth systems and programs.
> The requirements of the text interpreter are described elsewhere.
Well, you're interpreting the language of the standard in a very
particular way. And it's a way that greatly restricts
implementations: for example, division by zero is an ambiguous
condition, but the TC had no intention of insisting that the text
interpreter should abort when that happens.
Andrew.
David N. Williams
The difference for users seems pretty slight. To me it seems
better to give flag1 just one meaning -- the sign bit flag.
Then it seems natural to treat the sign for the string uniformly
as well -- never embedded.
The DPANS94 rationale does suggest an embedded sign, but seems
pretty loose:
-----------------------
A.12.6.1.2143 REPRESENT
This word provides a primitive for floating-point display. Some
floating-point formats, including those specified by IEEE-754,
allow representations of numbers outside of an implementation-
defined range. These include plus and minus infinities,
denormalized numbers, and others. In these cases we expect that
REPRESENT will usually be implemented to return appropriate
character strings, such as +infinity or nan, possibly truncated.
------------------------
My preference is nonembedded, but it's just that, a preference.
-- David
Elizabeth D Rather
> Ed <nos...@invalid.com> wrote:
>> Andrew Haley wrote:
>>> Ed <nos...@invalid.com> wrote:
...
>>>
>>> A circumstance for which this Standard does not prescribe a
>>> specific behavior for Forth systems and programs.
>
>> The requirements of the text interpreter are described elsewhere.
>
> Well, you're interpreting the language of the standard in a very
> particular way. And it's a way that greatly restricts
> implementations: for example, division by zero is an ambiguous
> condition, but the TC had no intention of insisting that the text
> interpreter should abort when that happens.
IMO library routines are entitled to expect reasonable input. And the
responsibility for getting reasonable input from the outside world
(whether devices or human users) is properly a function of the
application. Only the application can possibly know what's really
"reasonable", because only the application knows what's going to be done
with the numbers that are entered. It's not just a matter of whether
they're within the range of the number of bits you have; the
application's concept of "reasonable" is going to imply a certain value
range, scale, etc., for every number. That should be checked for *by
the application* at the point at which numbers enter the program (from
device, keyboard, etc.). Thereafter, internal code should be able to
assume reasonable input.
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
Marcel Hendrix
> Marcel Hendrix wrote:
>> "Ed" <nos...@invalid.com> writes Re: IEEE-FP 0.5.3
>> > Marcel Hendrix wrote:
...
>> >> >FLOAT
[..]
>> >> Rounds to nearest.
>> > Why not the current rounding mode? It's easier to implement
>> > and most likely you won't notice the difference anyway.
>> Compatibility. Current >FLOAT uses round-to-nearest.
> I see nothing in '94 that says >FLOAT uses round-to-nearest.
You're right! That's indeed simplyfing matters. The required
current rounding in >IEEE-FLOAT is still a technical problem though.
>> You may have noticed the difference in the 18th digit for the recent
>> quadratic.fs thread. Some Forths (e.g. Win32Forth, iForth) properly round
>> 0.66666... to 0.66...7, others don't (they chop).
> '94 says nothing about accuracy. Nor does it dictate rounding of
> the underlying math. Consequently what appears in the last digit
> of an f/p number is anyone's guess!
The context of my remark was your statement that "most likely you
won't notice the difference anyway." I just gave an example where you
will notice the difference. Of course, for engineering purposes it
is a non-problem, but you don't allow me to use that argument :-)
If David gets his way, and engineering problems don't count, the testsuite
will probably be checking proper rounding of the 20th digit :-)
[..]
>> All the Forths I know return 0e for 1e-22222 and +Inf for 1e+222222. None
>> abort. So it's common practice.
> All the forths I know can't detect integer overflow. That doesn't
> make it right.
If it's right or not is something else entirely. I could give you an opinion.
[..]
>> > I'm curious as to where you intend to use this feature - surely
>> > not in source code compilation or for testing apps? Wouldn't
>> > it be as confusing and meaningless as using integer overflow
>> > for compilation or testing?
>> For all practical purposes 1e5000 *is* +Inf, and 1e-5000 *is* 0. These
>> are not errors in an engineering sense.
> A forth compiler/text interpreter isn't an engineering application.
I assumed your "intend to use" was wrt applications in which I would use
interpretation or >FLOAT. The Forth compiler/interpreter is not a purpose
in itself.
[..QUIT spec..]
6.1.2050 QUIT CORE
( -- ) ( R: i*x -- )
Empty the return stack, store zero in SOURCE-ID if it is present, make
the user input device the input source, and enter interpretation state.
Do not display a message. Repeat the following:
- Accept a line from the input source into the input buffer, set >IN
to zero, and interpret.
- Display the implementation-defined system prompt if in
interpretation state, all processing has been completed, and no
ambiguous condition exists.
See: 3.4 The Forth text interpreter.
> '94 simply asserts what is a fact. Namely, that there is never
> a reason for the text interpreter to ignore errors.
"Errors" would validate your claim, but what it actually says is
"ambiguous condition." When checking what should happen "when an
ambiguous condition exists" I find that almost anything is
allowed (including ABORT), 3.4.4 Possible actions on an ambiguous
condition, but nothing is prescribed.
-marcel
Ed
> ...
> "Errors" would validate your claim, but what it actually says is
> "ambiguous condition." When checking what should happen "when an
> ambiguous condition exists" I find that almost anything is
> allowed (including ABORT), 3.4.4 Possible actions on an ambiguous
> condition, but nothing is prescribed.
What Forth-94 calls "ambiguous conditions" were previously
called "error conditions" in Forth-79 and 83.
My interpretation is that "ambiguous condition" was a more
general term that could encompass a multitude of sins - all
the way from 'fatal error' to 'ignore and continue'.
Of interest is that only 94' QUIT has the 'ambiguous condition'
clause. The TC obviously had something in mind but I can't
fathom what. Did they mean a) ambiguous condition from the
text interpreter, b) all ambiguous conditions, or c) exceptions
thrown by ambiguous conditions, d) something else?
David N. Williams
just try to hit a few high spots.
First of all, I want to thank Marcel for his "provocative" text
summary, which I found very helpful and not provocative at all
in a negative sense.
Some general issues.
1. DPANS94 rounding vs. IEEE current rounding.
In DPANS94 there are two kinds of rounding, not involving round
to nearest integer: implementation-defined and "round to
nearest". IEEE specifies the current rounding mode in
essentially all of those cases.
The attitude I intended in the last draft, which maybe wasn't so
clearly expressed, was that IEEE current rounding is compatible
with the DPANS94 round to nearest cases. The point being that
the default IEEE mode is roundTiesToEven, and formerly portable
programs will still use that, since they won't know about any
words that change the rounding mode.
For the implementation-defined cases, I think of IEEE-FP as
specifying an implementation. Insofar as the specification is
not unrealistic for implementors, that seems okay to me,
especially if there are weasel words like "should" in the right
places. Or am I wrong?
2. Accuracy and "correct rounding".
DPANS94 doesn't specify accuracy, and IEEE wants correct
rounding nearly everywhere. This is the IEEE definition of
correct rounding:
2.1.12 correct rounding: This standard�s method of converting
an infinitely precise result to a floating-point number, as
determined by the applicable rounding direction. A
floating-point number so obtained is said to be correctly
rounded.
I find IEEE prose turgid on this issue. For some things, like
binary/decimal conversion, they seem to want to make it a
"shall", maybe know that's impractical, but can't bring
themselves to say "should". Maybe a very close reading would
belie that interpretation, but it makes my head swim.
And what's the practical effect of current rounding, when
correct rounding is a pipe dream because of unachievaable
accuracy?
That's why I sometimes used the weasel terminology "nominally
shall" for current rounding cases.
The problem I have is that there is a state of the art, which
should be taken into account, but I'm not expert enough to know
what it is.
In any case, it's an important issue whether "shall", "should",
and "nominally shall" are correctly applied in the proposal, and
whether there's even a need for something like "nominally shall".
3. Text interpretation and ambiguous conditions.
Humn, guess I'll try to respond separately about this.
-- David
Andrew Haley
> DPANS94 doesn't specify accuracy, and IEEE wants correct
> rounding nearly everywhere. This is the IEEE definition of
> correct rounding:
> 2.1.12 correct rounding: This standard?s method of converting an
> infinitely precise result to a floating-point number, as
> determined by the applicable rounding direction. A
> floating-point number so obtained is said to be correctly
> rounded.
> I find IEEE prose turgid on this issue. For some things, like
> binary/decimal conversion, they seem to want to make it a "shall",
> maybe know that's impractical, but can't bring themselves to say
> "should".
I don't think that correct rounding of binary <-> decimal conversion
is impractical at all. I think it's perfectly doable, and that a
specimen implementation should accompany any IEEE ANS Forth proposal.
It's particularly important for floating-point literals in programs.
> And what's the practical effect of current rounding, when correct
> rounding is a pipe dream because of unachievaable accuracy?
In the case of the core arithmetic operations and binary/decimal
conversions, there is no insurmountable barrier to getting correctly
rounded results. This is the part that it's most important to get
right, because it determines the reproducibility (and therefore
predictability) of floating-point arithmetic.
Andrew.
David N. Williams
> David N. Williams <will...@umich.edu> wrote:
>> DPANS94 doesn't specify accuracy, and IEEE wants correct
>> rounding nearly everywhere. This is the IEEE definition of
>> correct rounding:
>
>> 2.1.12 correct rounding: This standard?s method of converting an
>> infinitely precise result to a floating-point number, as
>> determined by the applicable rounding direction. A
>> floating-point number so obtained is said to be correctly
>> rounded.
>
>> I find IEEE prose turgid on this issue. For some things, like
>> binary/decimal conversion, they seem to want to make it a "shall",
>> maybe know that's impractical, but can't bring themselves to say
>> "should".
>
> I don't think that correct rounding of binary <-> decimal conversion
> is impractical at all. I think it's perfectly doable, and that a
> specimen implementation should accompany any IEEE ANS Forth proposal.
> It's particularly important for floating-point literals in programs.
Okay, so let's make that a "shall" instead of a "nominal shall",
and expect a specimen implementation to emerge.
>> And what's the practical effect of current rounding, when correct
>> rounding is a pipe dream because of unachievaable accuracy?
>
> In the case of the core arithmetic operations and binary/decimal
> conversions, there is no insurmountable barrier to getting correctly
> rounded results. This is the part that it's most important to get
> right, because it determines the reproducibility (and therefore
> predictability) of floating-point arithmetic.
I wasn't in much doubt about core arithmetic, not because of my
own knowledge, but just from assertions I've read. I haven't
read any assertions like that for all of the transcendentals.
IEEE calls them "recommended correctly rounded functions". The
"recommended" seems to apply to the presence of the functions,
not to their being correctly rounded, so that's confusing.
-- David
Ed
Let's hope not, for the alternative would be disturbing.
I have no intention of implementing an IEEE REPRESENT that
is broken (in any respect). Only the foolish knowingly repeat
mistakes.
Andrew Haley
> Andrew Haley wrote:
> > David N. Williams <will...@umich.edu> wrote:
> >> DPANS94 doesn't specify accuracy, and IEEE wants correct
> >> rounding nearly everywhere. This is the IEEE definition of
> >> correct rounding:
> >
> >> 2.1.12 correct rounding: This standard?s method of converting an
> >> infinitely precise result to a floating-point number, as
> >> determined by the applicable rounding direction. A
> >> floating-point number so obtained is said to be correctly
> >> rounded.
> >
> >> I find IEEE prose turgid on this issue. For some things, like
> >> binary/decimal conversion, they seem to want to make it a "shall",
> >> maybe know that's impractical, but can't bring themselves to say
> >> "should".
> >
> > I don't think that correct rounding of binary <-> decimal conversion
> > is impractical at all. I think it's perfectly doable, and that a
> > specimen implementation should accompany any IEEE ANS Forth proposal.
> > It's particularly important for floating-point literals in programs.
> Okay, so let's make that a "shall" instead of a "nominal shall",
> and expect a specimen implementation to emerge.
Right. If the implementation is horrible, then we can reconsider. An
implementation must accompany the proposal anyway, and it's the best
way to do a sanity check.
> >> And what's the practical effect of current rounding, when correct
> >> rounding is a pipe dream because of unachievable accuracy?
> >
> > In the case of the core arithmetic operations and binary/decimal
> > conversions, there is no insurmountable barrier to getting correctly
> > rounded results. This is the part that it's most important to get
> > right, because it determines the reproducibility (and therefore
> > predictability) of floating-point arithmetic.
> I wasn't in much doubt about core arithmetic, not because of my
> own knowledge, but just from assertions I've read. I haven't
> read any assertions like that for all of the transcendentals.
> IEEE calls them "recommended correctly rounded functions". The
> "recommended" seems to apply to the presence of the functions,
> not to their being correctly rounded, so that's confusing.
I wasn't suggesting correctly rounded transcendentals. The state of
the art makes them unsuitable for real-time applications, and I've
done enough robotics in Forth to know that predictable execution time
is vital for trig functions. Imagine a robot arm whirling round and
occasionally juddering because some trig routine occasionally takes
ten times as long as usual in order to ensure least bit accuracy.
Andrew.
David N. Williams
>> > [...]
>> >
>> > I don't think that correct rounding of binary <-> decimal conversion
>> > is impractical at all. I think it's perfectly doable, and that a
>> > specimen implementation should accompany any IEEE ANS Forth proposal.
>> > It's particularly important for floating-point literals in programs.
>
>> Okay, so let's make that a "shall" instead of a "nominal shall",
>> and expect a specimen implementation to emerge.
>
> Right. If the implementation is horrible, then we can reconsider. An
> implementation must accompany the proposal anyway, and it's the best
> way to do a sanity check.
So maybe we don't need a MAX-FLOAT-DIGITS query, with the same
expectation that a reference implementation will emerge for
reproducibility under binary->decimal->binary conversion for M
decimal digits, with
M = 1 + ceiling( p * log_10(2) )
The IEEE-FP-FORMAT query returns the precision p, so M can be
calculated.
-- David
Andrew Haley
That might be OK; let's see. I think that apps need a nice way to say
"print this value with enough precision that someone can read it back
later."
Andrew.
David N. Williams
>
>> So maybe we don't need a MAX-FLOAT-DIGITS query, with the same
>> expectation that a reference implementation will emerge for
>> reproducibility under binary->decimal->binary conversion for M
>> decimal digits, with
>
>> M = 1 + ceiling( p * log_10(2) )
>
>> The IEEE-FP-FORMAT query returns the precision p, so M can be
>> calculated.
>
> That might be OK; let's see. I think that apps need a nice way to say
> "print this value with enough precision that someone can read it back
> later."
Here's a redraft of a version of REPRESENT without an embedded
sign for nan/inf. Correct rounding is now a "shall", exceptions
are specified, the MAX-FLOAT-DIGITS query is removed, and the
rationale is expanded.
---------
REPRESENT ( f: r -- ) ( c-addr u -- n flag1 flag2 )
When flag2 is true, the floating-point datum r was a finite
number; when false, it was a nan or inifinity. In any case,
flag1 is true if and only if the sign bit of r was unity.
When r is a finite number, place the character-string
representation of its significand at c-addr, and return the
decimal-base exponent as n. The character string shall
consist of the u most significant digits of the significand
represented as a decimal fraction with the implied decimal
point to the left of the first digit, and the first digit zero
only if all digits are zero. The significand shall be
correctly rounded to u digits, with correct signaling for
inexact and underflow conditions; n is adjusted, if necessary,
to correspond to the rounded magnitude of the significand.
If u is greater than or equal to
M = 1 + ceiling( p * log_10 (2) ) ,
where p is the precision returned by the IEEE-FP-FORMAT
environmental query, and the rounding mode is roundTiesToEven
in both directions, conversion back to binary with the
algorithm of >FLOAT or the text interpreter shall reproduce r.
The string shall be padded with u - M trailing zeroes if u is
larger than M.
An ambiguous condition exists if the value of BASE is not
decimal ten.
When r is a nan or infinity, the character string shall be one
of the three-character options for <nan> or <inf>, respectively,
recognized by >FLOAT. If u is less than three, the string is
truncated; if more than three, it is padded with trailing
blanks. When r is infinity, the value n returned is zero;
when r is a nan, it is a nonzero, implementation-defined
number. In neither case is an exception signaled.
---------
[**RATIONALE
The implementation-defined value of n for nans could be used in
a future proposal to encode information about the signaling bit
and load.
Correct rounding with IEEE floating-point exceptions is required
by IEEE-754-2008 5.12.2, "External decimal character sequences
representing finite numbers". Among the exceptions specified in
IEEE-754-2008 4.3, "Rounding-direction attributes", overlow is
irrelevant for finite r, leaving inexact and underflow. Infinity
and nan are treated explicitly.
Reproducibility under binary to decimal to binary conversion is
required by IEEE 754-2008 5.12.2. It ensures that a user can
print values and read them back without loss of precision.
A reference implementation which demonstrates correct rounding
and reproducibility remains to be presented. The following
example uses REPRESENT to define a word that prints decimal
floating-point output with the maximum usable number of digits.
s" IEEE-FP-FORMAT" ENVIRONMENT? [IF] ( emax p) NIP
0 D>F 2E FLOG F* FCEIL 1E F+ FCONSTANT MAX-FLOAT-DIGITS [THEN]
: .SIGN ( flag -- ) IF ." -" ELSE ." +" THEN ;
: F.BIG ( r -- )
PAD MAX-FLOAT-DIGITS REPRESENT IF
.SIGN ." ."
PAD MAX-FLOAT-DIGITS TYPE
." E" 0 .R
ELSE
OVER 0= ( INF) IF DUP .SIGN THEN
2DROP PAD MAX-FLOAT-DIGITS TYPE
THEN ;
]
--------
-- David
David N. Williams
> "David N. Williams" <will...@umich.edu> wrote in message
news:h6kfhc$j8p$1...@news.eternal-september.org...
>> Andrew Haley wrote:
>> > David N. Williams <will...@umich.edu> wrote:
>> >
>> >> REPRESENT ( f: r s: c-addr u -- n flag1 flag2 )
>> >> [..]
>>
>> > This is rather underspecified.
>>
>> Sorry for the delay -- other things going on...
>>
>> Here's a rewrite.
>
> Let's hope this is only the first revision and better one's
> will follow :)
I don't know if you think it's better, but one followed. :-)
> In the meantime, try this out on your forth:
>
> 2 SET-PRECISION ok
> 467.8E FE. 470.E0 ok
> 1E 0E F/ FE. +INF ok
-----------
[jost:~/Desktop] dnwills% pfe
\ Portable Forth Environment 0.33.61 (Aug 21 2008 11:00:57)
Copyright (C) Dirk Uwe Zoller 1993 - 1995.
Copyright (C) Tektronix, Inc. 1998 - 2003.
ANS/ffa ITC Forth - Please enter LICENSE and WARRANTY.
Running on powerpc darwin9.4.0 - to quit say BYE. ok
loadm floating ok
2 SET-PRECISION ok
1E 0E F/ F. inf ok
1E 0E F/ FS. INF ok
1E 0E F/ FE. nanE+324 ok
467.8E FE. +467.80E+00 ok
------------
[jost:~/Desktop] dnwills% gforth
Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
2 SET-PRECISION ok
1E 0E F/ F. in ok
1E 0E F/ FS. in ok
1E 0E F/ FE. in ok
467.8E FE. 470.�
0�0�
0�
[more lines snipped]
-----------
So they're both buggy...
-- David
Ed
> Ed wrote:
> > "David N. Williams" <will...@umich.edu> wrote in message
> news:h6kfhc$j8p$1...@news.eternal-september.org...
> >> Andrew Haley wrote:
> >> > David N. Williams <will...@umich.edu> wrote:
> >> >
> >> >> REPRESENT ( f: r s: c-addr u -- n flag1 flag2 )
> >> >> [..]
> >>
> >> > This is rather underspecified.
> >>
> >> Sorry for the delay -- other things going on...
> >>
> >> Here's a rewrite.
> >> [former rewrite snipped]
> >
> > Let's hope this is only the first revision and better one's
> > will follow :)
>
> I don't know if you think it's better, but one followed. :-)
The test is whether it can be used to write viable output
functions.
That's why I invited you to try out the examples I gave.
> > In the meantime, try this out on your forth:
> >
> > 2 SET-PRECISION ok
> > 467.8E FE. 470.E0 ok
> > 1E 0E F/ FE. +INF ok
>
> -----------
> [jost:~/Desktop] dnwills% pfe
> \ Portable Forth Environment 0.33.61 (Aug 21 2008 11:00:57)
> Copyright (C) Dirk Uwe Zoller 1993 - 1995.
> Copyright (C) Tektronix, Inc. 1998 - 2003.
> ANS/ffa ITC Forth - Please enter LICENSE and WARRANTY.
> Running on powerpc darwin9.4.0 - to quit say BYE. ok
> loadm floating ok
> 2 SET-PRECISION ok
> 1E 0E F/ F. inf ok
> 1E 0E F/ FS. INF ok
> 1E 0E F/ FE. nanE+324 ok
> 467.8E FE. +467.80E+00 ok
This forth is not a good test subject.
It assumes PRECISION means "decimal places" - which defeats
the purpose of the test. Nan/Inf display for FE. is also obviously
broken.
> ------------
> [jost:~/Desktop] dnwills% gforth
> Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
> Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
> Type `bye' to exit
> 2 SET-PRECISION ok
> 1E 0E F/ F. in ok
> 1E 0E F/ FS. in ok
> 1E 0E F/ FE. in ok
> 467.8E FE. 470.�
> 0�0�
> 0�
> [more lines snipped]
> -----------
>
This forth is typical of most:
- +INF has no sign and/or is truncated to the point of being
unintelligible.
- The wrong value is displayed for 470 - or else the system
crashes or displays rubbish in the attempt.
> So they're both buggy...
All forths I tried including commercial ones failed similarly*.
The tests used are "reasonable". E.g. in electronics, component
values with a precision of 2 are common, as is engineering
notation. The problem lies in REPRESENT.
I chose these examples to illustrate why REPRESENT as
commonly interpreted/implemented is wrong. Your spec
would produce similar results.
There are minimum features REPRESENT must have in order
to be able to write viable apps. I've implemented them.
What '94 says REPRESENT should do - or what others think
it says - is meaningless if one can't use it to do anything
useful with it.
--
* Not all forths that failed necessarily had a defective
REPRESENT.
Some forths which had implemented my REPRESENT spec,
then made departures, or they didn't use REPRESENT to
define FE. Or both. I'm not responsible for that.
David N. Williams
> [...]
>
> s" IEEE-FP-FORMAT" ENVIRONMENT? [IF] ( emax p) NIP
> 0 D>F 2E FLOG F* FCEIL 1E F+ FCONSTANT MAX-FLOAT-DIGITS [THEN]
Should be
s" IEEE-FP-FORMAT" ENVIRONMENT? [IF] ( emax p) NIP
0 D>F 2E FLOG F* FCEIL 1E F+ F>D DROP
CONSTANT MAX-FLOAT-DIGITS [THEN]
-- David
David N. Williams
>> And what's the practical effect of current rounding, when correct
>> rounding is a pipe dream because of unachievaable accuracy?
>
> In the case of the core arithmetic operations and binary/decimal
> conversions, there is no insurmountable barrier to getting correctly
> rounded results. This is the part that it's most important to get
> right, because it determines the reproducibility (and therefore
> predictability) of floating-point arithmetic.
I've been running some tests in gforth and pfe on correct
rounding with REPRESENT and reproducibility with that combined
with >FLOAT.
So far, it seems the round trip works in all but a few cases, in
spite of the fact that REPRESENT doesn't do correct rounding.
That may be because REPRESENT and >FLOAT use the *same* rounding
for the same system, but I'm not sure yet.
-- David
Andrew Haley
99 times out of 100 it will work, but some harder cases come when the
input string has more digits than the internal precision. The trick
described in "How to Read Floating Point Numbers Accurately" is use a
couple of digits of extra precision to get a close approximation and
then, if you're not sure, try FNEXT or FPREV to adjust.
Because this can be slow, one implementation possibility is to define
>FLOAT as the fast algorithm when you don't care about 1 ulp, and only
do the refinement in >IEEEFLOAT. This gives users the best of all
worlds, IMO. However, the text interpreter should always get this one
right!
Andrew.
David N. Williams
> Marcel Hendrix wrote:
>> ...
>> [quoting from David N. Williams]
>> An ambiguous condition exists if
>> causes unsuccessful text intepretation, in which case behavior
>> shall be governed by DPANS94 3.4.4, "Possible actions on an
>> ambiguous condition".
>>
>> [**QUOTE
>> 3.4.4 Possible actions on an ambiguous condition
>>
>> more of the following actions:
>>
>> * ignore and continue;
>> * display a message;
>> * execute a particular word;
>> * set interpretation state and begin text interpretation;
>> * take other implementation-defined actions;
>> * take implementation-dependent actions.
>>
>> The response to a particular ambiguous condition need not be the
>> same under all circumstances.
>> ]
>
> Reading the relevant sections suggests that not all these options
> are necessarily available. The list encompasses possible actions
> for all ambiguous conditions - not just those resulting from
> failed interpretation.
But nevertheless including those resulting from failed
interpretation, no?!
> A common view is that it is permissible to ignore numeric
> overflow in the interpreter. Maybe not.
>
> The text interpreter is bound up with the requirements of QUIT :
>
> 3.4 The Forth text interpreter
> ...
> Text interpretation (see 6.1.1360 EVALUATE and 6.1.2050 QUIT)
> shall repeat the following steps until either the parse area is empty
> or an ambiguous condition exists:
> ...
>
> 6.1.2050 QUIT
> ...
> Repeat the following:
>
> Accept a line from the input source ... and interpret.
>
> Display the implementation-defined system prompt if in
> interpretation state, all processing has been completed,
> and no ambiguous condition exists.
>
> The last paragraph suggests that should an ambiguous condition
> occur during interpretation, one is not permitted to say it's "OK"
> when interpretation state is re-entered. That seems to rule out
> the "ignore and continue" option.
I don't see the suggestion. Surely the last paragraph
does not logically restrict any legal ambiguous-condition
behavior when an ambiguous condition exists?
I personally prefer that fp overflow in the text interpreter not
be an ambiguous condition, and that it signal an IEEE exception.
With default exception handling (produce +/-infinity, set the
overflow flag, and continue), that can be detected if desired.
Eventually there should be an interface for alternate handlers,
and with a special handler installed, you could choose to abort
in a block of code.
Installing alternate handlers might well be different for low
level situations, like fundamental arithmetic, and higher level
situations, like text interpretation, where there would be
little performance penalty for something based on CATCH/THROW.
-- David
David N. Williams
> [...]
>
> D>F
> ( d -- ) ( F: -- r )
> When d is too large, generate +/-Inf.
>
> [ this can happen on a 64-bit system or on a 32-bit system with bin32
> floats. Note that the required current rounding mode does not cover
> the over/underflow case. The Standard does not specify D>F in that
> case so iForth does as stated.
> The same happens for the common S>F word. -mhx]
Guess I don't see this. On a 64-bit system, the biggest d is
1.FF... * 2^126, while emax is 127 for bin32. So d is in range,
and rounding doesn't overflow. Or am I mistaken?
On the other hand, I've learned that IEEE does specify an
equivalent, and it does mention overflow. Here's a redraft:
-------------
D>F ( d -- ) ( f: -- r )
The result r is the floating-point equivalent of d. If
conversion of d cannot be represented precisely in the
default fp format, it shall be rounded according to the
current rounding mode, and the inexact or overflow exception
shall be handled just as for arithmetic operations. See
IEEE 754-2008 5.4.1, "Arithmetic operations",
formatOf-convertFromInt(int).
[**Default handling for overflow/inexact is given by IEEE
754-2008 7.4/7.6. The fp status flags are set, and overflow
produces +/-infinity, while inexact rounds. Default overflow
handling sets the inexact flag as well.
Note that d is always in range for any of the formats
binary32, binary64, binary80, and binary128, for 32- or 64-bit
systems.
]
------------
-- David
Ed
> Ed wrote:
I read it as: don't display the OK prompt if an ambiguous
condition has occured.
The only way to stop the prompt from being displayed
is for the ambiguous condition to break out of the QUIT
loop. "Ignore and continue" won't do that.
One might debate which ambiguous condition the TC
was talking about - ones generated within QUIT itself
i.e. the interpreter - or those caused as a result of
executing functions initiated by the interpreter.
Marcel Hendrix
> Marcel Hendrix wrote:
[...]
>> D>F
>> ( d -- ) ( F: -- r )
>> When d is too large, generate +/-Inf.
>> [ this can happen on a 64-bit system or on a 32-bit system with bin32
>> floats. Note that the required current rounding mode does not cover
>> the over/underflow case. The Standard does not specify D>F in that
>> case so iForth does as stated.
>> The same happens for the common S>F word. -mhx]
> Guess I don't see this. On a 64-bit system, the biggest d is
> 1.FF... * 2^126, while emax is 127 for bin32. So d is in range,
> and rounding doesn't overflow. Or am I mistaken?
You're right. But am I mistakenly assuming that a programmer will count on
"xx. 2dup D>F F>D D= ." to print -1 ? (except possibly for the infamous
xx. == $8000,0000,0000,0000 case)
> On the other hand, I've learned that IEEE does specify an
> equivalent, and it does mention overflow. Here's a redraft:
-------------
D>F ( d -- ) ( f: -- r )
The result r is the floating-point equivalent of d. If
conversion of d cannot be represented precisely in the
default fp format, it shall be rounded according to the
current rounding mode, and the inexact or overflow exception
shall be handled just as for arithmetic operations. See
IEEE 754-2008 5.4.1, "Arithmetic operations",
formatOf-convertFromInt(int).
[**Default handling for overflow/inexact is given by IEEE
754-2008 7.4/7.6. The fp status flags are set, and overflow
produces +/-infinity, while inexact rounds. Default overflow
handling sets the inexact flag as well.
Note that d is always in range for any of the formats
binary32, binary64, binary80, and binary128, for 32- or 64-bit
systems.
]
------------
I think especially the rounding part of this definition deviates
wildly from common implementation practice (even gForth is using
the fild instruction here) and as such will cause chaos.
-marcel
Coos Haak
Did you ever read the following part of the standard:
3.4.4 Possible actions on an ambiguous condition
When an ambiguous condition exists, a system may take one or more of
the following actions:
* ignore and continue;
-- The above is a possible outcome!
* display a message;
-- or this
* execute a particular word;
-- or this
* set interpretation state and begin text interpretation;
-- or this
* take other implementation-defined actions;
-- or this
* take implementation-dependent actions.
-- and finally this too.
The response to a particular ambiguous condition need not be the same
under all circumstances.
> The only way to stop the prompt from being displayed
> is for the ambiguous condition to break out of the QUIT
> loop. "Ignore and continue" won't do that.
>
That's not what the standard says (only way).
--
Coos
CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html
Ed
> ...
> Did you ever read the following part of the standard:
Of course. It hasn't changed since the last time I read it.
> 3.4.4 Possible actions on an ambiguous condition
> When an ambiguous condition exists, a system may take one or more of
> the following actions:
> ...
It doesn't mean all are applicable, or that the Standard
won't specify further requirements as in QUIT which
then limits your options.
Failure of the forth text interpreter/compiler to find a
name or convert it to a valid number is not "OK" - it's
never useful, it's fatal. No doubt about it.
Andrew Haley
> The result r is the floating-point equivalent of d. If
> conversion of d cannot be represented precisely in the
> default fp format, it shall be rounded according to the
> current rounding mode, and the inexact or overflow exception
> shall be handled just as for arithmetic operations. See
> IEEE 754-2008 5.4.1, "Arithmetic operations",
> formatOf-convertFromInt(int).
> [**Default handling for overflow/inexact is given by IEEE
> 754-2008 7.4/7.6. The fp status flags are set, and overflow
> produces +/-infinity, while inexact rounds. Default overflow
> handling sets the inexact flag as well.
> Note that d is always in range for any of the formats
> binary32, binary64, binary80, and binary128, for 32- or 64-bit
> systems.
> ]
> ------------
> I think especially the rounding part of this definition deviates
> wildly from common implementation practice (even gForth is using
> the fild instruction here) and as such will cause chaos.
I can't see the difference from fild. Can you be more specific,
please?
Andrew.
David N. Williams
> [...]
>
>> Guess I don't see this. On a 64-bit system, the biggest d is
>> 1.FF... * 2^126, while emax is 127 for bin32. So d is in range,
>> and rounding doesn't overflow. Or am I mistaken?
>
> You're right. But am I mistakenly assuming that a programmer will
count on
> "xx. 2dup D>F F>D D= ." to print -1 ? (except possibly for the infamous
> xx. == $8000,0000,0000,0000 case)
Here's one programmer who wouldn't assume that! :-)
He couldn't count on it with DPANS94 because D>F generates an
ambiguous condition where IEEE would require rounding. F>D is
not ambiguous, because the r from D>F is an integer that fits
into a d.
With IEEE, rounding occurs when |d| >= 2^(p+1), where p is the
format precision, so he can't count on it then. This already
happens with 32-bit systems and binary64, where p = 53.
Clearly it would be good to add something to the informative
rationale. How about this?
----------
A programmer can assume that
( d) 2DUP D>F F>D D= ( flag)
results in a true flag only when |d| < 2^(p+1), where p is the
format precision, so that rounding does not occur. Rounding
does occur, for example, with 32-bit systems and binary64, when
|d| > 2^54.
----------
-- David
David N. Williams
> [...]
> A programmer can assume that
>
> ( d) 2DUP D>F F>D D= ( flag)
>
> results in a true flag only when |d| < 2^(p+1), where p is the
> format precision, so that rounding does not occur. Rounding
> does occur, for example, with 32-bit systems and binary64, when
> |d| > 2^54.
> ----------
Oops! |d| >= 2^54.
> -- David
Marcel Hendrix
> Marcel Hendrix <m...@iae.nl> wrote:
[.. D>F ..]
> I think especially the rounding part of this definition deviates
> wildly from common implementation practice (even gForth is using
> the fild instruction here) and as such will cause chaos.
> I can't see the difference from fild. Can you be more specific,
> please?
Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
cr 9223371972430266300. 2dup d. d>f f>d d.
9223371972430266300 9223371972430266368 ok
cr 9223371972430266300. 2dup d. d>f f.
9223371972430266300 9223371972430270000. ok
A positive double number is transformed into a float that is nowhere
near "correctly rounded."
( on a system with bin80 floats, which is also using fild )
FORTH> cr 9223371972430266306. 2dup d. d>f f>d d.
9223371972430266306 9223371972430266306 ok
FORTH> cr 9223371972430266306. 2dup d. d>f f.
9223371972430266306 0.922337197243026631e19 ok
-marcel
Marcel Hendrix
> Marcel Hendrix wrote:
[...]
> F>D is
> not ambiguous, because the r from D>F is an integer that fits
> into a d.
> With IEEE, rounding occurs when |d| >= 2^(p+1), where p is the
> format precision, so he can't count on it then. This already
> happens with 32-bit systems and binary64, where p = 53.
The problem with F>D is that when one specifies an F whose absolute
value does not fit into 53 bits, some Forths will return a fixed D
value, while the new F>D apparently wants them to return a "properly
rounded" one.
Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
9223371972430266300e f>d hex. hex. $7FFFFFF1 $0 ok
9223371972430266368e f>d hex. hex. $7FFFFFF1 $0 ok
9223371972430266378e f>d hex. hex. $7FFFFFF1 $0 ok
9223371972430266478e f>d hex. hex. $7FFFFFF1 $0 ok
9223371972430266478e f>d hex. hex. $7FFFFFF1 $0 ok
9223371972430266778e f>d hex. hex. $7FFFFFF1 $0 ok
9223371972430266878e f>d hex. hex. $7FFFFFF1 $0 ok
-marcel
David N. Williams
> Andrew Haley <andr...@littlepinkcloud.invalid> writes Re: IEEE-FP 0.5.3
>
>> Marcel Hendrix <m...@iae.nl> wrote:
> [.. D>F ..]
>> I think especially the rounding part of this definition deviates
>> wildly from common implementation practice (even gForth is using
>> the fild instruction here) and as such will cause chaos.
>
>> I can't see the difference from fild. Can you be more specific,
>> please?
>
> Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
> Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
> Type `bye' to exit
>
> cr 9223371972430266300. 2dup d. d>f f>d d.
> 9223371972430266300 9223371972430266368 ok
>
> cr 9223371972430266300. 2dup d. d>f f.
> 9223371972430266300 9223371972430270000. ok
>
> A positive double number is transformed into a float that is nowhere
> near "correctly rounded."
Actually, I think it's okay:
19 set-precision ok
cr 9223371972430266300. 2dup d. d>f f.
9223371972430266300 9223371972430266368. ok
I actually verified this by doing it all in hex and rounding by
hand.
-- David
David N. Williams
> "David N. Williams" <will...@umich.edu> writes Re: IEEE-FP 0.5.3
>
>> Marcel Hendrix wrote:
> [...]
>> F>D is
>> not ambiguous, because the r from D>F is an integer that fits
>> into a d.
>
>> With IEEE, rounding occurs when |d| >= 2^(p+1), where p is the
>> format precision, so he can't count on it then. This already
>> happens with 32-bit systems and binary64, where p = 53.
>
> The problem with F>D is that when one specifies an F whose absolute
> value does not fit into 53 bits, some Forths will return a fixed D
> value, while the new F>D apparently wants them to return a "properly
> rounded" one.
This would have been clearer if I'd included the DPANS94 text in
the spec for F>D -- sorry about that. I just happen to have
finished a redraft: :-)
-----------
F>D ( f: r -- ) ( -- d )
The result d is the double-cell signed-integer equivalent of
the integer portion of r. The fractional portion of r is
discarded. An ambiguous condition exists if the integer
portion of r cannot be precisely represented as a double-cell
signed integer, or if r is a nan or infinity. [**The only
noncosmetic change is the last clause of the last sentence.]
[**Marcel Hendrix suggests the following reasonable behavior for
the ambiguous condition on two's complement systems:
When the integer part of r is not representable by a signed,
double number, or when it is a NaN or Inf, the following
happens:
FORTH> +Inf F>D hex UD. 8000000000000000 ok
FORTH> -Inf F>D hex UD. 8000000000000000 ok
FORTH> +NaN F>D hex UD. 8000000000000000 ok
FORTH> -NaN F>D hex UD. 8000000000000000 ok
]
[**RATIONALE
The DPANS94 version corresponds to convertToIntegerTowardZero();
see IEEE 754-2008 5.8, "Details of conversions from
floating-point to integer formats". IEEE requires that the
invalid operation exception be signaled when r is a nan or
infinity or out of range of the destination format.
IEEE also requires
convertToIntegerTiesToEven()
convertToIntegerTowardPositive()
convertToIntegerTowardNegative()
convertToIntegerTiesToAway()
plus versions of the five conversions that signal inexact when
appropriate. Note that, except for convertToIntegerTiesAway and
the Forth ambiguous condition, the above conversions are
equivalent to Forth phrases such as "FCEIL F>D".
]
-----------
Okay, I see that the name F>D is more misleading with IEEE than
it was with DPANS94, because we're predisposed to think "current
rounding". Maybe it should be FTRUNC>D. Should we do that?
> Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
> Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
> Type `bye' to exit
>
> 9223371972430266300e f>d hex. hex. $7FFFFFF1 $0 ok
> 9223371972430266368e f>d hex. hex. $7FFFFFF1 $0 ok
> 9223371972430266378e f>d hex. hex. $7FFFFFF1 $0 ok
> 9223371972430266478e f>d hex. hex. $7FFFFFF1 $0 ok
> 9223371972430266478e f>d hex. hex. $7FFFFFF1 $0 ok
> 9223371972430266778e f>d hex. hex. $7FFFFFF1 $0 ok
> 9223371972430266878e f>d hex. hex. $7FFFFFF1 $0 ok
With the above explanation, this is the expected behavior,
AFAICT.
-- David
Andrew Haley
> [**RATIONALE
> The DPANS94 version corresponds to convertToIntegerTowardZero();
> see IEEE 754-2008 5.8, "Details of conversions from
> floating-point to integer formats". IEEE requires that the
> invalid operation exception be signaled when r is a nan or
> infinity or out of range of the destination format.
> IEEE also requires
> convertToIntegerTiesToEven()
> convertToIntegerTowardPositive()
> convertToIntegerTowardNegative()
> convertToIntegerTiesToAway()
> plus versions of the five conversions that signal inexact when
> appropriate. Note that, except for convertToIntegerTiesAway and
> the Forth ambiguous condition, the above conversions are
> equivalent to Forth phrases such as "FCEIL F>D".
> ]
> -----------
> Okay, I see that the name F>D is more misleading with IEEE than
> it was with DPANS94, because we're predisposed to think "current
> rounding". Maybe it should be FTRUNC>D. Should we do that?
F>D is, as far as I can see, convertToIntegerTowardZero. There's no
need for a different F>D function. The only difference from ANS is
the FP exceptions, so apart from requiring F>D to raise an exception
we can leave the wording alone.
Andrew.
David N. Williams
Right, I didn't mean to suggest a different function or a change
in wording. It's just that the name FTRUNC>D agrees better with
the spec. I do understand that it's not practical to rename, so
I should have squashed the impulse. :-(
I've moved the note about what's different from DPANS94 into the
rationale. Maybe the redraft below is clearer.
-- David
------------
[**RATIONALE
The only change from DPANS94 is to include nans and infinity in
the ambiguous condition. Except for exception handling, F>D
corresponds to the IEEE function convertToIntegerTowardZero().
IEEE requires that the invalid operation exception be signaled
when r is a nan or infinity or out of range of the destination
format. See IEEE 754-2008 5.8, "Details of conversions from
floating-point to integer formats".
IEEE also requires
convertToIntegerTiesToEven()
convertToIntegerTowardPositive()
convertToIntegerTowardNegative()
convertToIntegerTiesToAway()
plus versions of the five conversions that signal inexact when
appropriate. Note that, except for convertToIntegerTiesAway and
the Forth ambiguous condition, the above conversions are
equivalent to Forth phrases such as "FCEIL F>D".
]
------------
Anton Ertl
>I suspect I wasn't clear. I'm not concerned with the wording of
>your proposal. Rather the underlying assumption - namely that
>REPRESENT places a string of "u" characters in the buffer
>when flag2 = false.
>
>This is a common interpretation of the Standard definition,
>and indeed, some REPRESENT's have been implemented
>that way. What I'm suggesting is that this is a) not borne
>out by the text, and b) unhelpful.
>
>A close reading of the Standard text shows that "u" is only
>used in reference to "significant digits" and numbers - never
>as a string length. The paragraph that relates to when flag2
>= false, never mentions "u" at all. Readers simply assumed
>that the resulting string would be limited to "u characters".
>
>My spec isn't so much a change to the Standard definition
>- but another interpretation of it (along with some necessary
>extensions and clarification).
We have had this discussion before, but as I read it, your
"interpretation" is a change, and worse, it buffer-overflows at least
one existing standard program (and I looked at only one program that
uses REPRESENT). So I am not going to implement it, and oppose it if
it is proposed for standardization.
If you want something else, instead of breaking the existing
REPRESENT, better propose something better. REPRESENT is obviously
inspired by C's ecvt(), but fails in several respects, as the
discussion with you revealed:
1) There is no output length returned (in C this is done with
zero-termination).
2) The fcvt() functionality (for getting a specific number of digits
after the decimal point) is missing and hard to emulate.
Also, the ecvt() man page on my Linux system says:
|These functions are obsolete. Instead, sprintf(3) is recommended.
I'm not sure that an sprintf-style interface would fly, but certainly
a replacement for REPRESENT with a different name and without a hidden
buffer size would be a good idea.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2009: http://www.euroforth.org/ef09/
Anton Ertl
>[jost:~/Desktop] dnwills% gforth
>Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
>Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
>Type `bye' to exit
>2 SET-PRECISION ok
>1E 0E F/ F. in ok
>1E 0E F/ FS. in ok
>1E 0E F/ FE. in ok
>467.8E FE. 470.�
> 0�0�
> 0�
Strange:
Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
2 SET-PRECISION 467.8E FE. 470.E0 ok
(On Linux-AMD64, Linux-IA32, and Linux-PPC).
David N. Williams
> "David N. Williams" <will...@umich.edu> writes:
>> [jost:~/Desktop] dnwills% gforth
>> Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
>> Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
>> Type `bye' to exit
>> 2 SET-PRECISION ok
>> 1E 0E F/ F. in ok
>> 1E 0E F/ FS. in ok
>> 1E 0E F/ FE. in ok
>> 467.8E FE. 470.�
>> 0�0�
>> 0�
>
> Strange:
>
> Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
> Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
> Type `bye' to exit
> 2 SET-PRECISION 467.8E FE. 470.E0 ok
>
> (On Linux-AMD64, Linux-IA32, and Linux-PPC).
Seems to be a Mac OS X thing. I get similar behavior on both
intel and ppc Mac's, although the runaway characters are
different.
-- David
Ed
> "Ed" <nos...@invalid.com> writes:
> > ...
> >My spec isn't so much a change to the Standard definition
> >- but another interpretation of it (along with some necessary
> >extensions and clarification).
>
> "interpretation" is a change,
So it's not a change - but rather one interpretation against
another.
> and worse, it buffer-overflows at least
> one existing standard program (and I looked at only one program that
> uses REPRESENT).
A "standard program" that makes assumptions about
how REPRESENT works is hardly Standard.
I could equally assert that your program was defective
because you failed to accommodate the needs of
REPRESENT. It's all a matter of perspective.
BTW I looked at more than "one program" and only
yours failed. It's easily fixed - as you well know -
but then you would have no grounds for complaint.
> So I am not going to implement it, and oppose it if
> it is proposed for standardization.
Though not for any technical reason.
According to this, the spec was adopted sometime ago:
\ *P As of January 2007, recommendations made to the Forth200x standards
\ ** effort have been adopted for *\fo{REPRESENT}. The impact of these
\ ** changes are that the minimum buffer size used for *\fo{REPRESENT}
\ ** should be at least *\fo{#FDIGITS} characters, normally 18 bytes.
\ ** For details of the proposal, see:
\ *C ftp://ftp.taygeta.com/pub/Forth/Applications/ANS/Represent_20.txt
(ref: MPE VFX demo. Ndp387.fth)
Anton Ertl
>Anton Ertl wrote:
>> "Ed" <nos...@invalid.com> writes:
>> > ...
>> >My spec isn't so much a change to the Standard definition
>> >- but another interpretation of it (along with some necessary
>> >extensions and clarification).
>>
>> We have had this discussion before but as I read it, your
>> "interpretation" is a change,
>
>So it's not a change - but rather one interpretation against
>another.
No. Even you admit in your notes that it is a change: From
<ftp://ftp.taygeta.com/pub/Forth/Applications/ANS/Represent_21.txt>:
|Existing applications will be unaffected provided a buffer not less
|than MAX-FLOAT-DIGITS characters has been allocated.
If it was no change, existing applications would be unaffected no
matter what.
Also, your change requires applications to do an environmental query
for MAX-FLOAT-DIGITS, a query string that only your change introduced
and that does not occur in the standard.
>> and worse, it buffer-overflows at least
>> one existing standard program (and I looked at only one program that
>> uses REPRESENT).
>
>A "standard program" that makes assumptions about
>how REPRESENT works is hardly Standard.
A program that uses REPRESENT certainly has to make assumptions on how
it works. However, in this case these assumptions are based on the
text of the standard, and therefore the program is standard.
>I could equally assert that your program was defective
>because you failed to accommodate the needs of
>REPRESENT. It's all a matter of perspective.
It works correctly with a correctly implemented REPRESENT.
>BTW I looked at more than "one program" and only
>yours failed.
I don't believe that. How many of the programs you looked at have
queried MAX-FLOAT-DIGITS? And what do they do if the system does not
provide a length as a result of that query? If they do not query for
MAX-FLOAT-DIGITS or if the system does not give a length, there is no
way that a program can be correct for your changed REPRESENT; and
given that each system can chose not to give a length on that query,
there is no way that a program can guarantee to work correctly with
your changed REPRESENT.
Therefore I don't believe that there are any pre-existing programs
that work correctly with your changed REPRESENT in general; they may
be lucky enough to make the buffer big enough for some specific
systems, but that's not general correctness.
If you want to have it more concrete, please present a pre-existing
piece of code that uses REPRESENT in a way that you believe to be
compatible with your change, and I will show that it isn't.
>> So I am not going to implement it, and oppose it if
>> it is proposed for standardization.
>
>Though not for any technical reason.
>
>According to this, the spec was adopted sometime ago:
>
> \ *P As of January 2007, recommendations made to the Forth200x standards
> \ ** effort have been adopted for *\fo{REPRESENT}. The impact of these
> \ ** changes are that the minimum buffer size used for *\fo{REPRESENT}
> \ ** should be at least *\fo{#FDIGITS} characters, normally 18 bytes.
> \ ** For details of the proposal, see:
> \ *C ftp://ftp.taygeta.com/pub/Forth/Applications/ANS/Represent_20.txt
>
>(ref: MPE VFX demo. Ndp387.fth)
If MPE adopts your change in REPRESENT, that's deplorable, but mainly
it's something between them and their users.
Ed
> >
> > \ *P As of January 2007, recommendations made to the Forth200x standards
> > \ ** effort have been adopted for *\fo{REPRESENT}. The impact of these
> > \ ** changes are that the minimum buffer size used for *\fo{REPRESENT}
> > \ ** should be at least *\fo{#FDIGITS} characters, normally 18 bytes.
> > \ ** For details of the proposal, see:
> > \ *C ftp://ftp.taygeta.com/pub/Forth/Applications/ANS/Represent_20.txt
> >
> >(ref: MPE VFX demo. Ndp387.fth)
>
> If MPE adopts your change in REPRESENT, that's deplorable, but mainly
> it's something between them and their users.
Not deplorable - nothing else is viable.
What's deplorable is that someone should wish to foist upon all forth
users an interpretation of REPRESENT they know to be deficient:
2 SET-PRECISION
467.8E CR FE.
470.E0
-INF CR FE.
-I
Here, finite numbers are printed with as many characters as are
needed. But for no apparent reason, non-numbers are truncated
to 2 characters.
That's a very stupid and unusable REPRESENT. It's laughable
that anyone should support it.
Feel free to oppose all you want but I fail to see the sense in it.