Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #14667 > unrolled thread

CfV: S>F and F>S

Back to article view | Back to comp.lang.forth

Contents

  CfV: S>F and F>S anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-02 16:51 +0000
    Re: CfV: S>F and F>S mhx@iae.nl (Marcel Hendrix) - 2012-08-02 22:28 +0200
      Re: CfV: S>F and F>S Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-02 23:36 +0200
    Re: CfV: S>F and F>S Krishna Myneni <krishna.myneni@ccreweb.org> - 2012-08-03 04:39 -0700
      Re: CfV: S>F and F>S Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-03 19:56 +0200
        Re: CfV: S>F and F>S mhx@iae.nl (Marcel Hendrix) - 2012-08-03 21:18 +0200
          Re: CfV: S>F and F>S anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-04 09:50 +0000
            Re: CfV: S>F and F>S Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-04 21:51 +0200
              Presence of standard words (was: CfV: S>F and F>S) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-05 11:07 +0000
                Re: Presence of standard words (was: CfV: S>F and F>S) stephenXXX@mpeforth.com (Stephen Pelc) - 2012-08-05 11:34 +0000
                  Re: Presence of standard words (was: CfV: S>F and F>S) Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-05 13:59 +0200
                  Re: Presence of standard words (was: CfV: S>F and F>S) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-06 11:22 +0000
          Re: CfV: S>F and F>S Krishna Myneni <krishna.myneni@ccreweb.org> - 2012-08-04 04:50 -0700
            Re: CfV: S>F and F>S stephenXXX@mpeforth.com (Stephen Pelc) - 2012-08-04 12:30 +0000
              Re: CfV: S>F and F>S C G Montgomery <cgm@physics.utoledo.edu> - 2012-08-05 09:14 -0400
            Re: CfV: S>F and F>S Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-04 21:47 +0200
        Re: CfV: S>F and F>S Krishna Myneni <krishna.myneni@ccreweb.org> - 2012-08-04 05:42 -0700

#14667 — CfV: S>F and F>S

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/

[toc] | [next] | [standalone]

#14670

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

[toc] | [prev] | [next] | [standalone]

#14673

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/

[toc] | [prev] | [next] | [standalone]

#14685

On Aug 2, 12:51 pm, 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.  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 <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.  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.
>
>
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

[toc] | [prev] | [next] | [standalone]

#14700

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/

[toc] | [prev] | [next] | [standalone]

#14702

Bernd Paysan <bernd.paysan@gmx.de> writes Re: CfV: S>F and F>S
[..]
> 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).

I am probably going to end up with egg on my face.

F>D                 "f-to-d"                                          FLOAT
     ( -- d ) ( F: r -- )
     d is the double-cell signed integer equivalent to the integer portion of
     r. The fractional portion of r is discarded. An ambiguous condition
     exists if the integer portion of r cannot be precisely represented as a
     double-cell signed integer.


*The fractional portion of r is discarded*

Why do I need to know the rounding mode for this?

1.0001e F>S . 1
0.5e    F>S . 0
0.999e  F>S . 0
-0.999e F>S . 0
-1e     F>S . -1

Yes, I must do something to the 'rounding mode' to get this *integer 
portion*, but the Forth code does not need to know what that is to
recognize I have provided the correct result.

Note also that the spec. says "SIGNED integer equivalent." Doing 
F>D DROP  is certainly not preserving the sign, so I'd argue it is 
against the spirit of F>D .

-marcel

[toc] | [prev] | [next] | [standalone]

#14723

mhx@iae.nl (Marcel Hendrix) writes:
>Bernd Paysan <bernd.paysan@gmx.de> writes Re: CfV: S>F and F>S
>[..]
>> we have the problem that F>D does not specify a rounding 
>> mode (which is not really nice to easily write portable programs).
>
>I am probably going to end up with egg on my face.
>
>F>D                 "f-to-d"                                          FLOAT
>     ( -- d ) ( F: r -- )
>     d is the double-cell signed integer equivalent to the integer portion of
>     r. The fractional portion of r is discarded. An ambiguous condition
>     exists if the integer portion of r cannot be precisely represented as a
>     double-cell signed integer.
>
>
>*The fractional portion of r is discarded*
>
>Why do I need to know the rounding mode for this?
>
>1.0001e F>S . 1
>0.5e    F>S . 0
>0.999e  F>S . 0
>-0.999e F>S . 0
>-1e     F>S . -1

That's round towards zero.  Gforth's F>S and F>D also round towards 0

While I don't find the wording above crystal-clear, it's apparently
clear enough that we arrived at the same conclusion (and that I did
not make an RFI to the Forth-94 TC).

Which Forth systems perform which kind of rounding?

Let's try a few:

-------------------------------------------
 VFX Forth for Linux IA32
 © MicroProcessor Engineering Ltd, 1998-2009 

 Version: 4.40 [build 0404]
 Build date: 7 December 2009

 Free dictionary = 7922527 bytes [7736kb]


