This is actually a poll about how widely the proposal is implemented
and how popular it is among the programmers.  It is called a CfV
(call-for-votes) because the process is inspired by the Usenet Rdf/CfV
process.

You find the actual ballot further down (look for "VOTING INSTRUCTIONS"),
after the proposal on which you vote.

RfD History
initial version  15 March 2012
version 1.1  First Revision  09 April 2012
Charles G. Montgomery <cgm@physics.utoledo.edu>

Problem

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.

Proposal

Add two words to the Floating Extension wordset:

S>F     "s-to-f"        ( n -- ) ( F: -- r ) or ( n -- r )
r is the floating-point equivalent of the single-cell value n.

F>S     "f-to-s"        ( -- n ) ( F: r -- ) or ( r -- n )
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.

Remarks

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.

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.

An alternative specification which avoids reference to the behavior of
other words could be:

F>S     "f-to-s"        ( -- n ) ( F: r -- ) or ( r -- n )
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 .)
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).

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.

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.

In practice, S>F is used much more often than F>S .


Reference implementation

ANS versions could be
: S>F  S>D D>F ;
: F>S  F>D D>S ;

Experience

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.

Besides this, systems that already provide the words include
VFX, Gforth, bigForth, 4tH.  I'm sure there are others.


VOTING INSTRUCTIONS

Fill out the appropriate ballot(s) below and mail it/them to me
<anton@mips.complang.tuwien.ac.at>. Your vote will be published
(including your name (without email address) and/or the name of your
system) on <http://www.forth200x.org/s-to-f.html>. You can vote (or
change your vote) at any time by mailing to me, and the results will
be published there.

Note that you can be both a system implementor and a programmer, so you
can submit both kinds of ballots.

Ballot for systems

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).

[ ] 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.

If you want to provide information on partial implementation, please do
so informally, and I will aggregate this information in some way.

Ballot for programmers

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.

[ ] 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.

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.

- 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 2012: http://www.euroforth.org/ef12/

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes Re: CfV: S>F and F>S

> F>S     "f-to-s"        ( -- n ) ( F: r -- ) or ( r -- n )
> 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.

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).

In other words  (32-bit system)
FORTH> 32e f2^x f>d drop H. $00000000 ok
FORTH> 32e f2^x f>s      H. $80000000 ok

(64-bit system)
FORTH> 32e f2^x f>d drop H. $0000000100000000 ok
FORTH> 32e f2^x f>s      H. $0000000100000000 ok

> An ambiguous condition exists if applying F>D to r would result in
> an ambiguous condition.

Isn't that kind of obvious?

-- ---------
Ballot for systems

[x] iForth 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 [ ].
[x] will never implement the proposal in full.
-- ----------

-marcel

Marcel Hendrix wrote:

> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes Re: CfV: S>F and
> F>S
> 
>> F>S     "f-to-s"        ( -- n ) ( F: r -- ) or ( r -- n )
>> 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.
> 
> 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).

Same with bigForth, which uses FISTP, and that does this sort of 
limitation.

> In other words  (32-bit system)
> FORTH> 32e f2^x f>d drop H. $00000000 ok
> FORTH> 32e f2^x f>s      H. $80000000 ok
> 
> (64-bit system)
> FORTH> 32e f2^x f>d drop H. $0000000100000000 ok
> FORTH> 32e f2^x f>s      H. $0000000100000000 ok
> 
>> An ambiguous condition exists if applying F>D to r would result in
>> an ambiguous condition.
> 
> Isn't that kind of obvious?

I suggested to cut&paste the definition of F>D and rephrase it so that 
the output is an n.  This was rejected by the proposer, it only went to 
the remarks...

> -- ---------
> Ballot for systems
> 
> [x] iForth 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 [ ].
> [x] will never implement the proposal in full.
> -- ----------

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.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

On Aug 2, 12:51=A0pm, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:
> This is actually a poll about how widely the proposal is implemented
> and how popular it is among the programmers. =A0It is called a CfV
> (call-for-votes) because the process is inspired by the Usenet Rdf/CfV
> process.
>
> You find the actual ballot further down (look for "VOTING INSTRUCTIONS"),
> after the proposal on which you vote.
>
> RfD History
> initial version =A015 March 2012
> version 1.1 =A0First Revision =A009 April 2012
> Charles G. Montgomery <c...@physics.utoledo.edu>
>
> Problem
>
> 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. =A0While this is possible using the standar=
d
> 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. =A0Many systems which provide floating
> point support already include CODE definitions to accomplish these
> tasks. =A0It may be useful for the Standard to include specifications
> for words to provide these capabilities.
>
>
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.

Krishna

Krishna Myneni wrote:
> I've argued that we need to remove "F to S" from the language for a
> time, in order to reset its spec.

I don't think we have to remove it.  We simply have to state that if the 
floating point number doesn't fit into an integer, this is an ambiguous 
condition.  We could specify F>S to have the same rounding mode as F>D, 
but then, yes, we have the problem that F>D does not specify a rounding 
mode (which is not really nice to easily write portable programs).

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

On Aug 3, 1:56=A0pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> Krishna Myneni wrote:
> > I've argued that we need to remove "F to S" from the language for a
> > time, in order to reset its spec.
>
> I don't think we have to remove it. =A0We simply have to state that if th=
e
> floating point number doesn't fit into an integer, this is an ambiguous
> condition. =A0We could specify F>S to have the same rounding mode as F>D,
> but then, yes, we have the problem that F>D does not specify a rounding
> mode (which is not really nice to easily write portable programs).
>
> --
> Bernd Paysan
> "If you want it done right, you have to do it yourself"http://bernd-paysa=
n.de/

I agree with what you say.

Krishna