RfD: IEEE-FP
David N. Williams
http://www-personal.umich.edu/~williams/archive/temp/ieee-fp.txt
There are several editorial comments [**like this] which should
eventually disappear. They indicate gaps, explicit and implied
questions, etc.
My head is swimming from juggling details from among three C99
references and a couple of IEEE 754 references. Many of those
get hidden behind "adopt by reference" anyway. I'm certain to
have made mistakes.
Actually, I already see I've left out the C99 fmod, remainder,
and remquo functions. :-(
Locals aren't addressed at all, and I haven't proposed
resolutions for some of the other floating-point concerns that
have been expressed in c.l.f. -- I haven't had time to review
those yet. I expect people will speak up!
If people think the general framework is okay, maybe it can help
set a context for discussing those issues.
Please have a look, and offer criticisms, both general and
specific, and suggestions.
-- David
David N. Williams
> Okay, here's a first draft.
>
> http://www-personal.umich.edu/~williams/archive/temp/ieee-fp.txt
Some typos and a text duplication have been fixed, the most
important being in Sec. 5.6 on text interpretation, and in the
bnf in the definition of >F in Sec. 6.3.
Organizing corrections is going to be tricky.
The references are copied below, so the links can be clicked.
[2] and [4] are free for C99 -- although you have to register
for [4].
If somebody has a link for the IEEE 754:1985 final draft, I'd
appreciate having it. I used a copy I'd collected from
somewhere...
It appears that remarks about ttester from earilier versions
have been removed. The plan was that tests should be part of
the document, and indeed Annex F has a section that simply lists
results for signed zero, NaN, and Inf, ready for tests.
That still seems to me a good idea. But let's see what people
think first...
-- David
--------------------------
7 FOOTNOTES AND REFERENCES
[1] 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
[2] C99 + TC1 + TC2 is included in WG14/N1124, May 6, 2005:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf
[3] TC3: http://www.iec.ch/cgi-bin/getcorr.pl/yab/iso/
isoiec9899-cor3{ed1.0}en.pdf?file=iso/isoiec9899-cor3{ed1.0}en.pdf
[4] Single UNIX 3: http://www.unix.org/single_unix_specification/
[5] ANSI X3.215-1994 final draft:
http://www.taygeta.com/forth/dpans.html
[6] 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
Andrew Haley
> David N. Williams wrote:
> > Okay, here's a first draft.
> >
> > http://www-personal.umich.edu/~williams/archive/temp/ieee-fp.txt
> Some typos and a text duplication have been fixed, the most
> important being in Sec. 5.6 on text interpretation, and in the
> bnf in the definition of >F in Sec. 6.3.
> Organizing corrections is going to be tricky.
We really need a Wiki for this.
> The references are copied below, so the links can be clicked.
> [2] and [4] are free for C99 -- although you have to register
> for [4].
> If somebody has a link for the IEEE 754:1985 final draft, I'd
> appreciate having it. I used a copy I'd collected from
> somewhere...
It's not online AFAIK.
> It appears that remarks about ttester from earilier versions
> have been removed. The plan was that tests should be part of
> the document, and indeed Annex F has a section that simply lists
> results for signed zero, NaN, and Inf, ready for tests.
> That still seems to me a good idea. But let's see what people
> think first...
My first look indicates to me that there are some things in there that
are required neither by IEEE nor by Standard Forth. I take it that
this is not what was intended: we don't want to be importing the
entire C floating-point library. :-)
Great work, BTW.
Andrew.
Helmar
wrote:
> David N. Williams <willi...@umich.edu> wrote:
>
> > David N. Williams wrote:
> > > Okay, here's a first draft.
>
> > >http://www-personal.umich.edu/~williams/archive/temp/ieee-fp.txt
> > Some typos and a text duplication have been fixed, the most
> > important being in Sec. 5.6 on text interpretation, and in the
> > bnf in the definition of >F in Sec. 6.3.
> > Organizing corrections is going to be tricky.
>
> We really need a Wiki for this.
Or a Google Wave or so.
> > The references are copied below, so the links can be clicked.
> > [2] and [4] are free for C99 -- although you have to register
> > for [4].
> > If somebody has a link for the IEEE 754:1985 final draft, I'd
> > appreciate having it. I used a copy I'd collected from
> > somewhere...
>
> It's not online AFAIK.
>
> > It appears that remarks about ttester from earilier versions
> > have been removed. The plan was that tests should be part of
> > the document, and indeed Annex F has a section that simply lists
> > results for signed zero, NaN, and Inf, ready for tests.
> > That still seems to me a good idea. But let's see what people
> > think first...
>
> My first look indicates to me that there are some things in there that
> are required neither by IEEE nor by Standard Forth. I take it that
> this is not what was intended: we don't want to be importing the
> entire C floating-point library. :-)
>
> Great work, BTW.
>
> Andrew.
Just as a small question: Floating Point support is really that
important? I do not know. I guess a bound implementation to some
(whatever) standard makes it harder to support specific platforms. As
of now we do have some words, not bound to specific binary
representations (implementations are quite a different thing too).
Should not be it OK to leave it like it is? Well, I do not use (or
even like to use) floats that much.
-Helmar
Andrew Haley
> On May 29, 9:58?am, Andrew Haley <andre...@littlepinkcloud.invalid>
> wrote:
> > David N. Williams <willi...@umich.edu> wrote:
> >
> > > David N. Williams wrote:
> > > > Okay, here's a first draft.
> >
> > > >http://www-personal.umich.edu/~williams/archive/temp/ieee-fp.txt
> > > Some typos and a text duplication have been fixed, the most
> > > important being in Sec. 5.6 on text interpretation, and in the
> > > bnf in the definition of >F in Sec. 6.3.
> > > Organizing corrections is going to be tricky.
> >
> > We really need a Wiki for this.
> Or a Google Wave or so.
"Google Wave will be available later this year."
> > My first look indicates to me that there are some things in there
> > that are required neither by IEEE nor by Standard Forth. I take
> > it that this is not what was intended: we don't want to be
> > importing the entire C floating-point library. :-)
> >
> > Great work, BTW.
> Just as a small question: Floating Point support is really that
> important? I do not know. I guess a bound implementation to some
> (whatever) standard makes it harder to support specific
> platforms. As of now we do have some words, not bound to specific
> binary representations (implementations are quite a different thing
> too). Should not be it OK to leave it like it is?
Of course: this is an optional wordset. In practice, however, much of
the hardware that's used today is IEEE-compatible, and this is an
opportunity to make floating-point more useful.
Andrew.
Helmar
wrote:
> Helmar <hel...@gmail.com> wrote:
> > On May 29, 9:58?am, Andrew Haley <andre...@littlepinkcloud.invalid>
> > wrote:
> > > David N. Williams <willi...@umich.edu> wrote:
>
> > > > David N. Williams wrote:
> > > > > Okay, here's a first draft.
>
> > > > >http://www-personal.umich.edu/~williams/archive/temp/ieee-fp.txt
> > > > Some typos and a text duplication have been fixed, the most
> > > > important being in Sec. 5.6 on text interpretation, and in the
> > > > bnf in the definition of >F in Sec. 6.3.
> > > > Organizing corrections is going to be tricky.
>
> > > We really need a Wiki for this.
> > Or a Google Wave or so.
>
> "Google Wave will be available later this year."
I do not think it's implemented in Forth ;) As that we can call it a
"crap" here, even if it looks really promising imho...
> > > My first look indicates to me that there are some things in there
> > > that are required neither by IEEE nor by Standard Forth. I take
> > > it that this is not what was intended: we don't want to be
> > > importing the entire C floating-point library. :-)
>
> > > Great work, BTW.
> > Just as a small question: Floating Point support is really that
> > important? I do not know. I guess a bound implementation to some
> > (whatever) standard makes it harder to support specific
> > platforms. As of now we do have some words, not bound to specific
> > binary representations (implementations are quite a different thing
> > too). Should not be it OK to leave it like it is?
>
> Of course: this is an optional wordset. In practice, however, much of
> the hardware that's used today is IEEE-compatible, and this is an
> opportunity to make floating-point more useful.
It would be nice of course. I always understood FP as something that
is used in situation where you do not know the scale of your data -
eg. is it from 10 to 100 or from 1000000000 to 10000000000. I think it
still is this way. And it could be interesting for some specific
tasks. So if the IEEE-formate is really that common now, I do think
there is good reason to at least specify a good practice for it.
Regards,
-Helmar
David N. Williams
>
>> Organizing corrections is going to be tricky.
>
> We really need a Wiki for this.
Beyond my expertise, I'm afraid. :-(
Maybe somebody else could set one up? But maybe first we should
get a feeling for what the changes are likely to be.
>> If somebody has a link for the IEEE 754:1985 final draft, I'd
>> appreciate having it. I used a copy I'd collected from
>> somewhere...
>
> It's not online AFAIK.
Afraid of that. Here's a link:
http://twins.ee.nctu.edu.tw/~tjlin/courses/co01/IEEE754.pdf
If it's illegal, I didn't tell anybody to click on it!
> My first look indicates to me that there are some things in there that
> are required neither by IEEE nor by Standard Forth. I take it that
> this is not what was intended: we don't want to be importing the
> entire C floating-point library. :-)
Actually, that was pretty much my intent! :-)
I'm not sure which parts you're referring to. It seemed to me
worthwhile to include as much as possible, so the specification
is there, even if it's not implemented. For example, much of
Sec. 6.13, "Floating-point environment" is optional, even
according to C99, if I understand correctly. The document says
If an environmental query on the string FENV-ACCESS returns
false, none of the words defined here should be available.
And C99 says things to the effect that if such and such is
unsupported, such and such shall not be defined, implying they
don't have to be supported.
> Great work, BTW.
Than' kew! :-)
-- David
Anton Ertl
>David N. Williams <will...@umich.edu> wrote:
>> Organizing corrections is going to be tricky.
>
>We really need a Wiki for this.
If you want to have multiple people editing this, my suggestion would
be a version control system.
>> If somebody has a link for the IEEE 754:1985 final draft, I'd
>> appreciate having it. I used a copy I'd collected from
>> somewhere...
Why not use the 2008 version? Ok, I recently had a look at it and
found it hard to grasp; not sure if the 1985 version is better.
- 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/
Helmar
wrote:
> Andrew Haley <andre...@littlepinkcloud.invalid> writes:
> >David N. Williams <willi...@umich.edu> wrote:
> >> Organizing corrections is going to be tricky.
>
> >We really need a Wiki for this.
>
> If you want to have multiple people editing this, my suggestion would
> be a version control system.
A Wiki usually has this. I think "Wiki" is ok today. My note of the
Google-next-thing at horizon is not unintended. It can do probably
better than a plain Wiki as known today. The version control systems
today are worse than a wiki. Nothing against even RCS for private
needs (or use GIT, Subversion, CVS, ---> Mercurial <---, Monotone, ...
what you want). But this is for private needs. You do not get 10
developers to the same thing they like most. The truth about it is
that most things are still not very good.
> >> If somebody has a link for the IEEE 754:1985 final draft, I'd
> >> appreciate having it. I used a copy I'd collected from
> >> somewhere...
>
> Why not use the 2008 version? Ok, I recently had a look at it and
> found it hard to grasp; not sure if the 1985 version is better.
If there really is a 2008 version, I'd strongly suggest to use this
version.
Regards,
-Helmar
Thomas Pornin
> If there really is a 2008 version, I'd strongly suggest to use this
> version.
There is a 2008 version; it is the one I bought (for a project
completely unrelated to Forth, which called for the implementation of
IEEE 754 arithmetics with 32-bit and 64-bit integer operations).
It is quite understandable, and not too long (70 pages), but it pays
off to first read a smaller introduction to IEEE 754, in particular:
http://en.wikipedia.org/wiki/IEEE_754-1985
Half of the 2008 version is about decimal types, which you can skip if
you only want to use the binary types (the ones which were in the 1985
version, and which are commonly implemented by current hardware).
--Thomas Pornin
David N. Williams
facilitate discussion, not just the link. It's below.
-- David
-----------------------------------------
PROPOSAL FOR AN OPTIONAL IEEE 754, BINARY
FLOATING-POINT WORD SET
version 0.5.0
dnw 29-May-09
TABLE of CONTENTS
1 INTRODUCTION
2 TERMINOLOGY AND NOTATION
3 DATA TYPES AND ALIGNMENT
4 ENVIRONMENTAL QUERIES
5 IMPLEMENTATION
6 GLOSSARY
6.1 Parameters
6.2 Floating-point stack manipulation
6.3 Conversion
6.4 Storage
6.5 Input
6.6 Output
6.7 Comparison
6.8 Arithmetic
6.9 Nearest integer functions
6.10 Math functions
6.11 Number classification
6.12 Number manipulation
6.13 Floating-point environment
6.13.1 Exceptions
6.13.2 Rounding modes
7 REFERENCES AND FOOTNOTES
1 INTRODUCTION
This is a proposal for an optional Forth 200x word set that
supports the IEC 60559 floating-point standard for binary
floating-point arithmetic, second edition (IEC 60559:1989),
previously designated IEC 559:1989 and as IEEE Standard for
Binary Floating-Point Arithmetic (ANSI/IEEE Std 754:1985).
This document is modeled on the ISO/IEC 9899:1999 C language
specification [1] for IEEE 754 floating point, which is
contained in the WG14/N1124 draft standard [2], plus Technical
Corrigendum 3 [3], and is mostly expressed in Sections 5.2.4.2
of the Environment chaper, Sections 7.6, 7.7, and 7.12 of the
Library chapter, and Annex F, "IEC 60559 floating-point
arithmetic". The Single UNIX 3 specification [4] is a useful
resource for ISO/IEC 9899:1999
The advantages of following the C99 specification include the
following:
* It seems to be a comprehensive expression of IEEE 754:1985 and
William Kahan's approach to accurate floating-point
computation, which underlies it.
* It is pretty clearly written with freely available versions.
* It is straightforward to implement for Forth systems that can
call C libraries.
* Its combination of implementation abstractions and dependences
seems about as well suited to the spectrum of cpu capabilities
as can be expected. It complicates the specification, but
that is probably unavoidable.
This specification requires that ISO Forth [5,6] floating-point
and floating-point extension words in the optional
Floating-Point word set, when present, satisfy the IEEE 754
requirements. Words in that word set, and this, that correspond
to arithmetic operations, functions, or macros specified in
ISO/IEC 9899 adopt, as far as possible, the specified behavior
by reference.
[**Bracketed statements like this are for editorial questions
and comments, eventually to be removed.]
2 TERMINOLOGY AND NOTATION
"IEEE 754" or "IEEE": IEC 60559:1989.
"C99": ISO/IEC 9899:1999 C [1].
"Annex F": Annex in WG14/N1124 [2] or ISO/IEC 9899:1999.
"DPANS94": American National Standard for Forth, ANSI
X3.215-1994, final draft [5]. The final draft is believed to
be the same as the published version, which is now ISO/IEC
15145:1997 [6]. This document adopts the official terminology
of DPANS94 unless otherwise stated.
"fp" or "bfp": Short for "floating point", respectively,
"binary flaoting point". The Forth floating-point stack is
called the "fpstack".
"special number": Signed zero, a quiet or signaling signed nan,
or signed infinity.
"full set of numbers": For an IEEE 754 bfp format, the set of
normal, subnormal, and special numbers.
"IEEE number": Any member of a full set of numbers.
"IEEE arithmetic": Arithmetic defined by IEEE 754 for IEEE
numbers.
"nan load": The value of the IEEE 754 fractional bits 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. [**True for all IEEE binary formats?]
"qnan", resp., "snan": Any quiet or signaling nan,
respectively, of any sign or load.
"single": In the context of Forth fp, the IEEE 754 32-bit
single-precision format.
"double": In the context of Forth fp, the IEEE 754 64-bit
double-precision format.
"default": In the context of Forth fp, the default float
format.
Each IEEE bfp format has three fixed parameters, p > 0
(precision), emax > 0 (maximim exponent), and emin < 0 (minimum
exponent), and 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 = #signifcand bits.
IEEE numbers are typically encoded with exponent fields
equivalent to emin-1 for zero and subnormals, and emax+1 for
infinity and nans.
3 DATA TYPES AND ALIGNMENT
If part or all of the floating-point stack is implemented in
memory, the alignment of stack items in memory shall be the
maximum of the alignments of the implemented formats. The width
of the floating-point stack shall be at least that of the widest
implemented format. [**Does DPANS94 already imply this?]
The DPANS94 r, sr, and dr types are expanded to include the
special numbers.
For the purposes of this word set, DPANS94 Table 12.1 is
replaced by Table 1.
Table 1
-------------------------------------------------------------
Symbol Data type Size on stack
-------------------------------------------------------------
r default float implementation-defined
sr single float implementation-defined
dr double float implementation-defined
f-addr float-aligned address 1 cell
sf-addr single-float-aligned address 1 cell
df-addr double-float-aligned address 1 cell
enum distinct integer 1 cell
+enum nonnegative enum 1 cell
fenva a-addr 1 cell
fenvr n 1 cell
fxctpa a-addr 1 cell
fxcpts masks 1 cell
-------------------------------------------------------------
4 ENVIRONMENTAL QUERIES
A true result for the IEEE-FP environmental query implies that
at least a default, IEEE bfp format is implemented. As
described in the implemention section, that may or may not be
distinct from the IEEE single or double format.
Value
String Data Type Constant? Meaning
----------------------------------------------------------------
IEEE-FP n no n=1: single-fp format implemented
n-2: double-fp format implemented
n=3: both formats implemented
n=0: neither format implemented
FENV-ACCESS a-addr no default fp environment pointer
----------------------------------------------------------------
The words in the PARAMETERS section, plus 1 FLOATS and FALIGNED,
can be used to determine the default bfp format.
5 IMPLEMENTATION
This document considers three logical IEEE bfp formats: default
(Forth float), double, and single. They are called logical
formats because the default format may actually coincide with
the double or single format.
For each of these there is a corresponding set of words, the
default fp words, the double fp words, and the single fp words,
each of which is self-contained with respect to the
corresponding fp data and address operations.
There are also "generic" fp words, involving only data or fp
stack manipulation, which can be used with any of the three
types because of the model that all three have a single-width
container on the fpstack. (It is up to the user to keep track
of the type for fpstack numbers.) There is something to be said
for an alternate model with separate fpstacks for different
formats, but that is not the approach here.
Finally, there are "conversion" fp words, which convert between
bfp formats on the fpstack, between integers on the data
stack and numbers on the fpstack, and between strings and
numbers on the fpstack.
From now on, "default fp word set" refers both to the default
words already present in DPANS94 plus the default fp words
introduced in this document. "Double fp word set", "single fp
word set", "generic word set", and "conversion word set" have
analogous meanings. The collection is called the "IEEE-FP word
set".
Single and double word definitions are often specified by
substitution of single and double data and address types into
default definitions.
According to DPANS94, Section 3, "Usage requirements":
A system shall provide all of the words defined in 6.1 Core
Words. It may also provide any words defined in the optional
word sets and extension word sets.
The DPANS94 Floating-Point word set is an optional word set,
and so is the IEEE-FP word set.
The word "shall" in the following states a requirement when the
environmenal query for IEEE-FP returns true. "Should" means
"strongly recommended".
1. All words from the DPANS94 Floating-Point and Floating-Point
Extensions word sets are included in the IEEE-FP word set,
subject to additional IEEE 754 requirements.
2. A default, IEEE bfp format shall be implemented.
3. Each implemented IEEE format shall be full.
4. The single bfp format need not be implemented. This is a
departure from the IEEE 754 specification.
5. Neither the single nor the double fp word set need be
implemented. Only conversion words that connect to
implemented logical formats need be implemented.
6. The syntax specification in DPANS94 12.3.7, "Text input number
conversion", shall be replaced by
Convertible string := {<significand><exponent>|<special>}
[**Allow [<sign>]<digits0>.<digits> as well?]
<significand> := [<sign>]{<digits>[.<digits0>]|.<digits>}
[**Note the extra .<digits> option.]
<exponent> := {<e-char>[<sign>]<digits>|<e-char>}
[**Note that a sign with no digits is not allowed.]
<digits> := <digit><digits0>
<digits0> := <digit>*
<sign> := {+|-}
<e-char> := {E|e}
<special> := [<sign>]{<inf>|<nan>}
<inf> := {Inf|inf|INF}
<nan> := {NaN|nan|NAN}
Interpretation shall convert to the default IEEE format.
The positive special number produced for NaN is the quiet
nan with zero load, and that produced by -NaN is its
negative.
Nan loads should be interpreted.
[**Note the "should". Syntax spec to be filled in.]
C99 syntax with significand in hex and radix 2 exponent in
decimal should be interpreted.
[**Syntax spec to be filled in.]
The rounding mode for number conversion is the IEEE mode,
round to nearest with even tiebreakers.
[**This corresponds to the C99 requirement for translation.
However, DPANS94 12.3.1.2 says
Any rounding or truncation of floating-point numbers is
implementation defined.
I take that to apply to text interpreter input
number conversion, and we may want to keep it.
In any case, the wording of 12.3.1.2 needs fixing, because
it contradicts the DPANS94 definition of FROUNDS, which
requires "round to nearest".]
7. The default format should have precision and range greater
than or equal to those of any other implemented format.
Otherwise the text interpreter cannot correctly interpret
the maximum precision and range.
8. All words that have natural correspondences to macros,
functions, or operations in C99 are expected to have
analogous behavior, when that makes sense. In particular,
the behavior of floating point arithmetic and math functions
for the special numbers and exceptions is specified by Annex
F. Note that C99 leaves many such details as implementation
defined.
6 GLOSSARY
For the default, double, and single fp words, specifications are
usually given only for the default versions, with the names of
the other versions simply listed. Their specifications are
obtained by substitution of the appropriate data and address
types. The double and single names are not even listed for many
of the math function words.
6.1 Parameters
--------------
These words return values for the default fp format. The C99
parameter FRADIX is not implemented because the only radix is
two. The other C99 parameters have versions for each of the C
types float, double, and long double. Single and double
versions are omitted here, because they are required to
correspond exactly to the IEEE 754 32- and 64-bit formats.
FMANT-DIG ( -- p )
FEXP-MAX ( -- emax )
FEXP-MIN ( -- emin )
6.2 Floating-point stack manipulation
-------------------------------------
These generic words are simply listed. They do not have
explicit double or single versions. The new words are defined
by analogy with the corresponding integer words. The fpstack
manipulation words allow any of r, dr, and sr mixed as inputs or
outputs.
FALIGN FALIGNED FDEPTH FDROP FDUP FOVER FROT FSWAP
New:
-FROT FNIP FTUCK
[** 2FDUP 2FOVER 2FSWAP ?]
6.3 Conversion
--------------
F>SF ( f: r -- sr )
SF>F ( f: sr -- r )
F>DF ( f: r -- dr )
DF>F ( f: dr -- r )
SF>DF ( f: sr -- dr )
DF>SF ( f: dr -- sr )
These words are all new. The treatment of precision and
rounding in these conversions is adapted from C99:6.3.1.5.
[**Does that also cover nan loads?]
D>F ( d -- f: r )
F>D ( f: r -- s: d )
S>F ( n -- f: r ) new
F>S ( f: r -- s: n ) new
The DPANS94 specification is extended to include signed zero
for r. When an input r is signed zero, the output integer is
zero. When the input integer is zero, the output r is +0. An
ambiguous condition exists when the input r is infinity or
nan.
D>DF D>SF DF>D SF>D S>DF S>SF DF>S SF>S
>F ( c-addr u -- r: r s: flag )
The DPANS94 specification is that of >FLOAT, extended to
include special numbers, with modified syntax. [**Rounding?]
A string of blanks [**or the empty string?] should be treated
as +0. [**Allow formatting blanks or characters?]
Syntax of a convertible string := {<significand>[exponent]
|<special>}
<significand> := [<sign>]{<digits>[.<digits0>]|.<digits>}
<exponent> := <marker><digits0>
<marker> := [<e-form>|<sign>]
<e-form> := <e-char>[<sign>]
<sign> := {+|-}
<e-char> := {D|d|E|e}
<special> := [<sign>]{<inf>|<nan>}
<inf> := {Inf|inf|INF}
<nan> := {NaN|nan|NAN}
>DF >SF
FREPRESENT ( f: r s: c-addr u -- n flag1 flag2 )
The specification is basically that of DPANS94 for REPRESENT,
extended to include signed zero for r. The valid-result flag,
flag2, is false if r is infinity or a nan.
[**The new name is for consistency with the format
nomenclature, but also presents an opportunity to tighten the
specification of REPRESENT.]
DFREPRESENT SFREPRESENT
6.4 Storage
-----------
DPANS94 specifications for the existing words are extended to
include the special numbers. The only new words are the single
and double constant, literal, and variable words, which have the
natural definitions.
F! F@ FALIGN FALIGNED FCONSTANT FLITERAL FVARIABLE
DF! DF@ DFALIGN DFALIGNED DFCONSTANT DFLITERAL DFVARIABLE
SF! SF@ SFALIGN SFALIGNED SFCONSTANT SFLITERAL SFVARIABLE
FLOAT+ FLOATS DFLOAT+ DFLOATS SFLOAT+ SFLOATS
[**Do we want a CREATE-NALIGNED?]
6.5 Input
---------
See Item 6 in Section 5, concerning extension of the text
interpreter.
6.6 Output
----------
PRECISION ( -- u )
SET-PRECISION ( u -- )
These two are generic words. The DPANS94 definition is
extended to apply to the single and double versions of F.,
FE., and FS..
F. ( f: r -- )
FE. ( f: r -- )
FS. ( f: r -- )
The DPANS94 specification is extended to include the special
numbers, with output text of the appropriate form below, up to
implementation-dependent case sensitivity: [**Rounding?]
[**Mixed hex/decimal output words? FH. DFH. SFH.]
[<sign>]0{E|e}<space>
[<sign>]<inf><space>
[<sign>]<nan>[:<digits>]<space>
DF. DFE. DFS. SF. SFE. SFS.
6.7 Comparison
--------------
F0< ( f: r -- s: flag )
F0<> ( f: r -- s: flag ) new
F0= ( f: r -- s: flag )
F0> ( f: r -- s: flag ) new
F< ( f: r1 r2 -- s: flag )
F<= ( f: r1 r2 -- s: flag ) new
F<> ( f: r1 r2 -- s: flag ) new
F= ( f: r1 r2 -- s: flag ) new
F> ( f: r1 r2 -- s: flag ) new
F>= ( f: r1 r2 -- s: flag ) new
The basic definitions of the new words are by analogy with the
corresponding integer words. All definitions are extended to
the special numbers.
IEEE comparison rules:
* If any input is a nan, the result is false.
* The sign of signed zero is ignored.
* The sign of infinity is not ignored, and is treated in the
natural way for comparisons with real numbers or infinity.
Whether the "invalid" exception is raised for nans is
implementation dependent.
DF0< DF0<> DF0= DF0> DF< DF<= DF<> DF= DF> DF>=
SF0< SF0<> SF0= SF0> SF< SF<= SF<> SF= SF> SF>=
(F<) ( f: r1 r2 -- s: flag ) new C99:7.12.14.3
(F<=) ( f: r1 r2 -- s: flag ) new C99:7.12.14.4
(F>) ( f: r1 r2 -- s: flag ) new C99:7.12.14.1
(F>=) ( f: r1 r2 -- s: flag ) new C99:7.12.14.2
(F<|>) ( f: r1 r2 -- s: flag ) new C99:7.12.14.5
(F?) ( f: r1 r2 -- s: flag ) new C99:7.12.14.6
These words correspond to the C99 islessequal, isgreater,
isgreaterequal, islessgreater, and isunodered macros,
respectively. They do not raise an "invalid" fp exception
when one or both of the inputs is a nan.
Otherwise, the first four behave the same as their
unparenthesized counterparts.
(F<|>) returns false if either input is a nan, and otherwise
returns the same as FOVER FOVER F< F> OR (assuming a separate
fpstack), without evaluating its inputs twice.
(F?) returns true iff at least one of the inputs is a nan.
(DF<) (DF<=) (DF>) (DF>=) (DF<|>) (DF?)
(SF<) (SF<=) (SF>) (SF>=) (SF<|>) (SF?)
F~ ( f: r1 r2 r3 -- s: flag )
If the sign of r3 is plus, flag is true iff the absolute value
of r1 minus r2 is less than r3, taking into account IEEE
arithmetic and comparison rules.
If r3 is signed zero, flag is true iff r1 and r2 have
identical formats.
If the sign of r3 is minus, flag is true iff the absolute
value of r1 minus r2 is greater than r3, taking into account
IEEE arithmetic and comparison rules.
[**Double check that the middle case is identical to the other
two when r3 is signed zero.]
DF~ SF~
6.8 Arithmetic
--------------
F* ( f: r1 r2 -- r1*r2 )
F*+ ( f: r1 r2 r3 -- [r2*r3]+r1 ) new
F+ ( f: r1 r2 -- r1+r2 )
F- ( f: r1 r2 -- r1-r2 )
F/ ( f: r1 r2 -- r1/r2 )
FNEGATE ( f: r -- -r )
The DPANS94 specification is extended to IEEE arithmetic. See
Annex F for details on special numbers and exceptions.
[**Errors?]
DF* DF*+ DF+ DF- DF/
SF* SF*+ SF+ SF- SF/
DFNEGATE SFNEGATE
6.9 Nearest integer functions
-----------------------------
The treatment of domain and range errors is implementation
dependent.
Behavior required by C99 for special numbers, exceptions, and
the rounding state is adopted. See especially Annex F.
FCEIL ( f: r1 -- r2 ) new C99:7.12.9.1
FLOOR ( f: r1 -- r2 ) C99:7.12.9.2
FROUND ( f: r1 -- r2 ) C99:7.12.9.6
FNEARBYINT ( f: r1 -- r2 ) new C99:7.12.9.3
FTRUNC ( f: r1 -- r2 ) new C99:7.12.9.8
The behavior of FROUND is different from that of its C99
counterpart when there is a tie. It follows DPANS94, which
uses round to nearest with even tie breakers, instead of using
the ceiling for tie breakers.
FTRUNC has already passed a CfV.
FNEARBYINT depends on the rounding state.
DFCEIL DFLOOR DFROUND DFNEARBYINT DFTRUNC
SFCEIL SFLOOR SFROUND SFNEARBYINT SFTRUNC
6.10 Math functions
-------------------
All words have C99 function counterparts.
All have double and single versions, not listed, whose
names are derived from the default versions by prefixing "D" or
"S" to the default names, all of which begin with "F".
The treatment of domain and range errors is implementation
dependent.
Any special behavior required by C99 for special numbers,
exceptions, and the rounding state is adopted. See especially
Annex F.
FMAX FMIN
F** FABS FACOS FACOSH FALOG FASIN FASINH FATAN FATAN2
FATANH FCOS FCOSH FEXP FEXPM1 FLN FLNP1 FLOG FSIN
FSINCOS FSINH FSQRT FTAN FTANH
New:
FCBRT FDIM FEXP2 FHYPOT FLOG2
FERF FERFC FLGAMMA FTGAMMA
6.11 Number classification
--------------------------
FCLASSIFY ( f: r -- s: enum ) C99:7.12.3.1
Leave the classification enum corresponding to the type of r.
The required enums are listed below. An implementation may
define and produce additional enums corresponding to other
properties, with names prefixed by "FP-".
DFCLASSIFY SFCLASSIFY
FP-INFINITE ( -- enum )
FP-NAN ( -- enum )
FP-NORMAL ( -- enum )
FP-SUBNORMAL ( -- enum )
FP-ZERO ( -- enum )
IS-FINITE ( r: r -- s: [sub]normal? ) C99:7.12.3.2
IS-FINFINITE ( r: r -- s: [+|-]Inf? ) C99:7.12.3.3
IS-FNAN ( r: r -- s: [q|s]nan? ) C99:7.12.3.4
IS-FNORMAL ( r: r -- s: normal? ) C99:7.12.3.5
Leave a true flag iff r belongs to the classification
indicated by the word name.
IS-DFINITE IS-DFINFINITE IS-DFNAN IS-DFNORMAL
IS-SFINITE IS-SFINFINITE IS-SFNAN IS-SFNORMAL
6.12 Number manipulation
------------------------
See Annex F for special behavior.
FSIGNBIT ( f: r -- s: minus? ) C99:7.12.3.6
DFSIGNBIT SFSIGNBIT
FCOPYSIGN ( f: r1 r2 -- r3 ) C99:7.12.11.1
The output r3 is r1 with its sign bit replaced by that of r2.
DFCOPYSIGN SFCOPYSIGN
FNEXTAFTER ( f: r1 r2 -- r3 ) C99:7.12.11.3
FNEXTAFTER returns the next number after r1 in the r2
direction. Words corresponding to the C99 nexttoward
functions are not implemented.
DFNEXTAFTER SFNEXTAFTER
FREXP ( f: r -- frac.r s: n ) C99:7.12.6.4
The result is unspecified if r is neither normal nor
subnormal. Return the normalized fractional part of r as a
default fp number, and the power n such that frac.r*2^n = r.
If r = 0, then n = 0. Otherwise 0.5 <= frac.r < 1.0.
DFREXP SFREXP
FMODF ( f: [int.r+frac.r] -- frac.r int.r ) C99:7.12.6.12
Decompose the input into its fraction and integer parts, both
of which have the sign of the input.
DFMODF SFMODF
FSCAL2N ( f: r s: n -- f: r*2^n.r ) C99:7.12.6.13
FSCAL2D ( f: r s: d -- f: r*2^d.r )
The output is efficiently scaled by 2^n. A range-error may
occur. The C99 scalbn and scalbln family of functions works
with an implementation-defined radix b, which is required here
to be two. The ldexp family is the explicitly radix two
version for C99. It is not implemented here.
[**Should we use the C-like names: FSCALBN FSCALBD ?]
DFSCAL2N DFSCAL2D SFSCAL2N SFSCAL2D
FLOGB ( f: r -- e.r ) C99:7.12.6.11
FILOGB ( f: r -- s: e ) C99:7.12.6.5
Leave the radix two exponent e of the fp representation. If r
is subnormal, the exponent is computed as if r were
normalized, with e < emin. For FILOGB, leave the following
special values:
r e
-----------------
+0 FP_ILOGB0
-0 FP_ILOGB0
+Inf INT_MAX
-Inf INT_MAX
nan FP_ILOGBNAN
INT_MAX is the largest signed, cell-sized integer. Let
INT_MIN be the largest magnitude, negative cell-sized integer.
FP_ILOGB0 is either -INT_MAX or INT_MIN. FP_ILOGBNAN is
either INT_MAX or INT_MIN.
DFLOGB SFLOGB DFILOGB SFILOGB
6.13 Floating-point environment
-------------------------------
[**Needs checking. C99 is especially convoluted here.]
These words are all generic.
When C99 does not require the implementation of macros and
functions corresponding to words here, those words need not be
implemented. See WG14/N1124 7.6 for details [2].
If an environmental query on the string FENV-ACCESS returns
false, none of the words defined here should be available. If
the query returns true, it also returns the address of the
default fp environment data object, which the user may wish to
store in a Forth value. That replaces the C99 FE_DEFL_ENV
macro.
The structure of fp environment objects is unknown to the user.
Their data describes the state of both exception flags and the
rounding control mode, plus other implementation-defined
information.
The next two words shall be present if the FENV-ACCESS query is
true.
FE-ALL-EXCEPT ( -- fxcpts )
The output is the bitwise OR of the exception masks
for all supported fp exceptions.
/FENV ( -- u )
The size in address units of fp environment data objects.
Used to allot data space for them, which must first be
aligned.
On the data stack, "fenva" stands for the address of an fp
environment object; and "fenvr" stands for a nonzero throw code.
All words return zero if successful, else fenvr. [**Need throw
codes.]
FEGETENV ( fenva -- 0|fenvr ) C99:7.6.4.1
Store the current fp environment data at fenva.
FESETENV ( fenva -- 0|fenvr ) C99:7.6.4.2
Set the current fp environment to that of the object stored at
fenva, without raising exceptions.
FEHOLDEXCEPT ( fenva -- 0|fenvr ) C99:7.6.4.2
Store the current fp environment data at fenva for later
restoration, clear the fp exception flags, and install an
environment that turns on a nonstop mode for all fp
exceptions. Whether a nonstop mode can be set for all
exceptions is implementation dependent.
FEUPDATEENV ( fenva -- 0|fenvr ) C99:7.6.4.4
Temporarily save the current fp environment data, set the fp
environment to that of the object stored at fenva, and raise
the exceptions temporarily saved, in that order.
6.13.1 Exceptions
-----------------
If FE-ALL-EXCEPT is zero, none of the exception words in the
following should be available.
The structure of fp exception objects is unknown to the user.
Their data describes the state of the exception flags plus other
implementation-defined information.
/FEXCEPT ( -- u )
The size in address units of fp exception data objects. Used
to allot data space for them, which must first be aligned.
In the following, "fxcpta" on the data stack stands for the
address of an fp exception object, "fxcpts" stands for
exceptions mask, and "fenvr" stands for a nonzero throw code for
failure, as before. [**Need throw codes.]
The fp exceptions correspond to the following distinct, nonzero
flag masks, which correspond to C99 constant macros with "-"
replaced by "_" in the name:
Exception masks: FE-DIVBYZERO FE-INEXACT FE-INVALID
FE-OVERFLOW FE-UNDERFLOW
Masks for any of the above exceptions that are unsupported shall
not be defined. An implementation may define other exceptions,
as long the set of flags fits into one cell. Masks may be OR'd
to form fxcpts.
FEGETEXCEPTFLAG ( fxcpta fxcpts -- 0|fenvr ) C99:7.6.2.2
Store the current state of the fp exception masks in fxcpts
in the data object at fxcpta.
FESETEXCEPTFLAG ( fxcpta fxcpts -- 0|fenvr ) C99:7.6.2.4
Set the current fp exception flags in fxcpts to the values in
the data object at fxcpta.
FETESTEXCEPT ( fxcpts -- flags ) C99:7.6.2.5
Return the bitwise OR of those fp exception masks in fxcpts
that are set in the current fp exception state.
FERAISEEXCEPT ( fxcpts -- 0|fenvr) C99:7.6.2.3
FECLEAREXCEPT ( fxcpts -- 0|fenvr) C99:7.6.2.1
Attempt to raise, respectively, clear the fp exceptions in
fxcpts.
6.13.2 Rounding modes
---------------------
In the following, "fenvr" stands for a nonzero throw code for
failure, just as before, except that the one for FEGETROUND is
[**currently] required to negative. [**Need throw codes.]
The fp rounding modes correspond to the following +enums, which
correspond to C99 constant macros with "-" replaced by "_" in
the name:
Rounding +enums: FE-DOWNWARD FE-UPWARD FE-TONEAREST
FE-TOWARDZERO
An implementation may support other rounding modes, whereupon it
shall define corresponding +enums. Words for unsupported
rounding modes shall be undefined.
[**The C99 macro FLT_ROUNDS is not implemented.]
FEGETROUND ( -- +enum|fenvr ) C99:7.6.3.1
Return the +enum corresponding to the current rounding mode.
On failure, fenvr is negative.
FESETROUND ( +enum -- 0|fenvr ) C99:7.6.3.2
Attempt to set the rounding mode corresponding to +enum iff it
is supported. If the rounding mode is set, return 0, else
fenvr.
David N. Williams
The proposal is indeed specifically for binary types, but I have
no objection to using the 2008 version for those. I just didn't
have a copy, and C99 in Annex F specifies the 1985 version. Maybe
that changed between the final C99 draft and publication, but the
open-standard web site indicates they're the same:
http://www.open-std.org/jtc1/sc22/wg14/www/standards.html#9899
-- David
Andrew Haley
> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
> >David N. Williams <will...@umich.edu> wrote:
> >> Organizing corrections is going to be tricky.
> >
> >We really need a Wiki for this.
> If you want to have multiple people editing this, my suggestion would
> be a version control system.
A Wiki is a version control system, just easier to use.
Andrew.
Andrew Haley
> Andrew Haley wrote:
> > David N. Williams <will...@umich.edu> wrote:
> >> []
> >
> >> Organizing corrections is going to be tricky.
> >
> > We really need a Wiki for this.
> Beyond my expertise, I'm afraid. :-(
> Maybe somebody else could set one up? But maybe first we should
> get a feeling for what the changes are likely to be.
> >> If somebody has a link for the IEEE 754:1985 final draft, I'd
> >> appreciate having it. I used a copy I'd collected from
> >> somewhere...
> >
> > It's not online AFAIK.
> Afraid of that. Here's a link:
> http://twins.ee.nctu.edu.tw/~tjlin/courses/co01/IEEE754.pdf
> If it's illegal, I didn't tell anybody to click on it!
> > My first look indicates to me that there are some things in there that
> > are required neither by IEEE nor by Standard Forth. I take it that
> > this is not what was intended: we don't want to be importing the
> > entire C floating-point library. :-)
> Actually, that was pretty much my intent! :-)
> I'm not sure which parts you're referring to. It seemed to me
> worthwhile to include as much as possible, so the specification is
> there, even if it's not implemented.
That's a mistake, IMO. We need to include what IEEE requires and the
recommened functions and predicates. Things like FCBRT need a
separate RFD -- ieee does not require FCBRT. Also, while -FROT FNIP
FTUCK blah might have their merits, they need their own RFD.
> For example, much of Sec. 6.13, "Floating-point environment" is
> optional, even according to C99, if I understand correctly. The
> document says
> If an environmental query on the string FENV-ACCESS returns
> false, none of the words defined here should be available.
> And C99 says things to the effect that if such and such is
> unsupported, such and such shall not be defined, implying they don't
> have to be supported.
Right, but we are not standardizing C, we are standardizing Forth +
IEEE.
The biggest diagreement I have is with all the conversion words: IMO
we don't need them. Any conversions can be done with memory acceses:
F@, SF! etc. We don't need SF. or suchlike, and mixed formats on the
FP stack might not even be possible.
Here's my initial response.
Andrew.
> 3 DATA TYPES AND ALIGNMENT
>
> If part or all of the floating-point stack is implemented in
> memory, the alignment of stack items in memory shall be the
> maximum of the alignments of the implemented formats.
What is this for? The floating-point stack is an abstract entity that
has no alignment requirements. You can't take the address of anything
that's in the fp stack, so there is no way this is needed.
> The width of the floating-point stack shall be at least that of the
> widest implemented format. [**Does DPANS94 already imply this?]
I think so, but it doesn't hurt to say so.
> -------------------------------------------------------------
> Symbol Data type Size on stack
> -------------------------------------------------------------
> r default float implementation-defined
> sr single float implementation-defined
> dr double float implementation-defined
No, these sr and dr types exist only in memory. On the FP stack
there's just floats.
> C99 syntax with significand in hex and radix 2 exponent in
> decimal should be interpreted.
This is not a requirement for IEEE or Forth. I don't think we need
this.
> Any rounding or truncation of floating-point numbers is
> implementation defined.
>
> I take that to apply to text interpreter input
> number conversion, and we may want to keep it.
I don't think so. We need floating-point constants to be exactly
bitwise reproducable across all platforms.
> 7. The default format should have precision and range greater
> than or equal to those of any other implemented format.
> Otherwise the text interpreter cannot correctly interpret
> the maximum precision and range.
OK, so this allows 80-bit floats on the FP stack.
> New:
>
> -FROT FNIP FTUCK
> [** 2FDUP 2FOVER 2FSWAP ?]
Might be nice, but this is creeping featurism IMO, and should not be
here. (I think the most useful would be F>R and FR>, since you can
make everything else with them.)
> 6.3 Conversion
> --------------
>
> F>SF ( f: r -- sr )
> SF>F ( f: sr -- r )
> F>DF ( f: r -- dr )
> DF>F ( f: dr -- r )
> SF>DF ( f: sr -- dr )
> DF>SF ( f: dr -- sr )
>
> These words are all new. The treatment of precision and
> rounding in these conversions is adapted from C99:6.3.1.5.
> [**Does that also cover nan loads?]
AFAIAA this is not possible. You can adjust the precision of the
entire x87, but every element is the same size. On some platforms,
even those supporting IEEE, there is only one register size. We
should delete these words.
We can satisfy the IEEE requirement for conversion between the formats
with A SF@ B DF!.
> The DPANS94 specification is that of >FLOAT, extended to
> include special numbers, with modified syntax. [**Rounding?]
Binary <> decimal conversion is fully specified by IEEE Section 5.6.
I think we should only support round to nearest.
> A string of blanks [**or the empty string?] should be treated
> as +0. [**Allow formatting blanks or characters?]
I don't think this is required by IEEE?
> DPANS94 specifications for the existing words are extended to
> include the special numbers. The only new words are the single
> and double constant, literal, and variable words, which have the
> natural definitions.
I don't think there's any need for the new literal formats. There's
certainly no need for DFCONSTANT and SFCONSTANT.
> PRECISION ( -- u )
> SET-PRECISION ( u -- )
>
> These two are generic words. The DPANS94 definition is
> extended to apply to the single and double versions of F.,
> FE., and FS..
I don't think we need single and double versions of any of these,
since we don't need mixed-length numbers on the FP stack.
> The DPANS94 specification is extended to include the special
> numbers, with output text of the appropriate form below, up to
> implementation-dependent case sensitivity: [**Rounding?]
IEEE requires very special handling of floating-point output with
regard to the number of digits printed. This may be difficult.
> [**Mixed hex/decimal output words? FH. DFH. SFH.]
Not required by IEEE.
> DF. DFE. DFS. SF. SFE. SFS.
No, this is too much. We don't have mixed sizes on the stack.
> FCEIL ( f: r1 -- r2 ) new C99:7.12.9.1
Not required by IEEE.
> FNEARBYINT ( f: r1 -- r2 ) new C99:7.12.9.3
Not required by IEEE.
> FTRUNC ( f: r1 -- r2 ) new C99:7.12.9.8
Not required by IEEE.
> DFCEIL DFLOOR DFROUND DFNEARBYINT DFTRUNC
> SFCEIL SFLOOR SFROUND SFNEARBYINT SFTRUNC
Not needed, as previously discussed.
> New:
> FCBRT FDIM FEXP2 FHYPOT FLOG2
> FERF FERFC FLGAMMA FTGAMMA
Not required by IEEE.
> FP-INFINITE ( -- enum )
> FP-NAN ( -- enum )
> FP-NORMAL ( -- enum )
> FP-SUBNORMAL ( -- enum )
> FP-ZERO ( -- enum )
I don't think we need the enums. The ability to determine these with
the predicates is all we need.
> IS-FINITE ( r: r -- s: [sub]normal? ) C99:7.12.3.2
> IS-FINFINITE ( r: r -- s: [+|-]Inf? ) C99:7.12.3.3
> IS-FNAN ( r: r -- s: [q|s]nan? ) C99:7.12.3.4
> IS-FNORMAL ( r: r -- s: normal? ) C99:7.12.3.5
Forth tradition would have these as ?FINITE, ?NAN, etc.
> Leave a true flag iff r belongs to the classification
> indicated by the word name.
>
> IS-DFINITE IS-DFINFINITE IS-DFNAN IS-DFNORMAL
> IS-SFINITE IS-SFINFINITE IS-SFNAN IS-SFNORMAL
No mixed sizes on the FP stack, as mentioned.
> DFSIGNBIT SFSIGNBIT
Not required by IEEE. Unnecessary, too: F~ does this .
> FCOPYSIGN ( f: r1 r2 -- r3 ) C99:7.12.11.1
>
> The output r3 is r1 with its sign bit replaced by that of r2.
Yes.
> DFCOPYSIGN SFCOPYSIGN
No mixed sizes on the FP stack, as mentioned.
> FNEXTAFTER ( f: r1 r2 -- r3 ) C99:7.12.11.3
>
> FNEXTAFTER returns the next number after r1 in the r2
> direction. Words corresponding to the C99 nexttoward
> functions are not implemented.
Yes.
> DFNEXTAFTER SFNEXTAFTER
No mixed sizes on the FP stack, as mentioned.
> FLOGB ( f: r -- e.r ) C99:7.12.6.11
Yes.
> FILOGB ( f: r -- s: e ) C99:7.12.6.5
Not required by IEEE.
> If an environmental query on the string FENV-ACCESS returns
> false, none of the words defined here should be available.
Please delete this entire section, or make it a separate RFD.
Marcel Hendrix
> Anton suggested the entire document should be posted to
> facilitate discussion, not just the link. It's below.
( In the following, "No." means "Please, don't" and "Impossible." means
"I think this may be impossible." etc. )
[..]
> Each IEEE bfp format has three fixed parameters, p > 0
> (precision), emax > 0 (maximim exponent), and emin < 0 (minimum
^^^^^^^-- maximum
> exponent), and represents all real numbers of the form
[..]
> where
> s = 0 or 1, emin <= e <= emax,
> b_i = 0 or 1, p = #signifcand bits.
^^^^^^^^^^^-- #significand
[..]
> If part or all of the floating-point stack is implemented in
> memory, the alignment of stack items in memory shall be the
> maximum of the alignments of the implemented formats.
Why? (Unnecessary)
> The width
> of the floating-point stack shall be at least that of the widest
> implemented format. [**Does DPANS94 already imply this?]
How could that be not the case? (Unnecessary)
> fenva a-addr 1 cell
> fenvr n 1 cell
> fxctpa a-addr 1 cell
> fxcpts masks 1 cell
Unnecessary.
[..]
> described in the implemention section, that may or may not be
^^^^^^^^^^^^-- implementation
> String Data Type Constant? Meaning
> ----------------------------------------------------------------
> IEEE-FP n no n=1: single-fp format implemented
> n-2: double-fp format implemented
^^^-- n=2
> n=3: both formats implemented
> n=0: neither format implemented
What about extended-fp? (80 / 96 bits)
> FENV-ACCESS a-addr no default fp environment pointer
Unnecessary.
> Finally, there are "conversion" fp words, which convert between
> bfp formats on the fpstack, between integers on the data
> stack and numbers on the fpstack, and between strings and
> numbers on the fpstack.
Almost all implementations do conversion between fp formats by
using the FP stack ( x SF@ y DF! or x F! ), so new words are
not necessary.
[..]
> 6. The syntax specification in DPANS94 12.3.7, "Text input number
> conversion", shall be replaced by
> Convertible string := {<significand><exponent>|<special>}
> [**Allow [<sign>]<digits0>.<digits> as well?]
IMO: no.
> <significand> := [<sign>]{<digits>[.<digits0>]|.<digits>}
> [**Note the extra .<digits> option.]
No objection.
> <special> := [<sign>]{<inf>|<nan>}
I would happier with := <sign>{<inf>|<nan>}, and +Infinity should be allowed.
> Interpretation shall convert to the default IEEE format.
No, conversion should be to the widest format. As the result lands on the
FP stack (which has the widest format) conversion can take it from there.
> C99 syntax with significand in hex and radix 2 exponent in
> decimal should be interpreted.
> [**Syntax spec to be filled in.]
Not required. Forth has many (direct memory access, C,) ways to do this.
> 7. The default format should have precision and range greater
> than or equal to those of any other implemented format.
> Otherwise the text interpreter cannot correctly interpret
> the maximum precision and range.
This requirement would make the extended-fp format illegal or needlessly
complex.
[..]
> FMANT-DIG ( -- p )
> FEXP-MAX ( -- emax )
> FEXP-MIN ( -- emin )
IMO these are really unnecessary.
[..]
> -FROT FNIP FTUCK
> [** 2FDUP 2FOVER 2FSWAP ?]
F2DUP F2OVER F2SWAP
[..]
> F>SF ( f: r -- sr )
> SF>F ( f: sr -- r )
> F>DF ( f: r -- dr )
> DF>F ( f: dr -- r )
> SF>DF ( f: sr -- dr )
> DF>SF ( f: dr -- sr )
> These words are all new. The treatment of precision and
> rounding in these conversions is adapted from C99:6.3.1.5.
> [**Does that also cover nan loads?]
Unnecessary.
[..]
D>DF D>SF DF>D SF>D S>DF S>SF DF>S SF>S
Unnecessary.
> >F ( c-addr u -- r: r s: flag )
IMO not necessary. Adjust >FLOAT if you want.
> >DF >SF
No!
> FREPRESENT ( f: r s: c-addr u -- n flag1 flag2 )
> The specification is basically that of DPANS94 for REPRESENT,
> extended to include signed zero for r. The valid-result flag,
> flag2, is false if r is infinity or a nan.
No. It should be possible to format/output +Inf or +NaN, also with
the existing REPRESENT.
> DFREPRESENT SFREPRESENT
No!
[..]
> F! F@ FALIGN FALIGNED FCONSTANT FLITERAL FVARIABLE
> DF! DF@ DFALIGN DFALIGNED DFCONSTANT DFLITERAL DFVARIABLE
> SF! SF@ SFALIGN SFALIGNED SFCONSTANT SFLITERAL SFVARIABLE
xxCONSTANT and xxLITERAL are very unwanted, because all FP should
land on the FP stack, which will/can/must handle conversion to any
precision needed.
> [**Mixed hex/decimal output words? FH. DFH. SFH.]
Leave it to applications.
> DF. DFE. DFS. SF. SFE. SFS.
No.
> DF0< DF0<> DF0= DF0> DF< DF<= DF<> DF= DF> DF>=
> SF0< SF0<> SF0= SF0> SF< SF<= SF<> SF= SF> SF>=
No.
> (F<) ( f: r1 r2 -- s: flag ) new C99:7.12.14.3
> (F<=) ( f: r1 r2 -- s: flag ) new C99:7.12.14.4
> (F>) ( f: r1 r2 -- s: flag ) new C99:7.12.14.1
> (F>=) ( f: r1 r2 -- s: flag ) new C99:7.12.14.2
> (F<|>) ( f: r1 r2 -- s: flag ) new C99:7.12.14.5
> (F?) ( f: r1 r2 -- s: flag ) new C99:7.12.14.6
> These words correspond to the C99 islessequal, isgreater,
> isgreaterequal, islessgreater, and isunodered macros,
> respectively. They do not raise an "invalid" fp exception
> when one or both of the inputs is a nan.
No, please specify that F< etc. do not raise an exception (are
in effect (F<) etc.)
> (DF<) (DF<=) (DF>) (DF>=) (DF<|>) (DF?)
> (SF<) (SF<=) (SF>) (SF>=) (SF<|>) (SF?)
No.
> DF~ SF~
No.
> F*+ ( f: r1 r2 r3 -- [r2*r3]+r1 ) new
Creeping featurism? Are there Forths having this already?
> DF* DF*+ DF+ DF- DF/
> SF* SF*+ SF+ SF- SF/
> DFNEGATE SFNEGATE
No.
> DFCEIL DFLOOR DFROUND DFNEARBYINT DFTRUNC
> SFCEIL SFLOOR SFROUND SFNEARBYINT SFTRUNC
It is not possible to do SFROUND as it involves copying a
value from memory to the FP stack -- which may have a different
format. These words should work on memory, but IMO they can
be left out of the standard.
[..]
> All have double and single versions, not listed, whose
> names are derived from the default versions by prefixing "D" or
> "S" to the default names, all of which begin with "F".
Impossible, see DFCEIL etc. above.
> New:
> FCBRT FDIM FEXP2 FHYPOT FLOG2
> FERF FERFC FLGAMMA FTGAMMA
I can supply 50 other functions which are also "nice to have."
> DFCLASSIFY SFCLASSIFY
Impossible.
> IS-FINITE ( r: r -- s: [sub]normal? ) C99:7.12.3.2
> IS-FINFINITE ( r: r -- s: [+|-]Inf? ) C99:7.12.3.3
> IS-FNAN ( r: r -- s: [q|s]nan? ) C99:7.12.3.4
> IS-FNORMAL ( r: r -- s: normal? ) C99:7.12.3.5
IS-FINITE IS-INFINITE IS-NAN IS-NORMAL
> IS-DFINITE IS-DFINFINITE IS-DFNAN IS-DFNORMAL
> IS-SFINITE IS-SFINFINITE IS-SFNAN IS-SFNORMAL
Impossible.
> DFSIGNBIT SFSIGNBIT
Impossible.
> DFCOPYSIGN SFCOPYSIGN
Impossible.
> DFNEXTAFTER SFNEXTAFTER
Impossible.
> DFREXP SFREXP
Impossible.
> DFMODF SFMODF
Impossible.
> DFSCAL2N DFSCAL2D SFSCAL2N SFSCAL2D
Impossible.
> DFLOGB SFLOGB DFILOGB SFILOGB
Impossible.
> 6.13 Floating-point environment
> -------------------------------
I'd rather see words that explicitly specify a behavior and leave out the
getting and setting of mysterious masks. That is, "6.13.2 Rounding modes"
is ok, "6.13.1 Exceptions" is too devious.
-marcel
David N. Williams
agreement with Andrew's points about multiple types on the stack
-- pretty clear that I had a misconception.
I think there's enough agreement that I can do a revision that
simplifies the proposal.
Anyway, here are my reactions to *part* of Andrew's post.
Andrew Haley wrote:
> David N. Williams <will...@umich.edu> wrote:
>> [...]
>> I'm not sure which parts you're referring to. It seemed to me
>> worthwhile to include as much as possible, so the specification is
>> there, even if it's not implemented.
>
> That's a mistake, IMO. We need to include what IEEE requires and the
> recommened functions and predicates.
I'm not sure why it should be limited to *just* what IEEE
requires?
> Things like FCBRT need a
> separate RFD -- ieee does not require FCBRT.
Again, why *just* IEEE? Especially since it's up to the
implementation to include it or not, like any of the math
functions in the existing floating-point extensions word set.
> Also, while -FROT FNIP
> FTUCK blah might have their merits, they need their own RFD.
Okay, for sure, if leaving them in would prevent acceptance.
>> For example, much of Sec. 6.13, "Floating-point environment" is
>> optional, even according to C99, if I understand correctly. The
>> document says
>
>> If an environmental query on the string FENV-ACCESS returns
>> false, none of the words defined here should be available.
>
>> And C99 says things to the effect that if such and such is
>> unsupported, such and such shall not be defined, implying they don't
>> have to be supported.
>
> Right, but we are not standardizing C, we are standardizing Forth +
> IEEE.
I was aiming at Forth + IEEE compatible floating-point, not
necessarily limited to the functions IEEE recommends. But maybe
it does need to be split into different RfD's.
> The biggest diagreement I have is with all the conversion words: IMO
> we don't need them. Any conversions can be done with memory acceses:
> F@, SF! etc. We don't need SF. or suchlike, and mixed formats on the
> FP stack might not even be possible.
I'm pretty much convinced that I had a misconception, and that
you're right.
> Here's my initial response.
> [...]
>> 3 DATA TYPES AND ALIGNMENT
>>
>> If part or all of the floating-point stack is implemented in
>> memory, the alignment of stack items in memory shall be the
>> maximum of the alignments of the implemented formats.
>
> What is this for? The floating-point stack is an abstract entity that
> has no alignment requirements. You can't take the address of anything
> that's in the fp stack, so there is no way this is needed.
Okay, I agree it doesn't belong here.
>> The width of the floating-point stack shall be at least that of the
>> widest implemented format. [**Does DPANS94 already imply this?]
>
> I think so, but it doesn't hurt to say so.
I looked at the DPANS94 specs for DF@, DF!, SF@, SF!, and I now
believe it does *not* imply that the fp stack has the widest
format. In particular, for DF@ it says there's an ambiguous
condition if the double's exponent is too large for the internal
representation on the fp stack.
It seems DPANS94 allows the default float to have less than
the largest implemented precision and range. In that case,
it seems the interpreter can't handle the maximum precision
and range.
I'm inclined to keep the proposal's requirement that the default
format have the largest implemented precision and range, simply
to avoid that problem. What do people think? Are there even
any implementations that don't do that?
>> -------------------------------------------------------------
>> Symbol Data type Size on stack
>> -------------------------------------------------------------
>> r default float implementation-defined
>> sr single float implementation-defined
>> dr double float implementation-defined
>
> No, these sr and dr types exist only in memory. On the FP stack
> there's just floats.
As I said above, I'm pretty much convinced you're right. My
reservation is related to the point I'll mention below about
having self-contained logical environments for both singles and
larger formats when implemented.
>> C99 syntax with significand in hex and radix 2 exponent in
>> decimal should be interpreted.
>
> This is not a requirement for IEEE or Forth. I don't think we need
> this.
I do find it useful.
>> Any rounding or truncation of floating-point numbers is
>> implementation defined.
>>
>> I take that to apply to text interpreter input
>> number conversion, and we may want to keep it.
>
> I don't think so. We need floating-point constants to be exactly
> bitwise reproducable across all platforms.
Good! Do other people feel the same way?
>> 7. The default format should have precision and range greater
>> than or equal to those of any other implemented format.
>> Otherwise the text interpreter cannot correctly interpret
>> the maximum precision and range.
>
> OK, so this allows 80-bit floats on the FP stack.
Right.
>> New:
>>
>> -FROT FNIP FTUCK
>> [** 2FDUP 2FOVER 2FSWAP ?]
>
> Might be nice, but this is creeping featurism IMO, and should not be
> here. (I think the most useful would be F>R and FR>, since you can
> make everything else with them.)
Well, you know me -- simplification by logical completion. :-)
I'll think about F>R and FR>.
>> 6.3 Conversion
>> --------------
>>
>> F>SF ( f: r -- sr )
>> SF>F ( f: sr -- r )
>> F>DF ( f: r -- dr )
>> DF>F ( f: dr -- r )
>> SF>DF ( f: sr -- dr )
>> DF>SF ( f: dr -- sr )
>>
>> These words are all new. The treatment of precision and
>> rounding in these conversions is adapted from C99:6.3.1.5.
>> [**Does that also cover nan loads?]
>
> AFAIAA this is not possible. You can adjust the precision of the
> entire x87, but every element is the same size. On some platforms,
> even those supporting IEEE, there is only one register size. We
> should delete these words.
>
> We can satisfy the IEEE requirement for conversion between the formats
> with A SF@ B DF!.
Okay, I'm pretty sure you're right. I'll sleep on it.
>> The DPANS94 specification is that of >FLOAT, extended to
>> include special numbers, with modified syntax. [**Rounding?]
>
> Binary <> decimal conversion is fully specified by IEEE Section 5.6.
> I think we should only support round to nearest.
That's my vote, too.
>> A string of blanks [**or the empty string?] should be treated
>> as +0. [**Allow formatting blanks or characters?]
>
> I don't think this is required by IEEE?
Right, I was just leaving a hook for the discussion that's been
going on in c.l.f. about >FLOAT.
>> DPANS94 specifications for the existing words are extended to
>> include the special numbers. The only new words are the single
>> and double constant, literal, and variable words, which have the
>> natural definitions.
>
> I don't think there's any need for the new literal formats. There's
> certainly no need for DFCONSTANT and SFCONSTANT.
I'll think more about this.
>> PRECISION ( -- u )
>> SET-PRECISION ( u -- )
>>
>> These two are generic words. The DPANS94 definition is
>> extended to apply to the single and double versions of F.,
>> FE., and FS..
>
> I don't think we need single and double versions of any of these,
> since we don't need mixed-length numbers on the FP stack.
I think you're right.
>> The DPANS94 specification is extended to include the special
>> numbers, with output text of the appropriate form below, up to
>> implementation-dependent case sensitivity: [**Rounding?]
>
> IEEE requires very special handling of floating-point output with
> regard to the number of digits printed. This may be difficult.
>
>> [**Mixed hex/decimal output words? FH. DFH. SFH.]
>
> Not required by IEEE.
But still useful, at least FH. .
>> DF. DFE. DFS. SF. SFE. SFS.
>
> No, this is too much. We don't have mixed sizes on the stack.
You're convincing me.
I'll reply to the rest of your remarks in a separate message,
maybe tomorrow. It looks as if I'm going to be convinced that
really only one format makes sense on the stack. If so, we can
cut away quite a bit of cruft, and sharpen the focus.
Let me raise the point that I think still remains about math
with several implemented formats. Even assuming only one format
on the stack, cpu's like the ppc (and apparently intel?), have
both single and higher precision instructions. So the formats
in fp registers are logically distinct, if actually the same.
It then seems to make sense to have separate, self-contained,
single and higher precision environments, where all arithmetic
and functions have the same precision. I'm pretty sure I've
seen this advocated by computationalists.
Certainly C99 has this, where all fp math functions and
operations come in three logical formats. It may well be that
underneath, the library functions work by conversion of
arguments to only the highest precision, but I wouldn't have
thought that's a good strategy. My understanding is that it's
useful to know how a completely single-precision calculation
differs from a completely higher-precision calculation.
That argues for having default, single, and double versions of
all math operations and functions. Although there is only one
actual format on the stack, there would still have to be
distinct logical types on the stack, which the user would have
to know to apply the appropriate function.
Or not?
-- David
Marcel Hendrix
[..]
> I'm inclined to keep the proposal's requirement that the default
> format have the largest implemented precision and range, simply
> to avoid that problem. What do people think? Are there even
> any implementations that don't do that?
iForth's 1 FLOATS returns 8, while it supports F!, SF!, DF! and XF!.
XF! is 80 bits, with 1 XFLOATS being 16 for alignment purposes. Also,
iForth's ALLOCATE (but not ALLOT) always returns XFLOAT aligned blocks,
for compatibility with SSE2 system libraries and FPU assembly language
instructions.
[..]
>> I don't think so. We need floating-point constants to be exactly
>> bitwise reproducable across all platforms.
> Good! Do other people feel the same way?
Yes.
[..]
> I'll think about F>R and FR>.
I needed to add these words in the prelude to Dick van Oudheusden's FFL:
CREATE xp 0 C,
CREATE xstack #256 FLOATS ALLOT
: f>r ( r -- ; R: -- r = Push float on the return stack )
-1 xp C+! xstack xp C@ FLOATS + F! ;
: fr> ( -- r ; R: r -- = Pop float from the return stack )
xstack xp C@ FLOATS + F@ 1 xp C+! ;
: fr@ ( -- r ; R: r -- r = Get float from top of return stack )
xstack xp C@ FLOATS + F@ ;
Using a byte pointer makes resetting this stack unnecessary.
> Let me raise the point that I think still remains about math
> with several implemented formats. Even assuming only one format
> on the stack, cpu's like the ppc (and apparently intel?), have
> both single and higher precision instructions. So the formats
> in fp registers are logically distinct, if actually the same.
For the '387, once on the FPU stack they're all rounded to 80-bits.
A precision control instruction can then be used to influence
the working of +, -, *, / and sqrt. IMHO, you need to know exactly
what you're doing when setting the *default* FPU precision to 53 or
24 bits -- most practicioners will be served better by the 80-bit
default and maybe a word to explicitly change the precision around
specific code.
-marcel
Anton Ertl
> > Things like FCBRT need a
> > separate RFD -- ieee does not require FCBRT.
>
>Again, why *just* IEEE?
If it's the IEEE-FP proposal, that's a good indication where to stop.
If you put too much in a single proposal (and especially things that
are not widely implemented (yet?)), system implementors will be less
enthusiastic about the proposal, and even those who are enthusiastic
will need longer to implement it.
>Especially since it's up to the
>implementation to include it or not, like any of the math
>functions in the existing floating-point extensions word set.
The CfVs until now ask whether systems implement the extension in
full. The reason for this is: It does not make sense to have a huge
proposal of optional words where all the systems say that they
implement it, because they implement one word of it, a different word
for each system, and the programmers say that they would use it, and
they would use words that no system implements.
Extension queries must also only be affirmatively answered if the
extension is implemented in full.
Ok, various words may end up in the standards document in an extension
wordset and therefore be pick-and-choose. But even in Forth-94 a
system must only answer the query for an extension wordset with TRUE
TRUE if all the words in the extension are present.
OTOH, I don't want thematically related stuff to be split into one
proposal for each word.
> > The biggest diagreement I have is with all the conversion words: IMO
> > we don't need them. Any conversions can be done with memory acceses:
> > F@, SF! etc. We don't need SF. or suchlike, and mixed formats on the
> > FP stack might not even be possible.
>
>I'm pretty much convinced that I had a misconception, and that
>you're right.
Good. I also think that one on-stack FP type is the right thing.
Also, I am not aware of any demand from programmers for more (even SF@
SF! DF@ DF! seem to be little-used), or that any systems offer more
than one type at a time.
> >> The width of the floating-point stack shall be at least that of the
> >> widest implemented format. [**Does DPANS94 already imply this?]
In Forth-94 there is only one on-stack FP type, and of course the FP
stack has to be wide enough for this on-stack FP type.
>I looked at the DPANS94 specs for DF@, DF!, SF@, SF!, and I now
>believe it does *not* imply that the fp stack has the widest
>format. In particular, for DF@ it says there's an ambiguous
>condition if the double's exponent is too large for the internal
>representation on the fp stack.
It sounds like they were thinking of FP formats with smaller exponents
than IEEE DP; the number of total bits in such formats is not
necessarily smaller (IIRC 64-bit formats with 8-bit exponents were
popular in software FP). Of course using IEEE SP as on-stack format
would also be a Forth-94 conforming variant.
Anyway, your question seems to come down to the question of whether
this extension should require at least IEEE DP FP (or alternatively
any extended precision format) as on-stack format. There seems to be
wide common practice in systems for this, and I guess that programs
that care for IEEE FP properties (i.e., those that need this
extension) will often also need more than IEEE SP precision, so it's
probably a good idea.
> >> C99 syntax with significand in hex and radix 2 exponent in
> >> decimal should be interpreted.
> >
> > This is not a requirement for IEEE or Forth. I don't think we need
> > this.
>
>I do find it useful.
>
> >> Any rounding or truncation of floating-point numbers is
> >> implementation defined.
> >>
> >> I take that to apply to text interpreter input
> >> number conversion, and we may want to keep it.
> >
> > I don't think so. We need floating-point constants to be exactly
> > bitwise reproducable across all platforms.
>
>Good! Do other people feel the same way?
It's certainly something that I expect that programs want that need
IEEE FP properties.
OTOH, this may be the place where the least systems already implement
the wanted functionality, where it is relatively hard to implement,
and that's very hard to test. I certainly wanted to do bit-exact
input and output of FP numbers in Gforth, and I don't think we have
achieved that (certainly not on all platforms); I looked around for
(C) code to do that, but what I found did not inspire much trust.
Maybe if somebody came up with a reference implementation in Forth.
A cop-out would be to support the C99 hex-FP constants that you
mentioned above. It should be much easier to get that conversion
right.
>I'll think about F>R and FR>.
I don't think they belong in the IEEE FP proposal, but I'll give my
opinion anyway:
They are expensive to implement on many platforms due to alignment
considerations. Also, if a system has FP, it will likely also have
locals, so the better alternative IMO is to standardize FP locals.
>Certainly C99 has this, where all fp math functions and
>operations come in three logical formats.
C also has a large zoo of integer types, and tries (unsuccessfully in
my experience) to keep that under control with its type system,
overloading and automatic conversion. Forth has traditionally had as
few different types on the stack as possible (only cells and
double-cells on the data stack (and double-cells are bad enough)), and
that has worked very well in my experience (apart from the
double-cells); Forth also has no type system known to the
implementation, so having a zoo of on-stack FP types is probably going
to be worse than in C.
Anton Ertl
>> Let me raise the point that I think still remains about math
>> with several implemented formats. Even assuming only one format
>> on the stack, cpu's like the ppc (and apparently intel?), have
>> both single and higher precision instructions. So the formats
>> in fp registers are logically distinct, if actually the same.
>
>For the '387, once on the FPU stack they're all rounded to 80-bits.
>A precision control instruction can then be used to influence
>the working of +, -, *, / and sqrt. IMHO, you need to know exactly
>what you're doing when setting the *default* FPU precision to 53 or
>24 bits
Also, even that does not give you the IEEE-correct results in all
cases, because the exponent is still too large. And going through
memory is not going to help, because then you get double rounding
(i.e., the result differs by a bit from the IEEE-correct result in a
few cases). So there is no efficient way to implement IEEE SP or IEEE
DP on the 387, you only get a pretty good approximation.
Anton Ertl
>According to Helmar <hel...@gmail.com>:
>> If there really is a 2008 version, I'd strongly suggest to use this
>> version.
>
>There is a 2008 version; it is the one I bought (for a project
>completely unrelated to Forth, which called for the implementation of
>IEEE 754 arithmetics with 32-bit and 64-bit integer operations).
It's also easy to find through asking Wikipedia for IEEE 754. At the
bottom there is a link to the standard ("requires login"), and a link
to draft 1.2.9. I looked at the latter.
>It is quite understandable,
Not for the casual searcher. I wanted to check what it had to say
about the F** operation, and I also wanted to check the claim (IIRC by
Marcel) that functions like FSIN have to produce the closest FP number
to the real result as result. I did not find anything on either
topic, probably because it is not there, but the document is not clear
enough to be sure of that (at least not in the time I spent on that).
Anton Ertl
>> F*+ ( f: r1 r2 r3 -- [r2*r3]+r1 ) new
>
>Creeping featurism? Are there Forths having this already?
Some hardware has it, it's one of the few arithmetic operations
defined by IEEE FP, and it's relatively cumbersome to synthesize from
F*, F+ etc. (at least if the result should be IEEE-correct).
OTOH, the lack of common practice is certainly an argument against
including it.
Anton Ertl
>David N. Williams <will...@umich.edu> wrote:
>> IS-FINITE ( r: r -- s: [sub]normal? ) C99:7.12.3.2
>> IS-FINFINITE ( r: r -- s: [+|-]Inf? ) C99:7.12.3.3
>> IS-FNAN ( r: r -- s: [q|s]nan? ) C99:7.12.3.4
>> IS-FNORMAL ( r: r -- s: normal? ) C99:7.12.3.5
>
>Forth tradition would have these as ?FINITE, ?NAN, etc.
Really? The only words that come to my mind that start with a ?
(e.g. ?DUP, ?BRANCH) all take a flag (exception: ?DO). Words that
produce a flag maybe should be called FINITE? or NAN? etc., like EKEY?
EMIT? ENVIRONMENT? KEY?.
Andrew Haley
> I saw Marcel's post after writing this. There's a lot of
> agreement with Andrew's points about multiple types on the stack
> -- pretty clear that I had a misconception.
> I think there's enough agreement that I can do a revision that
> simplifies the proposal.
> Anyway, here are my reactions to *part* of Andrew's post.
> Andrew Haley wrote:
> > David N. Williams <will...@umich.edu> wrote:
> >> [...]
> >> I'm not sure which parts you're referring to. It seemed to me
> >> worthwhile to include as much as possible, so the specification is
> >> there, even if it's not implemented.
> >
> > That's a mistake, IMO. We need to include what IEEE requires and the
> > recommened functions and predicates.
> I'm not sure why it should be limited to *just* what IEEE
> requires?
Because IMO this should not turn in to a grab-bag of everything that
anyone might want in a full-featured floating-point system. It makes
far more sense to have a new FLOAT EXT proposal for those.
Fine-grained extensions allow implementers and users to include just
what they need. Besides, you make it hard for people -- like me --
who want to support an IEEE extension but don't want to insist that
IEEE compliant systems include a ton of new functions.
This isn't an objection to any of the new words, it's just that to
tack them on to an IEEE proposal is rather like those pork barrel
bills where something irrelevant is tacked onto the end of a law.
So, it may make sense to split this proposal into an IEEE and a new
FLOAT EXT proposal, with only the IEEE requirements in the IEEE
section.
> > Things like FCBRT need a separate RFD -- ieee does not require
> > FCBRT.
> Again, why *just* IEEE? Especially since it's up to the
> implementation to include it or not, like any of the math
> functions in the existing floating-point extensions word set.
No, it's not. All of this section is normative; if you want to claim
IEEE compliance, you have to include all the required words. And
anything non-normative shouldn't be here.
> > Also, while -FROT FNIP FTUCK blah might have their merits, they
> > need their own RFD.
> Okay, for sure, if leaving them in would prevent acceptance.
> >> For example, much of Sec. 6.13, "Floating-point environment" is
> >> optional, even according to C99, if I understand correctly. The
> >> document says
> >
> >> If an environmental query on the string FENV-ACCESS returns
> >> false, none of the words defined here should be available.
> >
> >> And C99 says things to the effect that if such and such is
> >> unsupported, such and such shall not be defined, implying they don't
> >> have to be supported.
> >
> > Right, but we are not standardizing C, we are standardizing Forth +
> > IEEE.
> I was aiming at Forth + IEEE compatible floating-point, not
> necessarily limited to the functions IEEE recommends. But maybe
> it does need to be split into different RfD's.
Yep. We need something that supports IEEE floating-point.
> >> The width of the floating-point stack shall be at least that of the
> >> widest implemented format. [**Does DPANS94 already imply this?]
> >
> > I think so, but it doesn't hurt to say so.
> I looked at the DPANS94 specs for DF@, DF!, SF@, SF!, and I now
> believe it does *not* imply that the fp stack has the widest
> format. In particular, for DF@ it says there's an ambiguous
> condition if the double's exponent is too large for the internal
> representation on the fp stack.
> It seems DPANS94 allows the default float to have less than
> the largest implemented precision and range. In that case,
> it seems the interpreter can't handle the maximum precision
> and range.
> I'm inclined to keep the proposal's requirement that the default
> format have the largest implemented precision and range, simply
> to avoid that problem.
I agree.
> >> C99 syntax with significand in hex and radix 2 exponent in
> >> decimal should be interpreted.
> >
> > This is not a requirement for IEEE or Forth. I don't think we need
> > this.
> I do find it useful.
Me too, but, as discussed above...
> >> The DPANS94 specification is that of >FLOAT, extended to
> >> include special numbers, with modified syntax. [**Rounding?]
> >
> > Binary <> decimal conversion is fully specified by IEEE Section 5.6.
> > I think we should only support round to nearest.
> That's my vote, too.
> >> The DPANS94 specification is extended to include the special
> >> numbers, with output text of the appropriate form below, up to
> >> implementation-dependent case sensitivity: [**Rounding?]
> >
> > IEEE requires very special handling of floating-point output with
> > regard to the number of digits printed. This may be difficult.
> >
> >> [**Mixed hex/decimal output words? FH. DFH. SFH.]
> >
> > Not required by IEEE.
> But still useful, at least FH. .
Sure, but, not relevant.
> Let me raise the point that I think still remains about math
> with several implemented formats. Even assuming only one format
> on the stack, cpu's like the ppc (and apparently intel?), have
> both single and higher precision instructions. So the formats
> in fp registers are logically distinct, if actually the same.
Not exactly. On x87 there's a mode bit that controls the precision of
the whole unit.
> It then seems to make sense to have separate, self-contained, single
> and higher precision environments, where all arithmetic and
> functions have the same precision. I'm pretty sure I've seen this
> advocated by computationalists.
> Certainly C99 has this, where all fp math functions and operations
> come in three logical formats. It may well be that underneath, the
> library functions work by conversion of arguments to only the
> highest precision, but I wouldn't have thought that's a good
> strategy. My understanding is that it's useful to know how a
> completely single-precision calculation differs from a completely
> higher-precision calculation.
> That argues for having default, single, and double versions of all
> math operations and functions.
All this is not without merit, but this is not the time to be
redesigning Forth. Forth *deliberately* presents a subset of the
machine to the programmer. If this proposal is to succeed, it will do
so because it's an opportunity for implementers to tighten up their
floating-point implementations, not a standards-mandated redesign.
If we make this too onerous and require dozens of new words it simply
won't be implemented.
Andrew.
Andrew Haley
> m...@iae.nl (Marcel Hendrix) writes:
> >> Let me raise the point that I think still remains about math
> >> with several implemented formats. Even assuming only one format
> >> on the stack, cpu's like the ppc (and apparently intel?), have
> >> both single and higher precision instructions. So the formats
> >> in fp registers are logically distinct, if actually the same.
> >
> >For the '387, once on the FPU stack they're all rounded to 80-bits.
> >A precision control instruction can then be used to influence the
> >working of +, -, *, / and sqrt. IMHO, you need to know exactly what
> >you're doing when setting the *default* FPU precision to 53 or 24
> >bits
> Also, even that does not give you the IEEE-correct results in all
> cases, because the exponent is still too large.
There's nothing I can see in IEEE 754 that forbids the use of larger
than standard exponents. In fact, it seems explicitly to allow it.
> And going through memory is not going to help, because then you get
> double rounding (i.e., the result differs by a bit from the
> IEEE-correct result in a few cases). So there is no efficient way
> to implement IEEE SP or IEEE DP on the 387, you only get a pretty
> good approximation.
True, but that's something we have to live with.
Andrew.
Andrew Haley
> "David N. Williams" <will...@umich.edu> writes:
> OTOH, this may be the place where the least systems already
> implement the wanted functionality, where it is relatively hard to
> implement, and that's very hard to test. I certainly wanted to do
> bit-exact input and output of FP numbers in Gforth, and I don't
> think we have achieved that (certainly not on all platforms); I
> looked around for (C) code to do that, but what I found did not
> inspire much trust.
I've had a lot of positive experiences with the floating-point IO in
fdlibm. AFAIK it does bit-exact input and output of FP numbers in all
cases.
> They are expensive to implement on many platforms due to alignment
> considerations. Also, if a system has FP, it will likely also have
> locals, so the better alternative IMO is to standardize FP locals.
Well, they're not exactly alternatives, but I take your point. I'm
not convinced that F>R is more expensive than a local. It seems very
un-Forth to provide a locals words to do the job but not a stack
version!
Andrew.
Andrew Haley
> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
> >David N. Williams <will...@umich.edu> wrote:
> >> IS-FINITE ( r: r -- s: [sub]normal? ) C99:7.12.3.2
> >> IS-FINFINITE ( r: r -- s: [+|-]Inf? ) C99:7.12.3.3
> >> IS-FNAN ( r: r -- s: [q|s]nan? ) C99:7.12.3.4
> >> IS-FNORMAL ( r: r -- s: normal? ) C99:7.12.3.5
> >
> >Forth tradition would have these as ?FINITE, ?NAN, etc.
> Really? The only words that come to my mind that start with a ?
> (e.g. ?DUP, ?BRANCH) all take a flag (exception: ?DO). Words that
> produce a flag maybe should be called FINITE? or NAN? etc., like EKEY?
> EMIT? ENVIRONMENT? KEY?.
FINITE? etc are fine by me.
Andrew.
Andrew Haley
> Not for the casual searcher. I wanted to check what it had to say
> about the F** operation, and I also wanted to check the claim (IIRC
> by Marcel) that functions like FSIN have to produce the closest FP
> number to the real result as result.
I think this is "recommended" by IEEE-2008, but none of these
functions are required. IEEE only requires the basic arithmetic and
low-level functions.
Andrew.
Anton Ertl
>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>> m...@iae.nl (Marcel Hendrix) writes:
>> >> Let me raise the point that I think still remains about math
>> >> with several implemented formats. Even assuming only one format
>> >> on the stack, cpu's like the ppc (and apparently intel?), have
>> >> both single and higher precision instructions. So the formats
>> >> in fp registers are logically distinct, if actually the same.
>> >
>> >For the '387, once on the FPU stack they're all rounded to 80-bits.
>> >A precision control instruction can then be used to influence the
>> >working of +, -, *, / and sqrt. IMHO, you need to know exactly what
>> >you're doing when setting the *default* FPU precision to 53 or 24
>> >bits
>
>> Also, even that does not give you the IEEE-correct results in all
>> cases, because the exponent is still too large.
>
>There's nothing I can see in IEEE 754 that forbids the use of larger
>than standard exponents. In fact, it seems explicitly to allow it.
What I meant was results that are exactly the same as those that an
IEEE DP or IEEE SP implementation produces.
>> And going through memory is not going to help, because then you get
>> double rounding (i.e., the result differs by a bit from the
>> IEEE-correct result in a few cases). So there is no efficient way
>> to implement IEEE SP or IEEE DP on the 387, you only get a pretty
>> good approximation.
>
>True, but that's something we have to live with.
Yes. But that means that on machines that only have a 387 FPU it is
impractical to implement an IEEE FP extension if it requires support
for DP or SP arithmetic.
David N. Williams
> David N. Williams <will...@umich.edu> wrote:
>> I saw Marcel's post after writing this. There's a lot of
>> agreement with Andrew's points about multiple types on the stack
>> -- pretty clear that I had a misconception.
>
>> I think there's enough agreement that I can do a revision that
>> simplifies the proposal.
>
>
>> That argues for having default, single, and double versions of all
>> math operations and functions.
>
> All this is not without merit, but this is not the time to be
> redesigning Forth. Forth *deliberately* presents a subset of the
> machine to the programmer. If this proposal is to succeed, it will do
> so because it's an opportunity for implementers to tighten up their
> floating-point implementations, not a standards-mandated redesign.
>
> If we make this too onerous and require dozens of new words it simply
> won't be implemented.
This is actually a reply to everybody. The discussion so far
has been very constructive, and I'm now engaged in a big rewrite.
I don't intend, by saying that, to inhibit further discussion in
the meantime! :-)
Thanks,
-- David
Anton Ertl
>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>> "David N. Williams" <will...@umich.edu> writes:
>
>> OTOH, this may be the place where the least systems already
>> implement the wanted functionality, where it is relatively hard to
>> implement, and that's very hard to test. I certainly wanted to do
>> bit-exact input and output of FP numbers in Gforth, and I don't
>> think we have achieved that (certainly not on all platforms); I
>> looked around for (C) code to do that, but what I found did not
>> inspire much trust.
>
>I've had a lot of positive experiences with the floating-point IO in
>fdlibm. AFAIK it does bit-exact input and output of FP numbers in all
>cases.
I found an fdlibm at <http://www.netlib.org/fdlibm/>, but I don't see
any IO or conversion functions there. Am I blind?
>> They are expensive to implement on many platforms due to alignment
>> considerations. Also, if a system has FP, it will likely also have
>> locals, so the better alternative IMO is to standardize FP locals.
>
>Well, they're not exactly alternatives, but I take your point. I'm
>not convinced that F>R is more expensive than a local. It seems very
>un-Forth to provide a locals words to do the job but not a stack
>version!
The performance issue is: If the FP value has higher alignment
requirements than a cell (e.g., on 32-bit SPARC or MIPS; not sure
about ARM), then a simple return stack implementation has to first
store the FP value in some temporary place and then copy it to the
return stack in cell-sized pieces. Of course one can optimize that
away, but it requires complications in the implementation of the
return stack that are not very Forth-like, either. Or alternatively a
separate floating-point return stack like the one Marcel Hendrix has
shown, which has its own performance issues.
Andrew Haley
> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
> >Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> >> m...@iae.nl (Marcel Hendrix) writes:
> >> >> Let me raise the point that I think still remains about math
> >> >> with several implemented formats. Even assuming only one format
> >> >> on the stack, cpu's like the ppc (and apparently intel?), have
> >> >> both single and higher precision instructions. So the formats
> >> >> in fp registers are logically distinct, if actually the same.
> >> >
> >> >For the '387, once on the FPU stack they're all rounded to 80-bits.
> >> >A precision control instruction can then be used to influence the
> >> >working of +, -, *, / and sqrt. IMHO, you need to know exactly what
> >> >you're doing when setting the *default* FPU precision to 53 or 24
> >> >bits
> >
> >> Also, even that does not give you the IEEE-correct results in all
> >> cases, because the exponent is still too large.
> >
> >There's nothing I can see in IEEE 754 that forbids the use of larger
> >than standard exponents. In fact, it seems explicitly to allow it.
> What I meant was results that are exactly the same as those that an
> IEEE DP or IEEE SP implementation produces.
This means that with x87 we won't be 100% compatible with IEEE, which
requires "Implementations shall provide [+ - * / sqrt] for
destinations of all supported arithmetic formats". But...
In 1985, the standard said that "All implementations shall support the
single format". Now (2008) it says "The choice of which of this
standard's formats to support is language-defined or, if the relevant
language standard is silent or defers to the implementation,
implementation-defined." So, we don't have to support single or
double AIUI, except as interchange formats as required by Standard
Forth. Granted, this is a rather Jesuitical reading of IEEE-2008, and
I may well have missed something.
> Yes. But that means that on machines that only have a 387 FPU it is
> impractical to implement an IEEE FP extension if it requires support
> for DP or SP arithmetic.
It's essential that we don't do that.
Andrew.
Andrew Haley
> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
> >Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> >> "David N. Williams" <will...@umich.edu> writes:
> >
> >> OTOH, this may be the place where the least systems already
> >> implement the wanted functionality, where it is relatively hard to
> >> implement, and that's very hard to test. I certainly wanted to do
> >> bit-exact input and output of FP numbers in Gforth, and I don't
> >> think we have achieved that (certainly not on all platforms); I
> >> looked around for (C) code to do that, but what I found did not
> >> inspire much trust.
> >
> >I've had a lot of positive experiences with the floating-point IO in
> >fdlibm. AFAIK it does bit-exact input and output of FP numbers in all
> >cases.
> I found an fdlibm at <http://www.netlib.org/fdlibm/>, but I don't see
> any IO or conversion functions there. Am I blind?
I hope not! The I/O routines I use are at
http://gcc.gnu.org/svn/gcc/trunk/libjava/classpath/native/\
fdlibm/{strtod,dtoa}.c
And, as you say, they seem not to be part of fdlibm.
> >> They are expensive to implement on many platforms due to alignment
> >> considerations. Also, if a system has FP, it will likely also have
> >> locals, so the better alternative IMO is to standardize FP locals.
> >
> >Well, they're not exactly alternatives, but I take your point. I'm
> >not convinced that F>R is more expensive than a local. It seems very
> >un-Forth to provide a locals words to do the job but not a stack
> >version!
> The performance issue is: If the FP value has higher alignment
> requirements than a cell (e.g., on 32-bit SPARC or MIPS; not sure
> about ARM), then a simple return stack implementation has to first
> store the FP value in some temporary place and then copy it to the
> return stack in cell-sized pieces.
Yes, or add some variable size padding for later removal. Tricky
either way, but I am still not convinced less tricky than a
floating-point local.
Andrew.
Anton Ertl
>
> The DPANS94 specification is that of >FLOAT, extended to
> include special numbers, with modified syntax. [**Rounding?]
I would just go with extending >FLOAT, unless one of the following
conditions holds:
* The extension conflicts with the existing definition of >FLOAT.
* The extension conflicts with an existing implementation of >FLOAT,
and the implementator cannot be convinced to change or resolve the
conflict in some other way, and the implementation is significant.
>FREPRESENT ( f: r s: c-addr u -- n flag1 flag2 )
>
> The specification is basically that of DPANS94 for REPRESENT,
Likewise, this should just be an extension of REPRESENT.
>[**Do we want a CREATE-NALIGNED?]
Actually Gforth maxaligns the bodies of all words (it would really
only be necessary for CREATE and FVARIABLE). One should certainly
think about requiring that for CREATE and ALLOCATE, and maybe have
MAXALIGN and MAXALIGNED words. But that's stuff for another RfD.
>6.7 Comparison
>--------------
...
> Whether the "invalid" exception is raised for nans is
> implementation dependent.
What is current practice here? Gforth does not raise an exception.
NaNs just don't compare (i.e., any comparison with them gives FALSE).
>6.8 Arithmetic
>--------------
>
>F* ( f: r1 r2 -- r1*r2 )
>F*+ ( f: r1 r2 r3 -- [r2*r3]+r1 ) new
>F+ ( f: r1 r2 -- r1+r2 )
>F- ( f: r1 r2 -- r1-r2 )
>F/ ( f: r1 r2 -- r1/r2 )
>FNEGATE ( f: r -- -r )
>
> The DPANS94 specification is extended to IEEE arithmetic. See
> Annex F for details on special numbers and exceptions.
Appendix F of what? I don't see such an appendix in the RfD.
>6.13 Floating-point environment
>-------------------------------
...
>6.13.1 Exceptions
>-----------------
It's not clear to me that this is needed, and if so, for what.
Even if the functionality is needed, I wonder if there is a better way
to map it to Forth.
>6.13.2 Rounding modes
>---------------------
I wonder how often other rounding modes than round-to-nearest are
needed.
Anton Ertl
>Now (2008) it says "The choice of which of this
>standard's formats to support is language-defined or, if the relevant
>language standard is silent or defers to the implementation,
>implementation-defined." So, we don't have to support single or
>double AIUI, except as interchange formats as required by Standard
>Forth.
Yes, I think that's the way to go. Disadvantage: We won't get bitwise
equivalence of results between platforms with different on-stack
representations, but as long as 387-only platforms are relevant, we
won't get that anyway.
BTW, since you have some knowledge in Java: AFAIK They very much
wanted to have bitwise equivalence. How do they deal with the 387?
Andrew Haley
> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
> >Now (2008) it says "The choice of which of this
> >standard's formats to support is language-defined or, if the relevant
> >language standard is silent or defers to the implementation,
> >implementation-defined." So, we don't have to support single or
> >double AIUI, except as interchange formats as required by Standard
> >Forth.
> Yes, I think that's the way to go. Disadvantage: We won't get bitwise
> equivalence of results between platforms with different on-stack
> representations, but as long as 387-only platforms are relevant, we
> won't get that anyway.
> BTW, since you have some knowledge in Java: AFAIK They very much
> wanted to have bitwise equivalence. How do they deal with the 387?
The Java spec requires IEEE double and single, so the Precision
Control Field of the FPU control word is set to double and single as
required.
There is a Java keyword "strictfp" which makes expressions FP-strict.
Expressions that are FP-strict must be evaluated according to the IEEE
rules, but these are expensive; expressions that are not FP-strict may
use a larger exponent than IEEE allows. For example,, setting the
Precision Control Field to 53 bits gets you non-strict Java double
compliance.
[OT: You're probably aware of this explanation of why Java's approact
to floating-point is wrong:
http://www.eecs.berkeley.edu/~wkahan/JAVAhurt.pdf]
Andrew.
David N. Williams
> Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>>> Now (2008) it says "The choice of which of this
>>> standard's formats to support is language-defined or, if the relevant
>>> language standard is silent or defers to the implementation,
>>> implementation-defined." So, we don't have to support single or
>>> double AIUI, except as interchange formats as required by Standard
>>> Forth.
>
>> Yes, I think that's the way to go. Disadvantage: We won't get bitwise
>> equivalence of results between platforms with different on-stack
>> representations, but as long as 387-only platforms are relevant, we
>> won't get that anyway.
See the remark below about predictability.
>> BTW, since you have some knowledge in Java: AFAIK They very much
>> wanted to have bitwise equivalence. How do they deal with the 387?
>
> The Java spec requires IEEE double and single, so the Precision
> Control Field of the FPU control word is set to double and single as
> required.
>
> There is a Java keyword "strictfp" which makes expressions FP-strict.
> Expressions that are FP-strict must be evaluated according to the IEEE
> rules, but these are expensive; expressions that are not FP-strict may
> use a larger exponent than IEEE allows. For example,, setting the
> Precision Control Field to 53 bits gets you non-strict Java double
> compliance.
>
> [OT: You're probably aware of this explanation of why Java's approact
> to floating-point is wrong:
> http://www.eecs.berkeley.edu/~wkahan/JAVAhurt.pdf]
Actually, this isn't that much OT for the discussion in general.
Here's a quote from page 19:
How many significantly different floating-point hardware
architectures matter today?
Four :
#0: Signal processors that may provide float and/or
float-extended but not double.
#1: RISC-based computers that provide 4-byte float and
8-byte double but nothing wider.
#2: Power-PC; MIPS R-10000; H-P 8000 : same as #1 plus fused
multiply-add operation.
#3: Intel x86, Pentium; clones by AMD and Cyrix; Intel
80960KB; new Intel/HP IA-64; and Motorola 680x0 and
88110: the same as #1 plus a 10+-byte long double.
Over 95% of the computers on desktops have architecture #3.
Most of the rest have #2. Both #3 and #2 can be and are used
in restricted ways that match #1 as nearly as matters. All of
#1, #2, #3 support Exception Flags and Directed Roundings,
capabilities mandated by IEEE Standard 754 but generally
omitted from architecture #0 because they have little value in
its specialized market.
Kahan goes into a lot of detail in the following pages about the
rationale for the exceptions part of the floating-point
environment. I haven't checked yet whether IEEE 754 still
*requires* exceptions and roundings.
I see other relevant stuff in that article, such as his advocacy
of controlled versus exact predictability (e.g., see page 17).
-- David
Anton Ertl
>Andrew Haley wrote:
> > [OT: You're probably aware of this explanation of why Java's approact
> > to floating-point is wrong:
> > http://www.eecs.berkeley.edu/~wkahan/JAVAhurt.pdf]
>
>Actually, this isn't that much OT for the discussion in general.
Yes, parts of it are very on-topic for the discussion at hand, because
it's not very specific to Java, but (among other things) how the
authors of that work think that languages in general should integrate
FP (and particularly IEEE FP).
Andrew Haley
> Four :
Not any more. In 64-bit mode, Linux gcc has floats and doubles plus
128-bit long doubles via the MMX architecture, and mostly ignores the
x87 extended precision. I'm not sure if 64-bit Windows does the same
thing.
> Most of the rest have #2. Both #3 and #2 can be and are used
> in restricted ways that match #1 as nearly as matters. All of
> #1, #2, #3 support Exception Flags and Directed Roundings,
> capabilities mandated by IEEE Standard 754 but generally
> omitted from architecture #0 because they have little value in
> its specialized market.
> Kahan goes into a lot of detail in the following pages about the
> rationale for the exceptions part of the floating-point
> environment. I haven't checked yet whether IEEE 754 still
> *requires* exceptions and roundings.
For FPU exceptions, IEEE-compatible FPUs have a status word that can
be interrogated, and this is AFAIK all that's needed. Hardware FPUs I
am aware of also allow control over roundings, but I'm a bit nervous
about requiring it in this specification. It's something to ask
implementers about.
The 2008 IEEE spec uses some language which is IMO quite
inappropriate: that attributes like rounding mode may be specified for
all standard operations in a block. But what if a language is not
block-structured? This requirement makes no sense for Forth IMO.
Dynamic modes make more sense, but even then this may not be
achievable, and I assume we do not want to make software
implementations impractical.
All things considered, I'm wondering if the 2008 version of 754 is
just too much. It's a bloated uber-specification that tries to
control far more than the 1985 version. In particular, it intrudes
into high-level languge issues, as noted above.
> I see other relevant stuff in that article, such as his advocacy
> of controlled versus exact predictability (e.g., see page 17).
Well, it is relevant, but let's not get carried away. Forth already
has a lot of implementations on IEEE-compatible hardware, and it would
not be wise to try to redesign these systems. But I think most of
them are fairly close anyway.
Andrew.
Ed
> Anton suggested the entire document should be posted to
> facilitate discussion, not just the link. It's below.
IEEE is not of particular interest so take these as general observations.
> ...
> 6. The syntax specification in DPANS94 12.3.7, "Text input number
> conversion", shall be replaced by
> ...
> <significand> := [<sign>]{<digits>[.<digits0>]|.<digits>}
> [**Note the extra .<digits> option.]
FVG (Forth Vendors Group) f/p allowed it and FTRAN requires it.
It's handy but does anyone know why '94 rejected leading decimal
points? Could it be confused with some other input?
I note F. also requires at least one digit before the decimal pt.
Are these requirements linked?
> <special> := [<sign>]{<inf>|<nan>}
Does one ever need to input nan/inf strings? Do other languages
allow/expect it?
If not, would having nan/inf as constants be more useful?
> ...
> >F ( c-addr u -- r: r s: flag )
>
> The DPANS94 specification is that of >FLOAT, extended to
> include special numbers, with modified syntax. [**Rounding?]
>
> A string of blanks [**or the empty string?] should be treated
> as +0. [**Allow formatting blanks or characters?]
>
> Syntax of a convertible string := {<significand>[exponent]
> |<special>}
> ...
> <special> := [<sign>]{<inf>|<nan>}
> <inf> := {Inf|inf|INF}
> <nan> := {NaN|nan|NAN}
As with the text interpreter, does one need to input nan/inf strings?
If not then >FLOAT is fine as it is.
Should an application want to input nan/inf strings then perhaps
provide the tools to do it. I've mentioned nan/inf constants, so:
: >F
2dup s" +NAN" caps-compare 0= if 2drop +nan true exit then
2dup s" -NAN" caps-compare 0= if 2drop -nan true exit then
2dup s" +INF" caps-compare 0= if 2drop +inf true exit then
2dup s" -INF" caps-compare 0= if 2drop -inf true exit then
>float ;
This would require a caps-compare function but it's generally useful
anyway.
> >DF >SF
Shouldn't be necessary.
I would expect systems that support IEEE single or double format
to have an internal precision at least equal to these. Consequently
one need only use SF@ DF@ etc before >FLOAT
> ...
> FREPRESENT ( f: r s: c-addr u -- n flag1 flag2 )
>
> The specification is basically that of DPANS94 for REPRESENT,
> extended to include signed zero for r. The valid-result flag,
> flag2, is false if r is infinity or a nan.
> [**The new name is for consistency with the format
> nomenclature, but also presents an opportunity to tighten the
> specification of REPRESENT.]
Is it only nan/inf strings that can be returned when flag2=0 ?
Perhaps the full list of possible IEEE returns needs to be
specified.
Also not mentioned is whether the sign, if any, should be
embedded in the string (it must for portability).
flag1 could hold the sign when flag2=0 but this would be of no
use to portable apps as they can't use it. Would it be of use to
IEEE apps?
I'm aware of two forths that currently don't embed the sign in the
string. Were they were prepared to do so, there would be no
need for a new function or name.
>
> DFREPRESENT SFREPRESENT
Again not necessary. See previous comment for >DF >SF
Ed
>
> [..]
>
> > FMANT-DIG ( -- p )
> > FEXP-MAX ( -- emax )
> > FEXP-MIN ( -- emin )
>
> IMO these are really unnecessary.
If FMANT-DIG is what I assume then every f/p forth already
has it e.g. #fdigits in VFX, 17 decimal in SwiftForth etc.
Portable apps need to know it in order to make informed
decisions for REPRESENT and SET-PRECISION.
I proposed it as environment string MAX-FLOAT-DIGITS.
FVG had a similar (?) value called F#PLACES.
FEXP-MAX
FEXP-MIN
A portable app might need to know the dynamic range of a system.
FEXP-MAX could be calculated from environment string
MAX-FLOAT but it's messy. Constants are easier.
However the names could be confused with function FEXP.
Andrew Haley
> "David N. Williams" <will...@umich.edu> writes:
> > >F ( c-addr u -- r: r s: flag )
> >
> > The DPANS94 specification is that of >FLOAT, extended to
> > include special numbers, with modified syntax. [**Rounding?]
> I would just go with extending >FLOAT, unless one of the following
> conditions holds:
> * The extension conflicts with the existing definition of >FLOAT.
> * The extension conflicts with an existing implementation of >FLOAT,
> and the implementator cannot be convinced to change or resolve the
> conflict in some other way, and the implementation is significant.
I agree. As long as input can be *accurate*, we don't need to change
the existing syntax. We'd run the risk of breaking existing code.
> >FREPRESENT ( f: r s: c-addr u -- n flag1 flag2 )
> >
> > The specification is basically that of DPANS94 for REPRESENT,
> Likewise, this should just be an extension of REPRESENT.
> >[**Do we want a CREATE-NALIGNED?]
> Actually Gforth maxaligns the bodies of all words (it would really
> only be necessary for CREATE and FVARIABLE). One should certainly
> think about requiring that for CREATE and ALLOCATE, and maybe have
> MAXALIGN and MAXALIGNED words. But that's stuff for another RfD.
> >6.7 Comparison
> >--------------
> ...
> > Whether the "invalid" exception is raised for nans is
> > implementation dependent.
> What is current practice here? Gforth does not raise an exception.
> NaNs just don't compare (i.e., any comparison with them gives FALSE).
Be careful here: "Raise an exception" in IEEE FP does not mean
actually raise an exception or cause a trap. 754-2008 says "Note that
event, exception, and signal are defined in diverse ways in different
programming environments".
> >6.13 Floating-point environment
> >-------------------------------
> ...
> >6.13.1 Exceptions
> >-----------------
> It's not clear to me that this is needed, and if so, for what.
> Even if the functionality is needed, I wonder if there is a better way
> to map it to Forth.
I think the best way is to be able to query the status with
approppriate words such ad INVALID? OVERFLOW? and INEXACT?.
Andrew.
David N. Williams
> Marcel Hendrix wrote:
>> [..]
>>
>>> FMANT-DIG ( -- p )
>>> FEXP-MAX ( -- emax )
>>> FEXP-MIN ( -- emin )
>> IMO these are really unnecessary.
>
> If FMANT-DIG is what I assume then every f/p forth already
> has it e.g. #fdigits in VFX, 17 decimal in SwiftForth etc.
Unfortunately, it's defined too far away for convenience (in the
terminology and notation section); p is the number of binary
digits, including any leading invisible bit, part of the IEEE
parametrization of binary formats.
> Portable apps need to know it in order to make informed
> decisions for REPRESENT and SET-PRECISION.
>
> I proposed it as environment string MAX-FLOAT-DIGITS.
> FVG had a similar (?) value called F#PLACES.
>
> FEXP-MAX
> FEXP-MIN
>
> A portable app might need to know the dynamic range of a system.
> FEXP-MAX could be calculated from environment string
> MAX-FLOAT but it's messy. Constants are easier.
> However the names could be confused with function FEXP.
I agree that the names are confusing. I would have used
FMAX-EXP and FMIN-EXP as names, based on C99, but those are off
by one compared to the IEEE definition of emax and emin, which I
found more understandable.
The definition in the proposal is
----------
Each IEEE bfp format has three fixed parameters, p > 0
(precision), emax > 0 (maximim exponent), and emin < 0 (minimum
exponent), and 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 = #signifcand bits.
----------
For IEEE doubles, emax = +1023, emin = �1022.
The C99 definition (5.2.4.2.2) is
----------
A floating-point number (x) is defined by the following model:
x = s * b^e sum_{k=1}^p f_k * b^{k}, emin <= e <= emax
----------
where s = +/-1, and b = 2 in our case. Then emax = +1024,
emin = -1021.
If these words are kept, what about one of these two
possibilities?
1. Use the IEEE definition with the names FMAX-EXP and FMIN-EXP,
plus a prominent statement that the numbers are off by one from
C99.
2. Use the C99 definition with the above names.
-- David
Anton Ertl
>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>> "David N. Williams" <will...@umich.edu> writes:
>> > >F ( c-addr u -- r: r s: flag )
>> >
>> > The DPANS94 specification is that of >FLOAT, extended to
>> > include special numbers, with modified syntax. [**Rounding?]
>
>> I would just go with extending >FLOAT, unless one of the following
>> conditions holds:
>
>> * The extension conflicts with the existing definition of >FLOAT.
>
>> * The extension conflicts with an existing implementation of >FLOAT,
>> and the implementator cannot be convinced to change or resolve the
>> conflict in some other way, and the implementation is significant.
>
>I agree. As long as input can be *accurate*, we don't need to change
>the existing syntax. We'd run the risk of breaking existing code.
I don't see how existing programs would be broken by adding >F, but
there are other unpleasant consequences. E.g., a new program would
have to decide whether to use >FLOAT or >F, with >FLOAT being more
portable and >F being more capable.
>> >6.7 Comparison
>> >--------------
>> ...
>> > Whether the "invalid" exception is raised for nans is
>> > implementation dependent.
>
>> What is current practice here? Gforth does not raise an exception.
>> NaNs just don't compare (i.e., any comparison with them gives FALSE).
>
>Be careful here: "Raise an exception" in IEEE FP does not mean
>actually raise an exception or cause a trap. 754-2008 says "Note that
>event, exception, and signal are defined in diverse ways in different
>programming environments".
I think the use of "exception" by IEEE 754 is unfortunate, because
that's a name of a different, though related concept, in a lot of
programming languages. In particular, we have exceptions in Forth
already. So the proposal at hand should probably introduce a
different name for the concept, note what the relation to concepts in
IEEE 754 is, and then use that name exclusively.
>> >6.13.1 Exceptions
>> >-----------------
>
>> It's not clear to me that this is needed, and if so, for what.
>
>> Even if the functionality is needed, I wonder if there is a better way
>> to map it to Forth.
In the meantime it is clear to me what this is for (based on reading
the comments by Kahan and Darcy with the Java title).
>I think the best way is to be able to query the status with
>approppriate words such ad INVALID? OVERFLOW? and INEXACT?.
Yes.
An additional possible feature (if supported by hardware and OS) would
be a program-configurable way to actually turn the raising of an IEEE
exception into the throwing of a Forth exception.
I'm not sure that either feature will be used enough to implement more
than one, and the status-polling is certainly the simpler one. Maybe
if some programmers demand the throwing variant, some systems can
implement it, and we can gain some experience before standardizing it.
Anton Ertl
>David N. Williams <will...@umich.edu> wrote:
>> Andrew Haley wrote:
>> > http://www.eecs.berkeley.edu/~wkahan/JAVAhurt.pdf]
>
>> Actually, this isn't that much OT for the discussion in general.
>> Here's a quote from page 19:
>> #3: Intel x86, Pentium; clones by AMD and Cyrix; Intel
>> 80960KB; new Intel/HP IA-64; and Motorola 680x0 and
>> 88110: the same as #1 plus a 10+-byte long double.
>
>> Over 95% of the computers on desktops have architecture #3.
>
>Not any more. In 64-bit mode, Linux gcc has floats and doubles plus
>128-bit long doubles via the MMX architecture, and mostly ignores the
>x87 extended precision.
But the 387 stuff is still there.
> I'm not sure if 64-bit Windows does the same
>thing.
The work above complains that Windows already cuts the 387 back to
53-bit mantissae in its 32-bit incarnation.
>For FPU exceptions, IEEE-compatible FPUs have a status word that can
>be interrogated, and this is AFAIK all that's needed. Hardware FPUs I
>am aware of also allow control over roundings, but I'm a bit nervous
>about requiring it in this specification. It's something to ask
>implementers about.
As an implementor, I would be interested to know what programmers
think about it. Kahan makes a case for having it, but as in many of
his examples I can't help wondering how general that stuff is, and if
anyone but Kahan and a few faithful want to use it (and as long as
they don't switch to Forth, we would be adding these features for
nobody).
>The 2008 IEEE spec uses some language which is IMO quite
>inappropriate: that attributes like rounding mode may be specified for
>all standard operations in a block. But what if a language is not
>block-structured? This requirement makes no sense for Forth IMO.
I have not read that part, but I guess the "block" is just a way to
specify a range of code. That's pretty easy to map into Forth (with a
ROUNDING...END-ROUNDING construct), and one would typically do it in a
way such that the range can be entered only at the start and exited
only at the end or through a thrown exception, i.e., the equivalent of
a block in block-structured languages.
>Dynamic modes make more sense, but even then this may not be
>achievable, and I assume we do not want to make software
>implementations impractical.
Why would it not be achievable?
The FP environment stuff of C99 looks both relatively complex and not
very well designed (wrt controlling rounding mode changes), though. I
wonder what the point of the complexity is.
For controlling the rounding mode dynamically, I would just have a
dynamic-scoping-style word for that to avoid having another global
state that easily affects parts of the code that were not intended to
be affected. E.g., something like
ROUNDING-EXECUTE ( ... rounding-mode xt -- ... )
which ensures that the rounding mode is restored when the word is left
even if it is left through throwing an exception.
Andrew Haley
> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
> >David N. Williams <will...@umich.edu> wrote:
> >> Andrew Haley wrote:
> >> > http://www.eecs.berkeley.edu/~wkahan/JAVAhurt.pdf]
> >
> >> Actually, this isn't that much OT for the discussion in general.
> >> Here's a quote from page 19:
> ...
> >> #3: Intel x86, Pentium; clones by AMD and Cyrix; Intel
> >> 80960KB; new Intel/HP IA-64; and Motorola 680x0 and
> >> 88110: the same as #1 plus a 10+-byte long double.
> >
> >> Over 95% of the computers on desktops have architecture #3.
> >
> >Not any more. In 64-bit mode, Linux gcc has floats and doubles plus
> >128-bit long doubles via the MMX architecture, and mostly ignores the
> >x87 extended precision.
> But the 387 stuff is still there.
It's still there, but mostly unused. So it doesn't matter what it
does.
> > I'm not sure if 64-bit Windows does the same
> >thing.
> The work above complains that Windows already cuts the 387 back to
> 53-bit mantissae in its 32-bit incarnation.
> >For FPU exceptions, IEEE-compatible FPUs have a status word that can
> >be interrogated, and this is AFAIK all that's needed. Hardware FPUs I
> >am aware of also allow control over roundings, but I'm a bit nervous
> >about requiring it in this specification. It's something to ask
> >implementers about.
> As an implementor, I would be interested to know what programmers
> think about it. Kahan makes a case for having it, but as in many of
> his examples I can't help wondering how general that stuff is, and
> if anyone but Kahan and a few faithful want to use it (and as long
> as they don't switch to Forth, we would be adding these features for
> nobody).
Well, it helps you to write interval arithmetic, and interval
arithmetic is useful in a pretty wide range of applications. Having
said that, In general I accept your point.
> >The 2008 IEEE spec uses some language which is IMO quite
> >inappropriate: that attributes like rounding mode may be specified for
> >all standard operations in a block. But what if a language is not
> >block-structured? This requirement makes no sense for Forth IMO.
> I have not read that part, but I guess the "block" is just a way to
> specify a range of code.
Right, but in a dynamic language, what's a range? It seems to me that
a range in Forth is an extent in time, not an extent in lexical scope.
> >Dynamic modes make more sense, but even then this may not be
> >achievable, and I assume we do not want to make software
> >implementations impractical.
> Why would it not be achievable?
I don't know that all floating-point packages (hw/sw combinations)
that might want to be compatible with this proposed extension will
have the ability to use all the rounding modes. Maybe some systems
don't even have all the modes.
However, if setting the rounding mode is always just a trivial matter
of setting a status bit, then I think we should consider requiring the
implementations to provide words to do that.
> The FP environment stuff of C99 looks both relatively complex and not
> very well designed (wrt controlling rounding mode changes), though. I
> wonder what the point of the complexity is.
Indeed. However, if it can be done without heroic effort, IMO a
reasonable subset that allows one to change modes would be useful.
> For controlling the rounding mode dynamically, I would just have a
> dynamic-scoping-style word for that to avoid having another global
> state that easily affects parts of the code that were not intended to
> be affected. E.g., something like
> ROUNDING-EXECUTE ( ... rounding-mode xt -- ... )
> which ensures that the rounding mode is restored when the word is left
> even if it is left through throwing an exception.
Isn't that just
@mode >r ['] foo catch r> !mode
?
Andrew.
David N. Williams
> David N. Williams wrote:
>> [...]
> [...]
>
>> <special> := [<sign>]{<inf>|<nan>}
>
> allow/expect it?
C99 defines NAN and INFINITY as constant expression macros, so
they can appear with signs in the text of an expression. In
writing code for a function, one needs to be able to specify
nans or infinities as special results, or as inputs to steps in
the calculation, and I think one ought to be able to include nan
loads as well. The intepretation of loads is not specified by
IEEE, but there's an implication that they should be available
for an application to use as it pleases.
> If not, would having nan/inf as constants be more useful?
I wondered about that, too. It's a problem if nan loads are to
be allowed.
>> ...
>> >F ( c-addr u -- r: r s: flag )
>>
>> The DPANS94 specification is that of >FLOAT, extended to
>> include special numbers, with modified syntax. [**Rounding?]
>>
>> A string of blanks [**or the empty string?] should be treated
>> as +0. [**Allow formatting blanks or characters?]
>>
>> Syntax of a convertible string := {<significand>[exponent]
>> |<special>}
>> ...
>> <special> := [<sign>]{<inf>|<nan>}
>> <inf> := {Inf|inf|INF}
>> <nan> := {NaN|nan|NAN}
>
> As with the text interpreter, does one need to input nan/inf strings?
> If not then >FLOAT is fine as it is.
I'm thinking, since >DF and >SF are being removed, just extend the
definition of >FLOAT to whatever is finally agreed upon.
> Should an application want to input nan/inf strings then perhaps
> provide the tools to do it. I've mentioned nan/inf constants, so:
>
> : >F
> 2dup s" +NAN" caps-compare 0= if 2drop +nan true exit then
> 2dup s" -NAN" caps-compare 0= if 2drop -nan true exit then
> 2dup s" +INF" caps-compare 0= if 2drop +inf true exit then
> 2dup s" -INF" caps-compare 0= if 2drop -inf true exit then
> >float ;
>
> This would require a caps-compare function but it's generally useful
> anyway.
Not a bad idea. I lean towards letting >FLOAT do the
interpretation, since it's supposed to be omnivorous. :-)
>> >DF >SF
>
> Shouldn't be necessary.
Already gone! :-)
>> ...
>> FREPRESENT ( f: r s: c-addr u -- n flag1 flag2 )
>>
>> The specification is basically that of DPANS94 for REPRESENT,
>> extended to include signed zero for r. The valid-result flag,
>> flag2, is false if r is infinity or a nan.
>> [**The new name is for consistency with the format
>> nomenclature, but also presents an opportunity to tighten the
>> specification of REPRESENT.]
>
> Is it only nan/inf strings that can be returned when flag2=0 ?
> Perhaps the full list of possible IEEE returns needs to be
> specified.
No, flag2 would also be 0 in all the cases it could before. But
now I'm inclined to agree with Marcel that it's better to just
use REPRESENT with its definition expanded to convert signed
zero, infinity, and nan. That raises the question of nan loads.
> Also not mentioned is whether the sign, if any, should be
> embedded in the string (it must for portability).
Yes, it should be mentioned explicitly.
> flag1 could hold the sign when flag2=0 but this would be of no
> use to portable apps as they can't use it. Would it be of use to
> IEEE apps?
I'd prefer to have the sign embedded in the output string.
> I'm aware of two forths that currently don't embed the sign in the
> string. Were they were prepared to do so, there would be no
> need for a new function or name.
Right, I think that's the way to go.
>> DFREPRESENT SFREPRESENT
>
> Again not necessary. See previous comment for >DF >SF
Yep!
-- David
Bernd Paysan
> Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> > Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>> >David N. Williams <will...@umich.edu> wrote:
>> >> Organizing corrections is going to be tricky.
>> >
>> >We really need a Wiki for this.
>
>> If you want to have multiple people editing this, my suggestion would
>> be a version control system.
>
> A Wiki is a version control system, just easier to use.
Anyway, if you need a Wiki for Forth-related stuff, either use Forth
eV's wiki (www.forth-ev.de/wiki), or Forthfreak's Wiki
(www.forthfreak.net).
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Thomas Pornin
> I also wanted to check the claim (IIRC by Marcel) that functions like
> FSIN have to produce the closest FP number to the real result as
> result
IEEE 754 does not mandate implementation of transcendental functions.
Apart from the basic operations (addition, subtraction, multiplication
and division), and the conversion routines between types, IEEE 754
mandates only square root and a fused add/mul (I'm not even sure it
mandates the latter).
Actually IEEE 754 does not says much on transcendental functions. Usual
implementations do not guarantee correct rounding. Some guarantee less
than 1 ulp, but on a restricted range (e.g. between 0 and pi/2 for sine)
and it can still be off on the last bit. It seems that correct rounding
of transcendental functions is not easy, but some people are working on
it:
http://lipforge.ens-lyon.fr/www/crlibm/
If you are not after the "mathematically correct rounding" but just want
a good result, then you can look at fdlibm:
ftp://ftp.netlib.org/fdlibm.tar
> but the document is not clear enough to be sure of that (at least not
> in the time I spent on that).
You have to read the whole of it once. When I say that it is quite
understandable, I mean that reading it once should be enough. I
daily fight against other standards, most notably X.509, where reading
five times is not enough to grasp what is going on.
--Thomas Pornin
Ed
> Ed wrote:
> > David N. Williams wrote:
> ...
> definition of >FLOAT to whatever is finally agreed upon.
>
> > Should an application want to input nan/inf strings then perhaps
> > provide the tools to do it. I've mentioned nan/inf constants, so:
> >
> > : >F
> > 2dup s" +NAN" caps-compare 0= if 2drop +nan true exit then
> > 2dup s" -NAN" caps-compare 0= if 2drop -nan true exit then
> > 2dup s" +INF" caps-compare 0= if 2drop +inf true exit then
> > 2dup s" -INF" caps-compare 0= if 2drop -inf true exit then
> > >float ;
> >
> > This would require a caps-compare function but it's generally useful
> > anyway.
>
> Not a bad idea. I lean towards letting >FLOAT do the
> interpretation, since it's supposed to be omnivorous. :-)
Let's see if I can disuade you from such a view!
As discussed in a previous thread extending >FLOAT reduces its
ability to discriminate bad input. No-one as yet has been able to
show any gain to counter-balance the loss. In contrast, methods
exist that allow extension without compromising >FLOAT .
Permitting >FLOAT to accept Nan/Inf is particularly ill-considered
as programs can then no longer discriminate between numbers and
non-numbers - with disastrous effect. Consider the following:
I have an f/p program. It has no need for nan/inf input, nor are
they likely to be generated.
The program takes an f/p number via >FLOAT. It then normalizes
it to the range 0.1 ... 1.0 by doing a comparison test and dividing/
multiplying by 10.0 as needed.
The program works fine ... until someone whose >FLOAT happens
to support nan/inf. They input these non-numbers and the program
hangs in an infinite loop attempting to normalize it.
No doubt other such examples could be found. IMO it is a
fundamental error to regard numbers and non-numbers as equals.
The reason why REPRESENT flags non-numbers differently is
because they are (different).
Adding Nan/Inf to the text interpreter or as dictionary constants,
however, is "less bad" because forth users are accustomed to
crashing the forth interpreter with ill-considered input :)
> >> ...
> >> FREPRESENT ( f: r s: c-addr u -- n flag1 flag2 )
> >>
> >> The specification is basically that of DPANS94 for REPRESENT,
> >> extended to include signed zero for r. The valid-result flag,
> >> flag2, is false if r is infinity or a nan.
> >> [**The new name is for consistency with the format
> >> nomenclature, but also presents an opportunity to tighten the
> >> specification of REPRESENT.]
> >
> > Is it only nan/inf strings that can be returned when flag2=0 ?
> > Perhaps the full list of possible IEEE returns needs to be
> > specified.
>
> No, flag2 would also be 0 in all the cases it could before. But
> now I'm inclined to agree with Marcel that it's better to just
> use REPRESENT with its definition expanded to convert signed
> zero, infinity, and nan. That raises the question of nan loads.
I meant other non-numbers e.g. "unsupported", "empty", "denormal"
on x87 hardware. If IEEE defines them (?) then should not the
proposal also specify them as potential REPRESENT output?
Marcel Hendrix
[..]
> I have an f/p program. It has no need for nan/inf input, nor are
> they likely to be generated.
> The program takes an f/p number via >FLOAT. It then normalizes
> it to the range 0.1 ... 1.0 by doing a comparison test and dividing/
> multiplying by 10.0 as needed.
> The program works fine ... until someone whose >FLOAT happens
> to support nan/inf. They input these non-numbers and the program
> hangs in an infinite loop attempting to normalize it.
> No doubt other such examples could be found.
Even without explicit input of "Inf" your program won't work as
described with current >FLOATs:
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
1e1024 f. Inf ok
s" 1e1024" >float . f. -1 Inf ok
s" Inf" >float . f. 0 0.
:19: Floating-point stack underflow
s" Inf" >float . >>>f.<<<
Backtrace:
$7FBA2C08 throw
iForth version 3.0.3, generated 17:21:51, May 30, 2009.
x86_32 binary, native floating-point, double precision.
Copyright 1996 - 2009 Marcel Hendrix.
FORTH> s" -1e1024" >float
[1]{1}FORTH> . f. -1 -INF ok
SwiftForth i386-Win32 3.1.3 29-Feb-2008
CHOOSE-OPTIONS ok
INCLUDING-OPTION C:\ForthInc\SWIFTFORTH\LIB\OPTIONS\` fpmath.f ok
s" -1e5024" >float . fs. -1 FLOAT_OVERFLOW
( SwiftForth apparently isn't able to print +Inf.
The error is in fs., not in >float )
-marcel
Andrew Haley
> According to Anton Ertl <an...@mips.complang.tuwien.ac.at>:
> > I also wanted to check the claim (IIRC by Marcel) that functions like
> > FSIN have to produce the closest FP number to the real result as
> > result
> IEEE 754 does not mandate implementation of transcendental
> functions. Apart from the basic operations (addition, subtraction,
> multiplication and division), and the conversion routines between
> types, IEEE 754 mandates only square root and a fused add/mul (I'm
> not even sure it mandates the latter).
754-2008 requires fused add/mul. It's a really good idea to have
this if at all possible.
> Actually IEEE 754 does not says much on transcendental functions. Usual
> implementations do not guarantee correct rounding. Some guarantee less
> than 1 ulp, but on a restricted range (e.g. between 0 and pi/2 for sine)
> and it can still be off on the last bit. It seems that correct rounding
> of transcendental functions is not easy, but some people are working on
> it:
> http://lipforge.ens-lyon.fr/www/crlibm/
Correct rounding will never be east, but the IBM Accurate Mathematical
Library, based on work by Abraham Ziv et al, [1] is part of glibc.
It's used on GNU/Linux systems and has done correct rounding of
elementary functions for some time. However, as Dinechin and Gast
point out [2] it has poor worst-case execution time.
Andrew.
[1] Fast evaluation of elementary mathematical functions with
correctly rounded last bit
ACM Transactions on Mathematical Software (TOMS)
Volume 17 , Issue 3 (September 1991)
pp: 410 - 423
1991
ISSN:0098-3500
Andrew Haley
> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
> >Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> >> "David N. Williams" <will...@umich.edu> writes:
> >> > >F ( c-addr u -- r: r s: flag )
> >> >
> >> > The DPANS94 specification is that of >FLOAT, extended to
> >> > include special numbers, with modified syntax. [**Rounding?]
> >
> >> I would just go with extending >FLOAT, unless one of the following
> >> conditions holds:
> >
> >> * The extension conflicts with the existing definition of >FLOAT.
> >
> >> * The extension conflicts with an existing implementation of >FLOAT,
> >> and the implementator cannot be convinced to change or resolve the
> >> conflict in some other way, and the implementation is significant.
> >
> >I agree. As long as input can be *accurate*, we don't need to change
> >the existing syntax. We'd run the risk of breaking existing code.
> I don't see how existing programs would be broken by adding >F, but
> there are other unpleasant consequences. E.g., a new program would
> have to decide whether to use >FLOAT or >F, with >FLOAT being more
> portable and >F being more capable.
Sorry, I musunderstood you. I think we should simply add NaN handling
etc to >FLOAT, along with a guarantee of correctly rounded I/O.
> >Be careful here: "Raise an exception" in IEEE FP does not mean
> >actually raise an exception or cause a trap. 754-2008 says "Note
> >that event, exception, and signal are defined in diverse ways in
> >different programming environments".
> I think the use of "exception" by IEEE 754 is unfortunate, because
> that's a name of a different, though related concept, in a lot of
> programming languages. In particular, we have exceptions in Forth
> already. So the proposal at hand should probably introduce a
> different name for the concept, note what the relation to concepts
> in IEEE 754 is, and then use that name exclusively.
I agree.
> An additional possible feature (if supported by hardware and OS)
> would be a program-configurable way to actually turn the raising of
> an IEEE exception into the throwing of a Forth exception.
> I'm not sure that either feature will be used enough to implement
> more than one, and the status-polling is certainly the simpler one.
> Maybe if some programmers demand the throwing variant, some systems
> can implement it, and we can gain some experience before
> standardizing it.
I think actually raising exceptions is too much for the current draft.
Andrew.
Andrew Haley
All this means is that your program needs to be improved for use on an
IEEE-compliant system.
> No doubt other such examples could be found. IMO it is a
> fundamental error to regard numbers and non-numbers as equals. The
> reason why REPRESENT flags non-numbers differently is because they
> are (different).
> Adding Nan/Inf to the text interpreter or as dictionary constants,
> however, is "less bad" because forth users are accustomed to
> crashing the forth interpreter with ill-considered input :)
But we'll still need a way to do I/O of NaNs and Infs. We either do
it by extending >FLOAT or defining a new word. I'm generally in
favour of extending existing functionality rather than defining new
words.
> > >> ...
> > >> FREPRESENT ( f: r s: c-addr u -- n flag1 flag2 )
> > >>
> > >> The specification is basically that of DPANS94 for REPRESENT,
> > >> extended to include signed zero for r. The valid-result flag,
> > >> flag2, is false if r is infinity or a nan.
> > >> [**The new name is for consistency with the format
> > >> nomenclature, but also presents an opportunity to tighten the
> > >> specification of REPRESENT.]
> > >
> > > Is it only nan/inf strings that can be returned when flag2=0 ?
> > > Perhaps the full list of possible IEEE returns needs to be
> > > specified.
> >
> > No, flag2 would also be 0 in all the cases it could before. But
> > now I'm inclined to agree with Marcel that it's better to just
> > use REPRESENT with its definition expanded to convert signed
> > zero, infinity, and nan. That raises the question of nan loads.
> I meant other non-numbers e.g. "unsupported", "empty", "denormal"
> on x87 hardware. If IEEE defines them (?) then should not the
> proposal also specify them as potential REPRESENT output?
I'm not sure what an unsupported or an empty number is. Denormals are
just numbers, and need no special hadling. The need to represent NaNs
and Infs in I/O is part of the interoperability requirements of IEEE
754. It doesn't specify any other types of number.
Andrew.
Anton Ertl
>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>
>> about the F** operation, and I also wanted to check the claim (IIRC
>> by Marcel) that functions like FSIN have to produce the closest FP
>
>I think this is "recommended" by IEEE-2008, but none of these
>functions are required.
I found the recommendation for many transcendental functions (but
nothing for the F** operation), but they were just enumerated, without
much speciofication about how they should behave. Thinking a little
bit about the "correct rounding" language suggests bit-accuracy to me.
And maybe one can extract the expected behaviour on boundary
conditions (like those in current CfVs) from somewhere in the text,
but it's not as obvious as I would have liked.
Anton Ertl
>I hope not! The I/O routines I use are at
>
>http://gcc.gnu.org/svn/gcc/trunk/libjava/classpath/native/\
>fdlibm/{strtod,dtoa}.c
That suggests that the copyright issues have already been cleared with
the FSF (have they?), which would make it easier to adapt this into
Gforth.
>> >Well, they're not exactly alternatives, but I take your point. I'm
>> >not convinced that F>R is more expensive than a local. It seems very
>> >un-Forth to provide a locals words to do the job but not a stack
>> >version!
>
>> The performance issue is: If the FP value has higher alignment
>> requirements than a cell (e.g., on 32-bit SPARC or MIPS; not sure
>> about ARM), then a simple return stack implementation has to first
>> store the FP value in some temporary place and then copy it to the
>> return stack in cell-sized pieces.
>
>Yes, or add some variable size padding for later removal. Tricky
>either way, but I am still not convinced less tricky than a
>floating-point local.
If you already have locals, adding FP locals (including padding) is
pretty straightforward, whereas dealing with padding on the return
stack is something pretty alien. There is a reason why Gforth has FP
locals, but not F>R FR>. And it's not just Gforth; the same is true
for iForth (even though alignment on the return stack is not an issue
there).
Anton Ertl
>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>> >David N. Williams <will...@umich.edu> wrote:
>> >> Andrew Haley wrote:
>> >> > http://www.eecs.berkeley.edu/~wkahan/JAVAhurt.pdf]
>> >
>> >> Actually, this isn't that much OT for the discussion in general.
>> >> Here's a quote from page 19:
>> ...
>> >> #3: Intel x86, Pentium; clones by AMD and Cyrix; Intel
>> >> 80960KB; new Intel/HP IA-64; and Motorola 680x0 and
>> >> 88110: the same as #1 plus a 10+-byte long double.
>> >
>> >> Over 95% of the computers on desktops have architecture #3.
>> >
>> >Not any more. In 64-bit mode, Linux gcc has floats and doubles plus
>> >128-bit long doubles via the MMX architecture, and mostly ignores the
>> >x87 extended precision.
>
>> But the 387 stuff is still there.
>
>It's still there, but mostly unused.
As far as Kahan's argument is concerned, it's there. His complaint is
that the software does not use the additional precision, even though
it's in the hardware. So gcc on AMD64 is another example of that.
BTW, I guess you mean SSE2, which uses the XMM registers, not MMX,
right?
>> >The 2008 IEEE spec uses some language which is IMO quite
>> >inappropriate: that attributes like rounding mode may be specified for
>> >all standard operations in a block. But what if a language is not
>> >block-structured? This requirement makes no sense for Forth IMO.
>
>> I have not read that part, but I guess the "block" is just a way to
>> specify a range of code.
>
>Right, but in a dynamic language, what's a range? It seems to me that
>a range in Forth is an extent in time, not an extent in lexical scope.
A range is whatever we specify. E.g., if we change the search order
during compilation, and later change it back, then the affected range
is the source code between the first change and the second change; if
you want, you can consider this as an extent in (compile) time, but
the effect corresponds very much to lexical/static things in other
programming languages.
As another example, locals in Forth don't do dynamic scoping, and
that's the right thing.
The occurences of "block" I have found in the IEEE 754:2008 document
(draft 1.2.9) are in Appendix E and deal with alternate IEEE-exception
handling modes. I don't know enough about how one might want to use
such features to tell whether it should be handled in a static way
(like locals) or in a dynamic way (like exceptions), but both
approaches are possible and established in Forth.
>I don't know that all floating-point packages (hw/sw combinations)
>that might want to be compatible with this proposed extension will
>have the ability to use all the rounding modes. Maybe some systems
>don't even have all the modes.
>
>However, if setting the rounding mode is always just a trivial matter
>of setting a status bit, then I think we should consider requiring the
>implementations to provide words to do that.
Yes, but the main words for user programs should be something safe
like ROUNDING-EXECUTE, or we produce another STATE, only this one is
much harder to notice and therefore more insidious.
>> For controlling the rounding mode dynamically, I would just have a
>> dynamic-scoping-style word for that to avoid having another global
>> state that easily affects parts of the code that were not intended to
>> be affected. E.g., something like
>
>> ROUNDING-EXECUTE ( ... rounding-mode xt -- ... )
>
>> which ensures that the rounding mode is restored when the word is left
>> even if it is left through throwing an exception.
>
>Isn't that just
>
> @mode >r ['] foo catch r> !mode
Not quite, but something along these lines.
Andrew Haley
> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
> >I hope not! The I/O routines I use are at
> >
> >http://gcc.gnu.org/svn/gcc/trunk/libjava/classpath/native/\
> >fdlibm/{strtod,dtoa}.c
> That suggests that the copyright issues have already been cleared with
> the FSF (have they?), which would make it easier to adapt this into
> Gforth.
I am not a lawyer, etc, but AFAICS the licence is quite permissive
enough.
Andrew.
David N. Williams
> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>> Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>>
>>> Not for the casual searcher. I wanted to check what it had to say
>>> about the F** operation, and I also wanted to check the claim (IIRC
>>> by Marcel) that functions like FSIN have to produce the closest FP
>>> number to the real result as result.
>> I think this is "recommended" by IEEE-2008, but none of these
>> functions are required.
>
> I found the recommendation for many transcendental functions (but
> nothing for the F** operation), but they were just enumerated, without
> much speciofication about how they should behave. Thinking a little
> bit about the "correct rounding" language suggests bit-accuracy to me.
> And maybe one can extract the expected behaviour on boundary
> conditions (like those in current CfVs) from somewhere in the text,
> but it's not as obvious as I would have liked.
Actually, the official IEEE-2008 document does include
recommendations for pow, and a lot of other functions not listed
in draft 1.2.9. It also has a lot more "shalls" than have been
discussed here, including comparisons, fp classification, etc.
I was able to get a pdf for free because the university has an
electronic subscription to ieeexplore. The pdf is pretty
convenient because its sections are bookmarked.
So I'm in the middle of a total, much simplified rewrite,
pretty much going with official IEEE-2008 for specs adopted "by
reference", instead of C99. C99 is mostly relegated to a few
informative comments (if any).
The good news is that IEEE does have recommendations for things
like nan and infinity in text input and output (IIRC draft 1.2.9
has those as well). The bad news is that a lot of the "shalls"
are things people here have expressed queasiness about.
For now, my approach is to include some of those, but mark them
as candidates for separate RfC's.
For now, my approach is to include some of those, but mark them
as candidates for separate RfC's.
-- David
Anton Ertl
>David N. Williams wrote:
>> Ed wrote:
>> > David N. Williams wrote:
>> ...
>> I'm thinking, since >DF and >SF are being removed, just extend the
>> definition of >FLOAT to whatever is finally agreed upon.
>>
>> > Should an application want to input nan/inf strings then perhaps
>> > provide the tools to do it. I've mentioned nan/inf constants, so:
>> >
>> > : >F
>> > 2dup s" +NAN" caps-compare 0= if 2drop +nan true exit then
>> > 2dup s" -NAN" caps-compare 0= if 2drop -nan true exit then
>> > 2dup s" +INF" caps-compare 0= if 2drop +inf true exit then
>> > 2dup s" -INF" caps-compare 0= if 2drop -inf true exit then
>> > >float ;
>> >
>> > This would require a caps-compare function but it's generally useful
>> > anyway.
>>
>> Not a bad idea. I lean towards letting >FLOAT do the
>> interpretation, since it's supposed to be omnivorous. :-)
>
>Let's see if I can disuade you from such a view!
>
>As discussed in a previous thread extending >FLOAT reduces its
>ability to discriminate bad input.
As also discussed in that thread, that's not it's job. FALSE just
indiscates that it has failed to turn its input into an FP number, not
that the input is bad. And a TRUE result does not indicate that the
input conformed to whatever restrictions you have in mind.
>No-one as yet has been able to
>show any gain to counter-balance the loss. In contrast, methods
>exist that allow extension without compromising >FLOAT .
Just as methods exist that allow doing input validation without
relying on arbitrary limits in >FLOAT.
>I have an f/p program. It has no need for nan/inf input, nor are
>they likely to be generated.
>
>The program takes an f/p number via >FLOAT. It then normalizes
>it to the range 0.1 ... 1.0 by doing a comparison test and dividing/
>multiplying by 10.0 as needed.
>
>The program works fine ... until someone whose >FLOAT happens
>to support nan/inf. They input these non-numbers and the program
>hangs in an infinite loop attempting to normalize it.
As Marcel showed, even a syntax-checking >FLOAT that does not accept
INF will have this problem. So this program should better check for
inf in the input to the normalization routine rather than relying on
>FLOAT to do a job it was not built for.
Andrew Haley
> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
> BTW, I guess you mean SSE2, which uses the XMM registers, not MMX,
> right?
Indeed, confusion reigns.
> >> >The 2008 IEEE spec uses some language which is IMO quite
> >> >inappropriate: that attributes like rounding mode may be specified for
> >> >all standard operations in a block. But what if a language is not
> >> >block-structured? This requirement makes no sense for Forth IMO.
> >
> >> I have not read that part, but I guess the "block" is just a way to
> >> specify a range of code.
> >
> >Right, but in a dynamic language, what's a range? It seems to me that
> >a range in Forth is an extent in time, not an extent in lexical scope.
> A range is whatever we specify. E.g., if we change the search order
> during compilation, and later change it back, then the affected range
> is the source code between the first change and the second change;
... which may or may not lexically be between the point of the
changes.
> if you want, you can consider this as an extent in (compile) time,
> but the effect corresponds very much to lexical/static things in
> other programming languages.
Well, OK, it's similar. Maybe. I think we both know perfectly well
how it all works.
> As another example, locals in Forth don't do dynamic scoping, and
> that's the right thing.
> The occurences of "block" I have found in the IEEE 754:2008 document
> (draft 1.2.9) are in Appendix E and deal with alternate IEEE-exception
> handling modes.
No, I'm referring to 8.3, "Language standards should define". Clearly
the word "should" means all this stuff is non-normative, so we don't
have to worry about it.
> >I don't know that all floating-point packages (hw/sw combinations)
> >that might want to be compatible with this proposed extension will
> >have the ability to use all the rounding modes. Maybe some systems
> >don't even have all the modes.
> >
> >However, if setting the rounding mode is always just a trivial matter
> >of setting a status bit, then I think we should consider requiring the
> >implementations to provide words to do that.
> Yes, but the main words for user programs should be something safe
> like ROUNDING-EXECUTE, or we produce another STATE, only this one is
> much harder to notice and therefore more insidious.
"Safe" ???? This is Forth, fercrineoutloud! If people want safely to
stash the old value, let them do so. I think a better factoring is to
have FOO_ROUNDING return the previous rounding, so that people can do
FOO_MODE >r ['] foo catch r> !MODE
or even
TRUNCATE_MODE >r f+ r> !MODE
which, assuming we don't let arithmetic throw, is perfectly safe.
Unless you're worried about someone pressing ctrl-c, but that is
nonstandard anyway: ctrl-c can do whatever cleanup is needed.
Andrew.
Andrew Haley
> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
> >Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> >
> >> Not for the casual searcher. I wanted to check what it had to say
> >> about the F** operation, and I also wanted to check the claim (IIRC
> >> by Marcel) that functions like FSIN have to produce the closest FP
> >> number to the real result as result.
> >
> >I think this is "recommended" by IEEE-2008, but none of these
> >functions are required.
> I found the recommendation for many transcendental functions (but
> nothing for the F** operation),
It's called pow. In table 9.1.
> but they were just enumerated, without much speciofication about how
> they should behave. Thinking a little bit about the "correct
> rounding" language suggests bit-accuracy to me.
That's exactly what it means.
> And maybe one can extract the expected behaviour on boundary
> conditions (like those in current CfVs) from somewhere in the text,
> but it's not as obvious as I would have liked.
Andrew.
Thomas Pornin
> bit-accuracy to me. And maybe one can extract the expected behaviour
> on boundary conditions
IEEE 754:2008 defines the meaning of "correct rounding" in section 2.1
(the section labelled "definitions"). The definition is:
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.
Then section 4 ("Attributes and rounding") specifies that rounding
operation. Namely, section 4.3 staths that:
Rounding takes a number regarded as infinitely precise and, if
necessary, modifies it to fit in the destinations format while
signaling the inexact exception, underflow, or overflow when
appropriate (see 7). Except where stated otherwise, every operation
shall be performed as if it first produced an intermediate result
correct to infinite precision and with unbounded range, and then
rounded that result according to one of the attributes in this
clause.
and goes on with listing the five standard rounding directions:
roundTiesToEven, roundTiesToAway, roundTowardPositive,
roundTowardNegative and roundTowardZero. The "roundTiesToAway" is novel
in the 2008 version; the four other modes were already in 754:1985.
--Thomas Pornin
David N. Williams
And "rountTiesToAway" is not required for a binary implementation
(section 4.3.3). :-)
-- David
Ed
> >As discussed in a previous thread extending >FLOAT reduces its
> >ability to discriminate bad input.
>
> As also discussed in that thread, that's not it's job. FALSE just
> indiscates that it has failed to turn its input into an FP number, not
> that the input is bad. And a TRUE result does not indicate that the
> input conformed to whatever restrictions you have in mind.
Impractical
> >No-one as yet has been able to
> >show any gain to counter-balance the loss. In contrast, methods
> >exist that allow extension without compromising >FLOAT .
>
> Just as methods exist that allow doing input validation without
> relying on arbitrary limits in >FLOAT.
Impractical
> >I have an f/p program. It has no need for nan/inf input, nor are
> >they likely to be generated.
> >
> >The program takes an f/p number via >FLOAT. It then normalizes
> >it to the range 0.1 ... 1.0 by doing a comparison test and dividing/
> >multiplying by 10.0 as needed.
> >
> >The program works fine ... until someone whose >FLOAT happens
> >to support nan/inf. They input these non-numbers and the program
> >hangs in an infinite loop attempting to normalize it.
>
> As Marcel showed, even a syntax-checking >FLOAT that does not accept
> INF will have this problem.
Non-conforming >FLOAT implementation
> So this program should better check for
> inf in the input to the normalization routine rather than relying on
> >FLOAT to do a job it was not built for.
Impractical
Ed
> "Ed" <nos...@invalid.com> writes Re: RfD: IEEE-FP
> [..]
> > I have an f/p program. It has no need for nan/inf input, nor are
> > they likely to be generated.
>
> > The program takes an f/p number via >FLOAT. It then normalizes
> > it to the range 0.1 ... 1.0 by doing a comparison test and dividing/
> > multiplying by 10.0 as needed.
>
> > The program works fine ... until someone whose >FLOAT happens
> > to support nan/inf. They input these non-numbers and the program
> > hangs in an infinite loop attempting to normalize it.
>
> > No doubt other such examples could be found.
>
> Even without explicit input of "Inf" your program won't work as
> described with current >FLOATs:
>
> 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
>
> 1e1024 f. Inf ok
> s" 1e1024" >float . f. -1 Inf ok
A defective implementation.
>FLOAT is required convert strings to a *valid floating-point number*.
Should "1e1024" be outside your range of valid numbers then it must
return false.
12.6.1.0558 >FLOAT
"... If the string does not represent a *valid floating-point number*
only false is returned".
Nans/Infs are *not* valid floating point numbers. Maths does not
regard Infinity as a number (it's a "concept"). Even C99 states nans/infs
are not floating point numbers. They only occupy the same storage
space as f/p numbers.
>FLOAT and REPRESENT are forth's basic f/p i/o primitives.
For sane f/p programming they must be able to discriminate numbers
and non-numbers.
If you believe forth needs a function that accepts both floats and nan/infs
then propose one. Simpler is to just write a pre-parser for >FLOAT as
previously suggested. I believe iForth has nan/infs as constants so it
shouldn't be hard.
Ed
Impractical.
No portable program can cope with a >FLOAT that is open-ended.
Even if >FLOAT was extended to include *only* nan/inf handling,
it would be prohibitive for programs to have to untangle the "feature"
(particularly without a caps-compare function).
Forth is about factoring. >FLOAT is a good and useful factor.
Don't ruin it.
> > I meant other non-numbers e.g. "unsupported", "empty", "denormal"
> > on x87 hardware. If IEEE defines them (?) then should not the
> > proposal also specify them as potential REPRESENT output?
>
> I'm not sure what an unsupported or an empty number is.
See FXAM in the Intel x87 manual.
Marcel Hendrix
>> Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
>> Type `bye' to exit
>> 1e1024 f. Inf ok
>> s" 1e1024" >float . f. -1 Inf ok
>> ...
( SwiftForth, iForth, .. same idea )
> A defective implementation.
VFX Forth for Windows IA32
� MicroProcessor Engineering Ltd, 1998-2007
Version: 4.01 [build 2390]
Build date: 12 February 2007
Free dictionary = 7684218 bytes [7504kb]
s" 1e5024" >FLOAT . f. -1 +Inf ok
NDP Potential Exception: NDP SW = 0028
Let's see, who did I miss?
32bit Forth for Windows 95, 98, and NT
Compiled: October 18th, 2006, 0:19am
Version: 4.2 Build: 0545 Rebuilt by User
Platform: Windows NT Version: 5.1 Build: 2600
3,815k bytes free
2,904 Words in Application dictionary
1,445 Words in System dictionary
4,349 Words total in dictionaries
9,462 Windows Constants available
Loading Win32For.CFG
*** DON'T PANIC, Press: F1 NOW! ***
S" 1e5024" >FLOAT . F. -1 Infini ok
Sorry, I don't have a more current implementation.
They *all* seem to be defective, so I guess they will have to
change real fast to the one true way.
-marcel
Andrew Haley
> Marcel Hendrix wrote:
> > "Ed" <nos...@invalid.com> writes Re: RfD: IEEE-FP
> > [..]
> > > I have an f/p program. It has no need for nan/inf input, nor are
> > > they likely to be generated.
> >
> > > The program takes an f/p number via >FLOAT. It then normalizes
> > > it to the range 0.1 ... 1.0 by doing a comparison test and dividing/
> > > multiplying by 10.0 as needed.
> >
> > > The program works fine ... until someone whose >FLOAT happens
> > > to support nan/inf. They input these non-numbers and the program
> > > hangs in an infinite loop attempting to normalize it.
> >
> > > No doubt other such examples could be found.
> >
> > Even without explicit input of "Inf" your program won't work as
> > described with current >FLOATs:
> >
> > 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
> >
> > 1e1024 f. Inf ok
> > s" 1e1024" >float . f. -1 Inf ok
> > ...
> A defective implementation.
> >FLOAT is required convert strings to a *valid floating-point number*.
Yes, and infinity is a valid floating-point number, so the right thing
to do here is to return inf. The alternative is much worse: the
program would not be able to distinguish between a a very large value
and a string of nonsense.
> Nans/Infs are *not* valid floating point numbers. Maths does not
> regard Infinity as a number (it's a "concept").
You can't just keep making stuff up about floating point and then
claiming "maths says".
Clearly NaN is not a valid floating-point number: NaN means "not a
number". But infinity very much is.
Andrew.
Andrew Haley
> Andrew Haley wrote:
> > All this means is that your program needs to be improved for use
> > on an IEEE-compliant system.
> Impractical.
> No portable program can cope with a >FLOAT that is open-ended.
It's not open-ended. It's really, really, well-defined. The whole
point of IEEE compliance to to make all this stuff *less* open-ended.
> Even if >FLOAT was extended to include *only* nan/inf handling,
> it would be prohibitive for programs to have to untangle the "feature"
> (particularly without a caps-compare function).
Why would you want to untangle it? Read the number and then say
INFINITE? if you need to know if a fp number is infinite.
> Forth is about factoring. >FLOAT is a good and useful factor.
> Don't ruin it.
> > > I meant other non-numbers e.g. "unsupported", "empty", "denormal"
> > > on x87 hardware. If IEEE defines them (?) then should not the
> > > proposal also specify them as potential REPRESENT output?
> >
> > I'm not sure what an unsupported or an empty number is.
> See FXAM in the Intel x87 manual.
What's the relevance of the Intel x87 manual? We're talking about
IEEE floating-point. Clearly "empty" is a floating-point stack
underflow, and AFAICS "unsupported" could only possibly be the result
of a very weird programming error. But no-one is proposing to
standardize x87 weirdnesses.
Andrew.
Ed
> ...
> Sorry, I don't have a more current implementation.
>
> They *all* seem to be defective, so I guess they will have to
> change real fast to the one true way.
The '94 specification is clear on this point. More importantly,
it is technically correct and promotes tight, portable programming.
I see no value in an input number routine that can't detect out of
out range floating point numbers.
Whether the forths you mention wish to correct their oversight
is their business.
As for your "one true way", I'm sure your ego will dictate to you
what that should be. Whether logic will play a part remains to be
seen.
Ed
> > >FLOAT is required convert strings to a *valid floating-point number*.
>
> Yes, and infinity is a valid floating-point number, so the right thing
> to do here is to return inf. The alternative is much worse: the
> program would not be able to distinguish between a a very large value
> and a string of nonsense.
>
> > Nans/Infs are *not* valid floating point numbers. Maths does not
> > regard Infinity as a number (it's a "concept").
>
> You can't just keep making stuff up about floating point and then
> claiming "maths says".
>
> Clearly NaN is not a valid floating-point number: NaN means "not a
> number". But infinity very much is.
Unbelievable
Andrew Haley
> Unbelievable
On the one hand you say to Marcel:
"As for your "one true way", I'm sure your ego will dictate to you
what that should be. Whether logic will play a part remains to be
seen."
and on the other hand your carefully thought out and logical reply to
me is
"Unbelievable"
Go figure...
Andrew.
Andrew Haley
> Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> > For controlling the rounding mode dynamically, I would just have a
> > dynamic-scoping-style word for that to avoid having another global
> > state that easily affects parts of the code that were not intended to
> > be affected. E.g., something like
> > ROUNDING-EXECUTE ( ... rounding-mode xt -- ... )
> > which ensures that the rounding mode is restored when the word is left
> > even if it is left through throwing an exception.
> Isn't that just
> @mode >r ['] foo catch r> !mode
> ?
I have a better idea that will not require another word to be defined
for EXECUTE and may be enough to make everyone happy. How about a
bracketed pair of words that enter and leave rounding modes:
FLOORED-ROUNDING[ foo bar baz ]ROUNDING
I'm not wild about these names, but you get the idea. I don't know
how well this will fit with the various exception-handling mechanisms
used by Forths. It may be impractical, but I'm sure it's better from
a user's point of view.
Andrew.
David N. Williams
I like the idea, assuming it incorporates saving and restoring
the current mode, as Anton says. If the mode is left by
throwing an exception in between, isn't that likely to reflect a
pretty drastic situation, where it wouldn't hurt to restore the
default anyway? To my mind, fp exceptions are going to be
nearly always nonstopping. Or am I wrong?
-- David
Andrew Haley
> > Andrew Haley <andr...@littlepinkcloud.invalid> wrote:
> >> Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> >
> >>> For controlling the rounding mode dynamically, I would just have a
> >>> dynamic-scoping-style word for that to avoid having another global
> >>> state that easily affects parts of the code that were not intended to
> >>> be affected. E.g., something like
> >
> >>> ROUNDING-EXECUTE ( ... rounding-mode xt -- ... )
> >
> >>> which ensures that the rounding mode is restored when the word is left
> >>> even if it is left through throwing an exception.
> >
> >> Isn't that just
> >
> >> @mode >r ['] foo catch r> !mode
> >
> >> ?
> >
> > I have a better idea that will not require another word to be defined
> > for EXECUTE and may be enough to make everyone happy. How about a
> > bracketed pair of words that enter and leave rounding modes:
> >
> > FLOORED-ROUNDING[ foo bar baz ]ROUNDING
> >
> > I'm not wild about these names, but you get the idea. I don't know
> > how well this will fit with the various exception-handling mechanisms
> > used by Forths. It may be impractical, but I'm sure it's better from
> > a user's point of view.
> I like the idea, assuming it incorporates saving and restoring
> the current mode, as Anton says.
That's the idea.
It's interesting to note that C Appendix F does not require dynamic
rounding modes (it's a "should") but it does require static rounding
modes (that's a "shall".) Not that this matters to us, or, as far as
I can see, to Standard C either. I'm assuming that all IEEE
floating-point hardware sets rounding modes via some sort of mode bit,
rather than embedding it in each instruction.
> If the mode is left by throwing an exception in between, isn't that
> likely to reflect a pretty drastic situation, where it wouldn't hurt
> to restore the default anyway?
Yes, I agree.
> To my mind, fp exceptions are going to be nearly always nonstopping.
> Or am I wrong?
I don't think that there is any proposal to turn IEEE exceptions into
Forth THROWs. So, any THROW that happens in a non-default FP region
is caused by something else.
Andrew.
David N. Williams
>
>> I like the idea, assuming it incorporates saving and restoring
>> the current mode, as Anton says.
>
> That's the idea.
>
>
>> If the mode is left by throwing an exception in between, isn't that
>> likely to reflect a pretty drastic situation, where it wouldn't hurt
>> to restore the default anyway?
>
> Yes, I agree.
>
>> To my mind, fp exceptions are going to be nearly always nonstopping.
>> Or am I wrong?
>
> I don't think that there is any proposal to turn IEEE exceptions into
> Forth THROWs. So, any THROW that happens in a non-default FP region
> is caused by something else.
Okay, do you intend stack effects like this?
FLOORED-ROUNDING[ ( -- rnd )
]ROUNDING ( rnd -- )
Else, how would you nest them, e.g., when a word using them
calls another word using them? Or is there a hidden rounding
stack?
-- David
Anton Ertl
Yes. But even with public domain code the FSF wants to have it in
writing that the code is in the public domain. If this code is
distributed with gcc, then the FSF already has the papers and we don't
need to ask people to sign them.
Andrew Haley
I'd stash them on the return stack.
Andrew.
Anton Ertl
>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>> A range is whatever we specify. E.g., if we change the search order
>> during compilation, and later change it back, then the affected range
>> is the source code between the first change and the second change;
>
>... which may or may not lexically be between the point of the
>changes.
Unless you are talking about perversions like EVALUATE-based macros
(which are perversions for that very reason), all the affected code is
lexically between the two changes.
>> The occurences of "block" I have found in the IEEE 754:2008 document
>> (draft 1.2.9) are in Appendix E and deal with alternate IEEE-exception
>> handling modes.
>
>No, I'm referring to 8.3, "Language standards should define". Clearly
>the word "should" means all this stuff is non-normative, so we don't
>have to worry about it.
I am now looking at the final version. That chapter is on "Alternate
exception handling attributes", i.e., it's the final incarnation of
that appendix.
Now the Definition of terms also contains a definition of a block:
|2.1.7 block: A language-defined syntactic unit for which a user can
|specify attributes. Language standards might provide means for users
|to specify attributes for blocks of varying scopes, even as large as
|an entire program and as small as a single operation.
That's pretty general and can certainly be translated into Forth
terms.
>> Yes, but the main words for user programs should be something safe
>> like ROUNDING-EXECUTE, or we produce another STATE, only this one is
>> much harder to notice and therefore more insidious.
>
>"Safe" ???? This is Forth, fercrineoutloud! If people want safely to
>stash the old value, let them do so.
In my experience it's programmer A who has the bad habit of not
restoring the old value (after all, that's what "Thinking Forth"
advocates), and programmer B and user C who suffer from this. This
style of programming may be ok if "code reuse" is a four-letter word
to you, but IMO the standard should also provide words directly usable
by other people.
>I think a better factoring is to
>have FOO_ROUNDING return the previous rounding, so that people can do
>
> FOO_MODE >r ['] foo catch r> !MODE
>
>or even
>
> TRUNCATE_MODE >r f+ r> !MODE
>
>which, assuming we don't let arithmetic throw, is perfectly safe.
>Unless you're worried about someone pressing ctrl-c, but that is
>nonstandard anyway: ctrl-c can do whatever cleanup is needed.
"User Interrupts" can happen in standard programs, and standard
programs can CATCH them. And there is no way for the user interrupt
to clean up various states, because there is no way for the user
interrupt to know what the states are supposed to be.
Anton Ertl
>Andrew Haley <andr...@littlepinkcloud.invalid> wrote:
>> Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>
>> > For controlling the rounding mode dynamically, I would just have a
>> > dynamic-scoping-style word for that to avoid having another global
>> > state that easily affects parts of the code that were not intended to
>> > be affected. E.g., something like
>
>> > ROUNDING-EXECUTE ( ... rounding-mode xt -- ... )
>
>> > which ensures that the rounding mode is restored when the word is left
>> > even if it is left through throwing an exception.
>
>> Isn't that just
>
>> @mode >r ['] foo catch r> !mode
>
>> ?
>
>I have a better idea that will not require another word to be defined
>for EXECUTE and may be enough to make everyone happy. How about a
>bracketed pair of words that enter and leave rounding modes:
>
> FLOORED-ROUNDING[ foo bar baz ]ROUNDING
>
>I'm not wild about these names, but you get the idea.
Yes, that's a nicer syntax, and that's fine with me. The other syntax
was more in line with the way CATCH works, and is somewhat easier to
implement.
>I don't know
>how well this will fit with the various exception-handling mechanisms
>used by Forths. It may be impractical, but I'm sure it's better from
>a user's point of view.
I don't think it's impractical (in the worst case you wrap the
contained stuff in an anonymous colon definition and call a word like
ROUNDING-EXECUTE), but it's more work.
Andrew Haley
> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
> >Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> >> A range is whatever we specify. E.g., if we change the search order
> >> during compilation, and later change it back, then the affected range
> >> is the source code between the first change and the second change;
> >
> >... which may or may not lexically be between the point of the
> >changes.
> Unless you are talking about perversions like EVALUATE-based macros
Or INCLUDEing code from elsewhere, etc, etc. All normal Forth.
> (which are perversions for that very reason), all the affected code
> is lexically between the two changes.
> >> Yes, but the main words for user programs should be something safe
> >> like ROUNDING-EXECUTE, or we produce another STATE, only this one is
> >> much harder to notice and therefore more insidious.
> >
> >"Safe" ???? This is Forth, fercrineoutloud! If people want safely to
> >stash the old value, let them do so.
> In my experience it's programmer A who has the bad habit of not
> restoring the old value (after all, that's what "Thinking Forth"
> advocates), and programmer B and user C who suffer from this. This
> style of programming may be ok if "code reuse" is a four-letter word
> to you, but IMO the standard should also provide words directly
> usable by other people.
They are, of course. If people want to do this in a "safe" way, with
CATCH et al, they can. It's up to them.
It would surely be very bad if a standard did not provide the tools to
do what you suggest.
> >I think a better factoring is to
> >have FOO_ROUNDING return the previous rounding, so that people can do
> >
> > FOO_MODE >r ['] foo catch r> !MODE
> >
> >or even
> >
> > TRUNCATE_MODE >r f+ r> !MODE
> >
> >which, assuming we don't let arithmetic throw, is perfectly safe.
> >Unless you're worried about someone pressing ctrl-c, but that is
> >nonstandard anyway: ctrl-c can do whatever cleanup is needed.
> "User Interrupts" can happen in standard programs, and standard
> programs can CATCH them.
Surely all a standard needs to do is provide tools that make it easy
to do a job well, not to enforce anyone's idea of good practice.
There's nothing to stop people doing what you suggest: they can use
CATCH with a mode change if they like.
> And there is no way for the user interrupt to clean up various
> states, because there is no way for the user interrupt to know what
> the states are supposed to be.
That's making the assumption that "the previous state" *is* what the
state is supposed to be.
Andrew.
Andrew Haley
> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
> >Andrew Haley <andr...@littlepinkcloud.invalid> wrote:
> >I have a better idea that will not require another word to be defined
> >for EXECUTE and may be enough to make everyone happy. How about a
> >bracketed pair of words that enter and leave rounding modes:
> >
> > FLOORED-ROUNDING[ foo bar baz ]ROUNDING
> >
> >I'm not wild about these names, but you get the idea.
> Yes, that's a nicer syntax, and that's fine with me. The other syntax
> was more in line with the way CATCH works, and is somewhat easier to
> implement.
> >I don't know how well this will fit with the various
> >exception-handling mechanisms used by Forths. It may be
> >impractical, but I'm sure it's better from a user's point of view.
> I don't think it's impractical (in the worst case you wrap the
> contained stuff in an anonymous colon definition and call a word like
> ROUNDING-EXECUTE), but it's more work.
Indeed. I'm very worried that with this proposal we may end up with
something so burdensome that no-one (except perhaps gforth!) will
implement it.
Andrew.
David N. Williams
>
>> FLOORED-ROUNDING[ ( -- rnd )
>> ]ROUNDING ( rnd -- )
>
>> Else, how would you nest them, e.g., when a word using them
>> calls another word using them? Or is there a hidden rounding
>> stack?
>
> I'd stash them on the return stack.
Okay, so there'd presumably be nonsaving words, like
FLOORED-ROUNDING, for interpret mode, and as factors in the
saving words?
-- David
David N. Williams
I'm almost ready with the next, much revised (and pruned) draft.
The fp environment-as-a-whole words are gone.
There is still a section on exceptions, which is empty, awaiting
the convergence of good ideas from this newsgroup.
The current state of the section on rounding modes is copied
below, for feedback. I changed Andrew's FLOORED-ROUNDING[ name
for consistency with the names of the integer rounding words
elsewhere in the document, but of course would be happy to
change it back. I did change "[" and "]" to "{" and "}",
because the square brackets have a connotation of switching to
interpretation mode.
See what you think.
I'm going to be traveling for the next few days, but will still
be able to respond at least in the evenings.
-- David
7.11 Rounding modes
-------------------
[**UNDER CONSTRUCTION]
From IEEE 9.3, "Operations on dynamic modes for attributes", we
define only words corresponding to 9.3.1, "Operations on
individual dynamic modes". As stated earlier, roundTiesToAway
is not defined.
[**This scheme was suggested by Andrew Haley in comp.lang.forth,
having emerged from a discussion with Anton Ertl.]
NEAR-ROUNDING ( -- )
CEIL-ROUNDING ( -- )
FLOOR-ROUNDING ( -- )
TRUNC-ROUNDING ( -- )
NEAR-ROUNDING{ ( -- ) compilation only
CEIL-ROUNDING{ ( -- ) compilation only
FLOOR-ROUNDING{ ( -- ) compilation only
TRUNC-ROUNDING{ ( -- ) compilation only
}ROUNDING ( -- ) compilation only
The first four words set the current rounding mode to
roundTiesToEven, roundTowardPositive, roundTowardNegative, and
roundTowardZero, respectively.
The next four, compilation only words save the current
rounding mode first, then set the current mode as indicated.
They must occur in a balanced pair with }ROUNDING, which
restores the mode saved by the first member of the pair. The
return stack may be used for saving and restoring the mode,
which entails the usual restrictions on their use with DO ...
LOOP, locals, etc.
Anton Ertl
>Clearly NaN is not a valid floating-point number: NaN means "not a
>number". But infinity very much is.
If you view FP as an algebra, then NaNs are FP values used to close
the algebra. Whether you view them (or infs) as things that you want
to input depends on your application. Given that >FLOAT is intended
to try to convert as much as possible, it should probably also convert
infinities and NaNs, and applications that don't want these kinds of
values should then reject them afterwards.
Anton Ertl
>It's interesting to note that C Appendix F does not require dynamic
>rounding modes (it's a "should") but it does require static rounding
>modes (that's a "shall".) Not that this matters to us, or, as far as
>I can see, to Standard C either. I'm assuming that all IEEE
>floating-point hardware sets rounding modes via some sort of mode bit,
>rather than embedding it in each instruction.
Alpha incorporates the rounding modes in the instruction. You can
statically specify normal rounding, chopped, and rounding towards
minus infinity; rounding towards plus infinity is only available
through dynamic rounding.
IIRC Kahan and Darcy also mentioned another architecture that supports
static rounding.
If we wanted to incorporate this in Forth, the usual way would be to
have separate words for the different operations, e.g.,:
F+ for dynamic
F+N for rounding to nearest or even
F+M for rounding towards minus infinity
F+P for rounding towards plus infinity
F+C for rounding towards zero (chopped)
However, that would be relatively expensive to implement efficiently
on CPUs that only support dynamic rounding, so if we want to provide
this, maybe we should think about a syntax that makes it easier to
implement efficiently on most CPUs. Or maybe we should just stick
with dynamic rounding.
>> If the mode is left by throwing an exception in between, isn't that
>> likely to reflect a pretty drastic situation, where it wouldn't hurt
>> to restore the default anyway?
The exception could happen for any number of reasons (e.g., user
interrupt), and it could be caught at any number of places, where a
non-default rounding mode should be in force (e.g., because the user
is running the same routine in different rounding modes). If we
support dynamic rounding modes, we should support them properly.
>> To my mind, fp exceptions are going to be nearly always nonstopping.
>> Or am I wrong?
That's at least the current behaviour on Gforth and iForth. It's
probably a good default to standardize. One can imagine extensions
that could turn certain IEEE exceptions into Forth exceptions. But
that is probably too much for the current proposal.
Anyway, as Andrew says, FP exceptions are not the only ones that could
lead to leaving the rounding region.
Anton Ertl
That's something where EXECUTE-ROUNDING would be more general. You
could just use it interpretively, or if you really want to set the
rounding mode permanently, do something like
' quit round-up execute-rounding
and it's good that it looks gross, because it is.
Anyway, for the bracketet variants and the non-saving words, I would
have
( rounding-mode ) <rounding ... rounding>
and
exch-rounding ( rounding-mode1 -- rounding-mode2 )
or if you want it more primitive
get-rounding ( -- rounding-mode2 )
set-rounding ( rounding-mode1 -- )
Anton Ertl
>the convergence of good ideas from this newsgroup.
I think the idea of having ways to query for the various
IEEE-exceptions is good. In addition, one would need a way to reset
the exceptions. Hmm, that opens up the question of how to make that
composable, which may have a similar answer as for the rounding modes.
The question is:
Some routine A needs to know if an IEEE-exception has happened in its
code, so it has to clear that IEEE-exception flag at the start and
query it afterwards. But what about a routine B that calls A and that
also needs to know which IEEE-exceptions happened in its code?
Resetting the flag at the start of A throws away the information
needed for B, so we have to save it in some way. We may also have to
combine the flag coming from A with the saved stuff.
I begin to see why C has this floating-point environment stuff, but
that does not look appropriate for Forth, because Forth has (Forth)
exceptions.
>The current state of the section on rounding modes is copied
>below, for feedback. I changed Andrew's FLOORED-ROUNDING[ name
>for consistency with the names of the integer rounding words
>elsewhere in the document, but of course would be happy to
>change it back. I did change "[" and "]" to "{" and "}",
>because the square brackets have a connotation of switching to
>interpretation mode.
I agree wrt "[" and "]".
>7.11 Rounding modes
>-------------------
>
>[**UNDER CONSTRUCTION]
>
> From IEEE 9.3, "Operations on dynamic modes for attributes", we
>define only words corresponding to 9.3.1, "Operations on
>individual dynamic modes". As stated earlier, roundTiesToAway
>is not defined.
>
>[**This scheme was suggested by Andrew Haley in comp.lang.forth,
>having emerged from a discussion with Anton Ertl.]
>
>NEAR-ROUNDING ( -- )
>CEIL-ROUNDING ( -- )
>FLOOR-ROUNDING ( -- )
>TRUNC-ROUNDING ( -- )
>
>NEAR-ROUNDING{ ( -- ) compilation only
>CEIL-ROUNDING{ ( -- ) compilation only
>FLOOR-ROUNDING{ ( -- ) compilation only
>TRUNC-ROUNDING{ ( -- ) compilation only
>}ROUNDING ( -- ) compilation only
Having two words like
ROUNDING{ ( compilation: -- some-sys ;
run-time: rounding-mode -- R: other-sys )
and
EXCH-ROUNDING ( rounding-mode1 -- rounding-mode2 )
plus four constants for the rounding modes is more flexible and
reduces the number of words by two.
Anton Ertl
>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>> >Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>> >> A range is whatever we specify. E.g., if we change the search order
>> >> during compilation, and later change it back, then the affected range
>> >> is the source code between the first change and the second change;
>> >
>> >... which may or may not lexically be between the point of the
>> >changes.
>
>> Unless you are talking about perversions like EVALUATE-based macros
>
>Or INCLUDEing code from elsewhere
True. But that's not any different from the C case, where #included
code would count as content of a block. Even the EVALUATE-based macro
has its C parallel in C macros.
>, etc, etc.
Could you elaborate on that?
>> In my experience it's programmer A who has the bad habit of not
>> restoring the old value (after all, that's what "Thinking Forth"
>> advocates), and programmer B and user C who suffer from this. This
>> style of programming may be ok if "code reuse" is a four-letter word
>> to you, but IMO the standard should also provide words directly
>> usable by other people.
>
>They are, of course. If people want to do this in a "safe" way, with
>CATCH et al, they can. It's up to them.
Yes, they can (up to a point), but giving them just CATCH is too
inconvenient, and there are few books that teach how to do it, and one
frequently-recommended book that teaches the bad habit. As a
consequence, we have lots of code that's not reusable, because it just
messes around with various states.
>Surely all a standard needs to do is provide tools that make it easy
>to do a job well,
Yes, "easy" is the important word.
>There's nothing to stop people doing what you suggest: they can use
>CATCH with a mode change if they like.
That's too hard.
>> And there is no way for the user interrupt to clean up various
>> states, because there is no way for the user interrupt to know what
>> the states are supposed to be.
>
>That's making the assumption that "the previous state" *is* what the
>state is supposed to be.
Maybe one can construct words where the state that's supposed to be is
different, but I don't think such words can be used as reusable
components. Also, not changing the state when calling a word follows
the principle of least surprise.
Andrew Haley
> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
> >Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> >> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
> >> >Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> >> >> A range is whatever we specify. E.g., if we change the search order
> >> >> during compilation, and later change it back, then the affected range
> >> >> is the source code between the first change and the second change;
> >> >
> >> >... which may or may not lexically be between the point of the
> >> >changes.
> >
> >> Unless you are talking about perversions like EVALUATE-based macros
> >
> >Or INCLUDEing code from elsewhere
> True. But that's not any different from the C case, where #included
> code would count as content of a block. Even the EVALUATE-based macro
> has its C parallel in C macros.
> >, etc, etc.
> Could you elaborate on that?
There's also LOAD, and there's POSTPONE.
> >> In my experience it's programmer A who has the bad habit of not
> >> restoring the old value (after all, that's what "Thinking Forth"
> >> advocates), and programmer B and user C who suffer from this.
> >> This style of programming may be ok if "code reuse" is a
> >> four-letter word to you, but IMO the standard should also provide
> >> words directly usable by other people.
> >
> >They are, of course. If people want to do this in a "safe" way, with
> >CATCH et al, they can. It's up to them.
> Yes, they can (up to a point), but giving them just CATCH is too
> inconvenient, and there are few books that teach how to do it, and
> one frequently-recommended book that teaches the bad habit.
It looks to me as though you want to enforce a view of what
constitutes good habits by only providing the solutions of which you
approve.
> As a consequence, we have lots of code that's not reusable, because
> it just messes around with various states.
> >Surely all a standard needs to do is provide tools that make it easy
> >to do a job well,
> Yes, "easy" is the important word.
> >There's nothing to stop people doing what you suggest: they can use
> >CATCH with a mode change if they like.
> That's too hard.
I'm trying to understand exactly what you want. Is EXECUTE-MODE any
different from, say
: execute-mode ( xt mode) !MODE EXECUTE ;
: EXECUTE-MODE ( xt mode)
@MODE >R ['] execute-mode CATCH R> !MODE THROW ;
(Good grief, the exception word set is cumbersome to use.)
I have to stress here that I am *not* arguing against the idea of
providing the tools users need: I am arguing against the idea of only
providing users with what we happen think is good for them.
For example, it will be extremely useful interactively to set the
rounding mode and then experiment with code. If we only provide a
form of mode setting that takes an xt or a block of code then people
can't do e.g.,
floored-mode pi fsqrt foo f- x f* ...
The loss of the interactive ability to experiment with rounding modes
would be a Bad Thing.
Andrew.
Anton Ertl
>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>> >Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>> >> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>> >> >Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>> >> >> A range is whatever we specify. E.g., if we change the search order
>> >> >> during compilation, and later change it back, then the affected range
>> >> >> is the source code between the first change and the second change;
>> >> >
>> >> >... which may or may not lexically be between the point of the
>> >> >changes.
>There's also LOAD, and there's POSTPONE.
LOAD is just a variant of the INCLUDE case.
POSTPONE is affected just in the ordinary Forth way. If you have
POSTPONE X in the range, and X is a different word in that range,
POSTPONE will of course postpone that word; likewise, if X is in a
colon definition, it will be compiled permanently into that colon
definition. Sure the change may have effects elsewhere, but the
direct effect on source code does not extend beyond the range (apart
from various forms of inclusion).
>It looks to me as though you want to enforce a view of what
>constitutes good habits by only providing the solutions of which you
>approve.
I just want to make good habits at least as easy to use as bad habits.
>I'm trying to understand exactly what you want. Is EXECUTE-MODE any
>different from, say
>
>: execute-mode ( xt mode) !MODE EXECUTE ;
>: EXECUTE-MODE ( xt mode)
> @MODE >R ['] execute-mode CATCH R> !MODE THROW ;
>
>(Good grief, the exception word set is cumbersome to use.)
It seems you begin to see the "easyness" problem.
Yes, that would be an ok implementation. There is still a window of
vulnerability between CATCH and !MODE, and some systems may provide an
implementation that does not have that window. Of course, the syntax
you suggested is easier to use and therefore preferable according to
the "good habits should be easy to use" criterion.
>For example, it will be extremely useful interactively to set the
>rounding mode and then experiment with code. If we only provide a
>form of mode setting that takes an xt or a block of code then people
>can't do e.g.,
>
> floored-mode pi fsqrt foo f- x f* ...
: execute-rounding ( ... xt rounding-mode -- ... )
rounding{ execute }rounding ;
: floored-mode ( -- ) ['] quit round-floored execute-rounding ;
Easier than the other way round; you would have to insert a line break
after FLOORED-MODE, though.
Of course, this FLOORED-MODE is less general than the one you had in
mind, but it's good enough for the application you want FLOORED-MODE
for.
Marcel Hendrix
> Some routine A needs to know if an IEEE-exception has happened in its
> code, so it has to clear that IEEE-exception flag at the start and
> query it afterwards. But what about a routine B that calls A and that
> also needs to know which IEEE-exceptions happened in its code?
> Resetting the flag at the start of A throws away the information
> needed for B, so we have to save it in some way. We may also have to
> combine the flag coming from A with the saved stuff.
Mandating this feature means that cooperative multi-tasking schemes
must be updated/upgraded by saving and restoring the full FPU state.
>> I did change "[" and "]" to "{" and "}",
>> because the square brackets have a connotation of switching to
>> interpretation mode.
> I agree wrt "[" and "]".
"rounding{" violates the FSL convention for arrays.
-marcel
Anton Ertl
>an...@mips.complang.tuwien.ac.at (Anton Ertl) writes Re: RfD: IEEE-FP
>
>> Some routine A needs to know if an IEEE-exception has happened in its
>> code, so it has to clear that IEEE-exception flag at the start and
>> query it afterwards. But what about a routine B that calls A and that
>> also needs to know which IEEE-exceptions happened in its code?
>> Resetting the flag at the start of A throws away the information
>> needed for B, so we have to save it in some way. We may also have to
>> combine the flag coming from A with the saved stuff.
>
>Mandating this feature means that cooperative multi-tasking schemes
>must be updated/upgraded by saving and restoring the full FPU state.
It would mean that you would have to save and restore the five
IEEE-exception bits in addition to the two rounding-mode bits. I
guess the additional cost on many CPUs is zero.
>>> I did change "[" and "]" to "{" and "}",
>>> because the square brackets have a connotation of switching to
>>> interpretation mode.
>
>> I agree wrt "[" and "]".
>
>"rounding{" violates the FSL convention for arrays.
How do you like <ROUNDING ... ROUNDING> or maybe <ROUND ... ROUND>?
Marcel Hendrix
[..]
> For example, it will be extremely useful interactively to set the
> rounding mode and then experiment with code. If we only provide a
> form of mode setting that takes an xt or a block of code then people
> can't do e.g.,
> floored-mode pi fsqrt foo f- x f* ...
> The loss of the interactive ability to experiment with rounding modes
> would be a Bad Thing.
Agreed.
Anyway, on x86, it is practically impossible to set e.g. the
rounding mode for a block of compiled code statically.
Note that some Forth kernel words already manipulate FPU modes
(FTRUNCATE, FLOOR F>D F>S S>F D>F FALOG FEXP etc.). These words
will probably/hopefully/need to resist manipulation.
-marcel
Andrew Haley
> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
> >Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> >> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
> >> >Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> >It looks to me as though you want to enforce a view of what
> >constitutes good habits by only providing the solutions of which you
> >approve.
> I just want to make good habits at least as easy to use as bad
> habits.
Okay, fine. As long as we've got that clear, I'm happy. You don't
want to forbid bad habits, just make good ones easy -- for some
definitions of "bad" and "good".
> >I'm trying to understand exactly what you want. Is EXECUTE-MODE any
> >different from, say
> >
> >: execute-mode ( xt mode) !MODE EXECUTE ;
> >: EXECUTE-MODE ( xt mode)
> > @MODE >R ['] execute-mode CATCH R> !MODE THROW ;
> >
> >(Good grief, the exception word set is cumbersome to use.)
> It seems you begin to see the "easyness" problem.
Please try a little harder to be less patronizing.
> Yes, that would be an ok implementation. There is still a window of
> vulnerability between CATCH and !MODE,
Well, R> cannot throw. The only thing that might happen is a user
interrupt, and it would require some pretty heroic efforts to prevent
that from occurring even between two instructions. I suppose it would
be possible fleetingly to stop (say) ctrl-c from being processed
during that window.
But there surely must be a huge number of ways in which a perfectly
reasonable standard program will break if you allow user interrupts in
arbitrary places. There's nothing special about this one.
> and some systems may provide an implementation that does not have
> that window. Of course, the syntax you suggested is easier to use
> and therefore preferable according to the "good habits should be
> easy to use" criterion.
Yes, but I'm worried that it may be impractical to implement, as I
suggested. It rather implies a hidden anonymous colon definition, and
to require that is rather like requiring a sledgehammer to crack a
nut.
> >For example, it will be extremely useful interactively to set the
> >rounding mode and then experiment with code. If we only provide a
> >form of mode setting that takes an xt or a block of code then people
> >can't do e.g.,
> >
> > floored-mode pi fsqrt foo f- x f* ...
> : execute-rounding ( ... xt rounding-mode -- ... )
> rounding{ execute }rounding ;
> : floored-mode ( -- ) ['] quit round-floored execute-rounding ;
> Easier than the other way round; you would have to insert a line
> break after FLOORED-MODE, though.
Oh, that is horrible.
> Of course, this FLOORED-MODE is less general than the one you had in
> mind, but it's good enough for the application you want FLOORED-MODE
> for.
Well, yes, but we would be making interaction more painful for the
sake of enforcing good habits. That is not very Forth.
Andrew.
Andrew Haley
> an...@mips.complang.tuwien.ac.at (Anton Ertl) writes Re: RfD: IEEE-FP
> > Some routine A needs to know if an IEEE-exception has happened in
> > its code, so it has to clear that IEEE-exception flag at the start
> > and query it afterwards. But what about a routine B that calls A
> > and that also needs to know which IEEE-exceptions happened in its
> > code? Resetting the flag at the start of A throws away the
> > information needed for B, so we have to save it in some way. We
> > may also have to combine the flag coming from A with the saved
> > stuff.
> Mandating this feature means that cooperative multi-tasking schemes
> must be updated/upgraded by saving and restoring the full FPU state.
Surely you have to do that anyway: on an FPU with a limited stack size
you have no way to know if there's going to be enough room.
Andrew.
Marcel Hendrix
> Marcel Hendrix <m...@iae.nl> wrote:
>> Mandating this feature means that cooperative multi-tasking schemes
>> must be updated/upgraded by saving and restoring the full FPU state.
> Surely you have to do that anyway: on an FPU with a limited stack size
> you have no way to know if there's going to be enough room.
I assume all serious implementations switch the FPU stack between tasks
(and, BTW, allow non-trivial RECURSE for FP words).
However, at the moment there is no reason they should save and restore
rounding modes, exception masks etc., as there are no standard Forth
words that could/will change these.
-marcel
Anton Ertl
>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>> Yes, that would be an ok implementation. There is still a window of
>> vulnerability between CATCH and !MODE,
>
>Well, R> cannot throw. The only thing that might happen is a user
>interrupt, and it would require some pretty heroic efforts to prevent
>that from occurring even between two instructions. I suppose it would
>be possible fleetingly to stop (say) ctrl-c from being processed
>during that window.
Alternatively, just rerun the code starting with R>. And actually
don't use R>, but R@ or a local in the rerun window.
>But there surely must be a huge number of ways in which a perfectly
>reasonable standard program will break if you allow user interrupts in
>arbitrary places. There's nothing special about this one.
I have not noticed any breakage other than not preserving system state
yet. Of course the user program (or a part of it) will not complete,
but that's what the user wanted when he interrupted the program.
Program state may be a mess, but that's not affecting the system, and
in any case, it's the programmer's responsibility.
The special thing about stuff like BASE or the rounding mode is that
it is system state, and if it's wrong, the system will not work as
expected; in particular, the effects of rounding mode are pretty
subtle; FP operations will just give slightly different results for no
obvious reason. But even the wrong BASE is often not obvious.
>> and some systems may provide an implementation that does not have
>> that window. Of course, the syntax you suggested is easier to use
>> and therefore preferable according to the "good habits should be
>> easy to use" criterion.
>
>Yes, but I'm worried that it may be impractical to implement, as I
>suggested. It rather implies a hidden anonymous colon definition, and
>to require that is rather like requiring a sledgehammer to crack a
>nut.
Having such wrapped definitions seems to be a popular feature anyway,
and is not very hard to implement. I'm rather worried that such an
implementation might not provide all the features we might want to
have, in particular, having locals from outside the rounding block
visible inside.
Another implementation approach is to build an exception frame inline,
but that's a little more effort than the wrapped-definition approach.
Aleksej Saushev
> Please have a look, and offer criticisms, both general and
> specific, and suggestions.
What I don't understand in all recent proposals is why they exist at all.
Where's the practice large enough to have all those in standard?
--
BECHA...
CKOPO CE3OH...
Andrew Haley
> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
> >Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> >> Yes, that would be an ok implementation. There is still a window of
> >> vulnerability between CATCH and !MODE,
> >
> >Well, R> cannot throw. The only thing that might happen is a user
> >interrupt, and it would require some pretty heroic efforts to prevent
> >that from occurring even between two instructions. I suppose it would
> >be possible fleetingly to stop (say) ctrl-c from being processed
> >during that window.
> Alternatively, just rerun the code starting with R>. And actually
> don't use R>, but R@ or a local in the rerun window.
> >But there surely must be a huge number of ways in which a perfectly
> >reasonable standard program will break if you allow user interrupts in
> >arbitrary places. There's nothing special about this one.
> I have not noticed any breakage other than not preserving system
> state yet. Of course the user program (or a part of it) will not
> complete, but that's what the user wanted when he interrupted the
> program. Program state may be a mess, but that's not affecting the
> system, and in any case, it's the programmer's responsibility.
Exactly so, yes. I don't really understand, however, why system state
and program state should be treated differently. Forth doesn't really
have a tradition of "the system" as sacrosanct, so people don't expect
it to be.
> The special thing about stuff like BASE or the rounding mode is that
> it is system state, and if it's wrong, the system will not work as
> expected; in particular, the effects of rounding mode are pretty
> subtle; FP operations will just give slightly different results for
> no obvious reason. But even the wrong BASE is often not obvious.
Indeed not.
> >> and some systems may provide an implementation that does not have
> >> that window. Of course, the syntax you suggested is easier to use
> >> and therefore preferable according to the "good habits should be
> >> easy to use" criterion.
> >
> >Yes, but I'm worried that it may be impractical to implement, as I
> >suggested. It rather implies a hidden anonymous colon definition, and
> >to require that is rather like requiring a sledgehammer to crack a
> >nut.
> Having such wrapped definitions seems to be a popular feature
> anyway, and is not very hard to implement.
Well, I don't know that it's always "not very hard". I think it
depends on the system.
> I'm rather worried that such an implementation might not provide all
> the features we might want to have, in particular, having locals
> from outside the rounding block visible inside.
The thing that worries me, on the other hand, is that on some systems
that embed the rounding mode in the instruction, dynamic rounding modes
may not be possible at all, and as a consequence this long
conversation we're having may be a total waste of time. However, the
only way to simulate static rounding modes on hardware that only
supports dynamic rounding modes x87, say) is to set the mode at
: and ; . This problem seems to be inherently hard.
Andrew.