0.999e  F>S . 0 
Err# -13 ERR: Undefined word.
 -> 0.999e  F>S . 0
          ^
---------------------------------------------
SwiftForth i386-Linux 3.2.1 28-Dec-2009 
0.999e  F>S . 0 0.999e ?
----------------------------------------------
                       ANS bigFORTH 386-Linux rev. 2.3.1

0.999e  F>S .  don't know  0.999e 
----------------------------------------------

Oh yeah, sorry, I forgot that I am not supposed to test different
Forth systems.

- 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/

[toc] | [prev] | [next] | [standalone]

#14734

Anton Ertl wrote:
>                        ANS bigFORTH 386-Linux rev. 2.3.1
> 
> 0.999e  F>S .  don't know  0.999e
> ----------------------------------------------
> 
> Oh yeah, sorry, I forgot that I am not supposed to test different
> Forth systems.

You might put a note somewhere to tell you what magic these different 
systems require to load the optional floating point wordset.  In 
bigForth, it's "import float".

It is, after all, an *optional* wordset.

We should at least have a standard way to do this.

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

[toc] | [prev] | [next] | [standalone]

#14737 — Presence of standard words (was: CfV: S>F and F>S)

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>>                        ANS bigFORTH 386-Linux rev. 2.3.1
>> 
>> 0.999e  F>S .  don't know  0.999e
>> ----------------------------------------------
>> 
>> Oh yeah, sorry, I forgot that I am not supposed to test different
>> Forth systems.
>
>You might put a note somewhere to tell you what magic these different 
>systems require to load the optional floating point wordset.  In 
>bigForth, it's "import float".

                       ANS bigFORTH 386-Linux rev. 2.3.1

import float  ok
0.999e  F>S .  don't know  F>S 
0.999e  F>D d.  don't know  F>D 

Well, at least it understands FP literals after "import float".

>It is, after all, an *optional* wordset.

That means that a system does not need to provide it, not that arcane
incantations should be necessary to load it.  The file wordset is also
optional, do I have to IMPORT that, too, on bigForth?

>We should at least have a standard way to do this.

Maybe.  Or just have all the optional wordsets you have loaded from
the start.  Arcane incantations or maybe less arcane standardized
incantations may be appropriate for embedded systems, but on a big
machine?  No.  And even on embedded systems the system could leave
unused words away, no need for arcane or standardized incantations.

- 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/

[toc] | [prev] | [next] | [standalone]

#14738 — Re: Presence of standard words (was: CfV: S>F and F>S)

On Sun, 05 Aug 2012 11:07:23 GMT, anton@mips.complang.tuwien.ac.at
(Anton Ertl) wrote:

>Arcane incantations or maybe less arcane standardized
>incantations may be appropriate for embedded systems, but on a big
>machine?  No.  And even on embedded systems the system could leave
>unused words away, no need for arcane or standardized incantations.

And for those systems that have a choice of (say) floating point
packages. What does
  load-wordset float
actually do? You now have to specify which one. The same applies
for embedded systems. For example, on an ARM Cortex (M0/M1, M3,
and M4) there's a choice of three instruction sets, one with 32
bit floats. If you really want to standardise all this stuff,
you need to standardise real life. Nobody has ever managed that.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

[toc] | [prev] | [next] | [standalone]

#14739 — Re: Presence of standard words (was: CfV: S>F and F>S)

Stephen Pelc wrote:

> On Sun, 05 Aug 2012 11:07:23 GMT, anton@mips.complang.tuwien.ac.at
> (Anton Ertl) wrote:
> 
>>Arcane incantations or maybe less arcane standardized
>>incantations may be appropriate for embedded systems, but on a big
>>machine?  No.  And even on embedded systems the system could leave
>>unused words away, no need for arcane or standardized incantations.
> 
> And for those systems that have a choice of (say) floating point
> packages. What does
>   load-wordset float
> actually do? You now have to specify which one.

Now that can be system-sepcific.  You have three different FP packages 
for x86, either, but one is the "lead package".  You can make this 
choice for your other platforms, too.

The fact that bigForth FP package is optional comes from a time where 
there were more than one package, too.  And I wanted to write an SSE-
based floating point package, but never got there.  In the end, you now 
have three choices on most recent x86: 387 instructions, SSE 
instructions and AVX instructions.  The reasonable default depends on 
your processor, so a system can do that choice for you.

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

[toc] | [prev] | [next] | [standalone]

#14769 — Re: Presence of standard words (was: CfV: S>F and F>S)

stephenXXX@mpeforth.com (Stephen Pelc) writes:
>On Sun, 05 Aug 2012 11:07:23 GMT, anton@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>
>>Arcane incantations or maybe less arcane standardized
>>incantations may be appropriate for embedded systems, but on a big
>>machine?  No.  And even on embedded systems the system could leave
>>unused words away, no need for arcane or standardized incantations.
>
>And for those systems that have a choice of (say) floating point
>packages. What does
>  load-wordset float
>actually do? You now have to specify which one.

