forked from Forth-Standard/forth200x
/
s-to-f.html
256 lines (195 loc) · 9.27 KB
/
s-to-f.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
<title>S>F and F>S</title>
<h3>S>F and F>S</h3>
[ <a href="rfds.html">RfDs/CfVs</a> | <a href="proposals.html">Other proposals</a> ]
<h4>Poll standings</h4>
See <a href="#voting">below</a> for voting instructions.
<h5>Systems</h5>
<pre>
[ ] conforms to ANS Forth.
VFX Forth (Windows, OSX, Linux, DOS ...) (Stephen Pelc)
MPE Forth cross compilers (all targets) (Stephen Pelc)
iForth (Marcel Hendrix)
bigForth (Bernd Paysan)
SwiftForth (Leon Wagner)
[ ] already implements the proposal in full since release [ ].
4th v3.5d.3 (Hans Bezemer)
VFX Forth since 1998 (but see comment from Bernd Paysan below)
MPE Forth cross compilers (all targets)
SwiftForth 2.0
[ ] implements the proposal in full in a development version.
[ ] will implement the proposal in full in release [ ].
[ ] will implement the proposal in full in some future release.
[ ] There are no plans to implement the proposal in full in [ ].
[ ] will never implement the proposal in full.
iForth (Marcel Hendrix)
bigForth (Bernd Paysan)
</pre>
<h5>Programmers</h5>
<pre>
[ ] I have used (parts of) this proposal in my programs.
Hans Bezemer
Stephen Pelc
Graham Smith (used VFX Forth)
[ ] I would use (parts of) this proposal in my programs if the systems
I am interested in implemented it.
[ ] I would use (parts of) this proposal in my programs if this
proposal was in the Forth standard.
[ ] I would not use (parts of) this proposal in my programs.
</pre>
<h5>Informal results</h5>
Marcel Hendrix writes <05071301958435@frunobulax.edu>:
<pre>
iForth's F>S does not work that way. On a 32-bit system, F>S produces
at most +/-(2^31 - 1), on a 64-bit system that is +/-(2^63 - 1).
</pre>
Bernd Paysan agrees with Marcel and writes
<2492413.8maJAivhPE@sunwukong.fritz.box>:
<pre>
Same with bigForth. Why on earth should I generate an intermediate
double result just to drop the top half in order to meet this
specification?
The funny thing is that both iForth and bigForth have S>F and F>S. They
just don't confirm to this broken specification. Please, adjust the
specification, not the systems.
</pre>
Kryshna Myneni writes <915bf38a-0edc-41be-bd21-ff85dbf49f48@18g2000yqm.googlegroups.com>:
<pre>
I've argued that we need to remove "F to S" from the language for a
time, in order to reset its spec. This was based on finding that
different Forth systems performed different kinds of rounding. I can't
accept the proposal to define this word in terms of "F to D", unless
the spec. for "F to D" is clarified to be unambiguous with respect to
rounding. The other valid reason for not specifying "F to S" in terms
of "F to D" was given by both Marcel and Bernd. I also don't plan to
implement this proposed "F to S" in kForth.
</pre>
Bernd Paysan writes <2582576.MVdGcY4r0L@sunwukong.fritz.box>:
<pre>
VFX does the same thing Marcel and I am doing, it uses
FSTP to a dword. Which means the Intel architecture overflow handling
checks for overflow, and therefore
> : F>S F>D D>S ;
does not produce the same result.
1e15 f>d drop . -1530494976 ok
1e15 f>s . -2147483648 ok
</pre>
<h4>Change History</h4>
initial version 15 March 2012<br>
version 1.1 First Revision 09 April 2012<br>
Charles G. Montgomery <tt>cgm<tt>@</tt>physics.utoledo.edu</tt>
<h4>Problem</h4>
It is not uncommon in forth programs using floating point to need to
convert a single-cell value to its floating point representation, or
the reverse, for further use. While this is possible using the standard
words S>D D>F F>D and D>S , it can be inconvenient, and may result in
inefficiency by forcing a conversion to double numbers, particularly
on systems with a large cell size. Many systems which provide floating
point support already include CODE definitions to accomplish these
tasks. It may be useful for the Standard to include specifications
for words to provide these capabilities.
<h4>Proposal</h4>
Add two words to the Floating Extension wordset:
<pre>
S>F "s-to-f" ( n -- ) ( F: -- r ) or ( n -- r )
</pre>
r is the floating-point equivalent of the single-cell value n.
<pre>
F>S "f-to-s" ( -- n ) ( F: r -- ) or ( r -- n )
</pre>
n is the less significant portion of the double word that would be
produced by the word F>D applied to the floating-point value r.
An ambiguous condition exists if applying F>D to r would result in
an ambiguous condition.
<h4>Remarks</h4>
Specifying F>S in terms of the behavior of F>D should prevent any
ambiguity that isn't already present in F>D, and inherit its
freedom from overspecification. It should ease the task of adding
these words to a system that doesn't already provide them but does
include the floating-point word set. Of course it's an
"as if" specification. The value n is what would result from
executing F>D D>S , although it need not be obtained that way.
<p>Discussions in response to the original version of this proposal
have largely concentrated on the issue of whether it is good or bad to
specify the behavior of the proposed word F>S in terms of the specified
behavior of other words. I recognize valid points made on both sides
of this issue; I fail to find either side overwhelmingly persuasive.
<p>An alternative specification which avoids reference to the behavior of
other words could be:
<pre>
F>S "f-to-s" ( -- n ) ( F: r -- ) or ( r -- n )
</pre>
n is one of the single-cell values that corresponds to the floating-
point value r. If more than one integer corresponds to r in the
particular implementation of integer and floating-point values
provided by the system, it is implementation-dependent which of them
is returned. A program which relies on a specific choice must
declare an environmental dependency (or include code to guarantee
the desired result, for example by using words like FLOOR or FROUND
before F>S .)
<p>An ambiguous condition exists if the floating point representation
in use does not specify an corresponding integer (for example, NAN
or INF or some such).
<p>This form of specification is even less precise than the previous,
since it provides no requirement of consistency in the behavior of
the two similar words F>D and F>S , which might be considered either
an advantage or a disadvantage. It seems to be consistent with the
general disinclination to restrict floating-point implementations,
as expressed in Section 12.3.1.2.
<p>There have also been suggestions for adding a larger set of new words,
such as FROUND>S , FTRUNC>S , which specify the rounding method of the
floating point value. But in the cases where this is needed it can be
handled before invoking F>S.
<p>In practice, S>F is used much more often than F>S .
<h4>Reference implementation</h4>
ANS versions could be
<pre>
: S>F S>D D>F ;
: F>S F>D D>S ;
</pre>
<h4>Experience</h4>
The Forth Scientific Library utility files provide high-level
definitions for these words, so they are available in some form
in any system that provides the FSL.
<p>Besides this, systems that already provide the words include
VFX, Gforth, bigForth, 4tH. I'm sure there are others.
<h4><a name="voting">Voting instructions</a></h4>
Fill out the appropriate ballot(s) below and mail it/them to me
<anton<tt>@</tt>mips.complang.tuwien.ac.at>. Your vote will be published
(including your name (without email address) and/or the name of your
system) here. You can vote (or change your vote) at any time by
mailing to me, and the results will be published here.
<p>Note that you can be both a system implementor and a programmer, so
you can submit both kinds of ballots.
<h5>Ballot for systems</h5>
If you maintain several systems, please mention the systems separately
in the ballot. Insert the system name or version between the brackets
or in the line below the statement. Multiple hits for the same system
are possible (if they do not conflict).
<pre>
[ ] conforms to ANS Forth.
[ ] already implements the proposal in full since release [ ].
[ ] implements the proposal in full in a development version.
[ ] will implement the proposal in full in release [ ].
[ ] will implement the proposal in full in some future release.
[ ] There are no plans to implement the proposal in full in [ ].
[ ] will never implement the proposal in full.
</pre>
If you want to provide information on partial implementation, please do
so informally, and I will aggregate this information in some way.
<h5>Ballot for programmers</h5>
Just mark the statements that are correct for you (e.g., by putting
your name on the line below the statement you agree with). If some
statements are true for some of your programs, but not others, please
mark the statements for the dominating class of programs you write.
<pre>
[ ] I have used (parts of) this proposal in my programs.
[ ] I would use (parts of) this proposal in my programs if the systems
I am interested in implemented it.
[ ] I would use (parts of) this proposal in my programs if this
proposal was in the Forth standard.
[ ] I would not use (parts of) this proposal in my programs.
</pre>
If you feel that there is closely related functionality missing from the
proposal (especially if you have used that in your programs), make an
informal comment, and I will collect these, too. Note that the best time
to voice such issues is the RfD stage.