No.  I would have a default, and an arcane incantation for selecting a
non-default package.  I would use a command-line option or the binary
name for the selection, but as long as there is a sensible default,
any other way for selecting the non-default should be fine; or, as
Bernd suggested, if the choice depends on the actual hardware, look at
what the actual hardware is.

> The same applies
>for embedded systems. For example, on an ARM Cortex (M0/M1, M3,
>and M4) there's a choice of three instruction sets, one with 32
>bit floats. If you really want to standardise all this stuff,
>you need to standardise real life. Nobody has ever managed that.

Let's see how other compilers do it: GCC does it through command-line
options: <http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html>, in
particular --mfloat-abi=soft/softfp/hard. "The default depends on the
specific target configuration."  GCC does not require arcane
incantations in the source code of the compiled program and
understands floats even if you don't specify --mfloat-abi.  

- 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/

[toc] | [prev] | [next] | [standalone]

#14724

On Aug 3, 3:18 pm, m...@iae.nl (Marcel Hendrix) wrote:
> Bernd Paysan <bernd.pay...@gmx.de> writes Re: CfV: S>F and F>S
> [..]
>
> > 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).
>
> I am probably going to end up with egg on my face.
>
> F>D                 "f-to-d"                                          FLOAT
>      ( -- d ) ( F: r -- )
>      d is the double-cell signed integer equivalent to the integer portion of
>      r. The fractional portion of r is discarded. An ambiguous condition
>      exists if the integer portion of r cannot be precisely represented as a
>      double-cell signed integer.
>
> *The fractional portion of r is discarded*
>
> Why do I need to know the rounding mode for this?
>
> 1.0001e F>S . 1
> 0.5e    F>S . 0
> 0.999e  F>S . 0
> -0.999e F>S . 0
> -1e     F>S . -1
>
> Yes, I must do something to the 'rounding mode' to get this *integer
> ...

As Anton points out, this is round towards zero, and the language was
apparently ambiguous enough for at least one major Forth system to
implement it differently. I believe you posted that discrepancy a few
years ago, Marcel. In the discussion which ensued, the consensus was
that the spec was clumsily written, and trying to indicate round
towards zero. I recall Stephen Pelc saying that VFX Forth would be
fixed to conform to this interpretation. So, it would be worthwhile to
clean up the spec for "F to D".

Krishna

[toc] | [prev] | [next] | [standalone]

#14726

On Sat, 4 Aug 2012 04:50:19 -0700 (PDT), Krishna Myneni
<krishna.myneni@ccreweb.org> wrote:

>As Anton points out, this is round towards zero, and the language was
>apparently ambiguous enough for at least one major Forth system to
>implement it differently.

Our change notes suggest that the discussion was in October 2002.

The rationale behind the now-deprecated behaviour was that other
FP words are permitted to be sensitive to a current rounding mode.

>I believe you posted that discrepancy a few
>years ago, Marcel. In the discussion which ensued, the consensus was
>that the spec was clumsily written, and trying to indicate round
>towards zero. I recall Stephen Pelc saying that VFX Forth would be
>fixed to conform to this interpretation. So, it would be worthwhile to
>clean up the spec for "F to D".

I agree.

A side effect of the discussion was that we had to introduce FR>D
and FR>S, which behave according to the current rounding mode, in
order to preserve the previous functionality.

The most convincing argument for the new behaviour is that the FSL
requires it.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

[toc] | [prev] | [next] | [standalone]

#14740

Stephen Pelc stephenXXX@mpeforth.com wrote:

> ...
> The most convincing argument for the new behaviour is that the FSL
> requires it.
> 

It's a bit too strong to say that the FSL requires any particular version 
of F>S .  FSL utility files include a version for the convenience of 
users.  I don't believe any of the actual uses of F>S is the current 
Library Algorithms are sensitive to the kinds of variations among 
implementations that are being discussed here.

If a Forth200x standard definition for F>S is adopted, I expect the 
utility files will provide something that is consistent with it.  If not, 
things will probably stay as they are.  (Those possibilities are not 
necessarily disjoint.  ;-)  )

regards to all   cgm

[toc] | [prev] | [next] | [standalone]

#14733

Krishna Myneni wrote:
> As Anton points out, this is round towards zero, and the language was
> apparently ambiguous enough for at least one major Forth system to
> implement it differently. I believe you posted that discrepancy a few
> years ago, Marcel. In the discussion which ensued, the consensus was
> that the spec was clumsily written, and trying to indicate round
> towards zero.

Yes, that seems to be the case.  I just remembered a discussion that 
people didn't fully agree on what dropping the fractional part is, and 
floored rounding seems to be another option.

> I recall Stephen Pelc saying that VFX Forth would be
> fixed to conform to this interpretation. So, it would be worthwhile to
> clean up the spec for "F to D".

Probably.

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

[toc] | [prev] | [next] | [standalone]

#14727

On Aug 3, 1:56 pm, 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.  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/

I agree with what you say.

Krishna

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.forth

csiph-web