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

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

RfD: S>F and F>S First Revision

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

Contents

  RfD: S>F and F>S  First Revision C G Montgomery <cgm@physics.utoledo.edu> - 2012-04-10 16:02 -0400
    Re: RfD: S>F and F>S First Revision Krishna Myneni <krishna.myneni@ccreweb.org> - 2012-04-12 19:29 -0700
      Re: RfD: S>F and F>S First Revision Hans Bezemer <the.beez.speaks@gmail.com> - 2012-04-13 09:02 +0200
        Re: RfD: S>F and F>S First Revision Krishna Myneni <krishna.myneni@ccreweb.org> - 2012-04-13 03:01 -0700
          Re: RfD: S>F and F>S First Revision Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-04-13 05:30 -0500
            Re: RfD: S>F and F>S First Revision Krishna Myneni <krishna.myneni@ccreweb.org> - 2012-04-14 17:43 -0700
              Re: RfD: S>F and F>S First Revision Bernd Paysan <bernd.paysan@gmx.de> - 2012-04-15 02:49 +0200
                Re: RfD: S>F and F>S First Revision Krishna Myneni <krishna.myneni@ccreweb.org> - 2012-04-14 20:25 -0700
              Re: RfD: S>F and F>S First Revision Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-04-15 03:11 -0500
                Re: RfD: S>F and F>S First Revision Krishna Myneni <krishna.myneni@ccreweb.org> - 2012-04-15 07:23 -0700
                  Re: RfD: S>F and F>S First Revision Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-04-15 09:39 -0500
                    Re: RfD: S>F and F>S First Revision Krishna Myneni <krishna.myneni@ccreweb.org> - 2012-04-15 19:12 -0700
                      Re: RfD: S>F and F>S First Revision Paul Rubin <no.email@nospam.invalid> - 2012-04-15 19:23 -0700
                        Re: RfD: S>F and F>S First Revision Krishna Myneni <krishna.myneni@ccreweb.org> - 2012-04-15 19:50 -0700
                        Re: RfD: S>F and F>S First Revision Krishna Myneni <krishna.myneni@ccreweb.org> - 2012-04-15 20:08 -0700
                          Re: RfD: S>F and F>S First Revision Paul Rubin <no.email@nospam.invalid> - 2012-04-15 21:01 -0700
                            Re: RfD: S>F and F>S First Revision jacko <jackokring@gmail.com> - 2012-04-16 05:32 -0700
                              Re: RfD: S>F and F>S First Revision Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-04-16 07:45 -0500
                              Re: RfD: S>F and F>S First Revision anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-16 13:08 +0000
      Re: RfD: S>F and F>S First Revision Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-04-13 19:20 +0000
        Re: RfD: S>F and F>S First Revision Krishna Myneni <krishna.myneni@ccreweb.org> - 2012-04-14 17:46 -0700
          Re: RfD: S>F and F>S First Revision Hans Bezemer <the.beez.speaks@gmail.com> - 2012-04-15 12:20 +0200

Page 1 of 2  [1] 2  Next page →

#11126 — RfD: S>F and F>S First Revision

RfD:  S>F and F>S
version 1.1  First Revision  09 April 2012
Charles G. Montgomery <cgm@physics.utoledo.edu>

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.

So this revision, in addition to some other minor improvements, 
provides two alternative specifications, labeled A) and B) below,  
I have moved the "Remarks" section for each next to the corresponding 
"Proposal" section.

I, myself, don't really care which is preferred.  As a user, I would 
like to see standardization of these two words.  (As a user of floating 
point I know I will always need to check whether peculiarities of an 
implementation need to be corrected for in order to get the right answers, 
but no Standard will relieve me of that burden.)

I, myself, would oppose any form of specification which adds new
requirements on what particular implementation of floating-point
is used by a standard system providing these words.

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.

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

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.

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

Remarks

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.

\ end of RfD

[toc] | [next] | [standalone]

#11231 — Re: RfD: S>F and F>S First Revision

On Apr 10, 3:02 pm, C G Montgomery <c...@physics.utoledo.edu> wrote:
> RfD:  S>F and F>S
> version 1.1  First Revision  09 April 2012
> Charles G. Montgomery <c...@physics.utoledo.edu>
>
...
> A)
> 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.
>
> 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.
>
> B)
> 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 .) ...

This is a particularly *bad* idea, IMO. The specification of F>S, as
with the existing spec. for F>D, should specify the type of rounding.
Leaving this specification open will almost certainly lead to non-
portability of code and vicious bugs. This is why I believe the
primitives, FROUND>S, FTRUNC>S, and maybe FCEIL>S are more important
to standardize.

Krishna

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

#11235 — Re: RfD: S>F and F>S First Revision

Krishna Myneni wrote:

> On Apr 10, 3:02 pm, C G Montgomery <c...@physics.utoledo.edu> wrote:
> This is a particularly *bad* idea, IMO. The specification of F>S, as
> with the existing spec. for F>D, should specify the type of rounding.
Agreed: "d is the double-cell signed-integer equivalent of the integer
portion of r. The fractional portion of r is discarded."

> Leaving this specification open will almost certainly lead to non-
> portability of code and vicious bugs. This is why I believe the
> primitives, FROUND>S, FTRUNC>S, and maybe FCEIL>S are more important
> to standardize.
I really don't see this. We already got FROUND, FTRUNC. FCEIL is something
to be discussed (it's not in the standard yet). It someone wants a
particular way of rounding this will do as well:

        FROUND F>S

I don't see why you need to pollute the standard with a myriad of variations
on the same theme. Before you know it we also got:

        FROUND>D, FTRUNC>D, and maybe FCEIL>D

Then we have to obsolete D>F and F>D. All very messy. Let's define some good
building blocks instead of specialized and very clever words. I think
that's good Forth practice.

Hans Bezemer

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

#11238 — Re: RfD: S>F and F>S First Revision

On Apr 13, 2:02 am, Hans Bezemer <the.beez.spe...@gmail.com> wrote:
> Krishna Myneni wrote:
> > On Apr 10, 3:02 pm, C G Montgomery <c...@physics.utoledo.edu> wrote:
> > This is a particularly *bad* idea, IMO. The specification of F>S, as
> > with the existing spec. for F>D, should specify the type of rounding.
>
> Agreed: "d is the double-cell signed-integer equivalent of the integer
> portion of r. The fractional portion of r is discarded."
>
> > Leaving this specification open will almost certainly lead to non-
> > portability of code and vicious bugs. This is why I believe the
> > primitives, FROUND>S, FTRUNC>S, and maybe FCEIL>S are more important
> > to standardize.
>
> I really don't see this. We already got FROUND, FTRUNC. FCEIL is something
> to be discussed (it's not in the standard yet). It someone wants a
> particular way of rounding this will do as well:
>
>         FROUND F>S
>
> I don't see why you need to pollute the standard with a myriad of variations
> on the same theme. Before you know it we also got:
>
>         FROUND>D, FTRUNC>D, and maybe FCEIL>D
>
> Then we have to obsolete D>F and F>D. All very messy. Let's define some good
> building blocks instead of specialized and very clever words. I think
> that's good Forth practice.
>
> Hans Bezemer

We've had this discussion previously in regard to F>D. The wording of
the ANS Forth spec for F>D implies rounding towards zero, and it's
hard to argue that the wording matches any of the other forms of
rounding (round to nearest, round to negative infinity, or round to
positive infinity). That interpretation has been widely adopted now,
although perhaps not universally among Forth implementations. In fact,
it would be a good idea to revise the F>D spec to explicitly state
"rounding towards zero". Given the existing spec for F>D, it is
inconsistent to leave the rounding mode of F>S be unspecified.

The more important aspect of this is that an F>S with an unspecified
rounding mode is entirely useless for calculations involving fp. The
calculation would not be reproducible across Forth systems. What would
even be the purpose of having a word such an F>S? Why would you use it
in code if the resulting value for an argument of 2.51e could be 2 on
one Forth system, but 3 on another? The proposed spec for F>S leaves
open such a possibility.

Btw, we also have FLOOR. The word FCIEL (round towards positive inf)
does need to be added for completeness ... as soon as we figure out
its proper spelling!

Krishna

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

#11239 — Re: RfD: S>F and F>S First Revision

Krishna Myneni <krishna.myneni@ccreweb.org> wrote:
> 
> Btw, we also have FLOOR. The word FCIEL (round towards positive inf)
> does need to be added for completeness ... as soon as we figure out
> its proper spelling!

Why should it be added?  "For completeness" isn't a good enough
reason: it also has to be useful.  On the odd occasion it was really
needed it'd be easy enough to define with FLOOR .

Andrew.

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

#11303 — Re: RfD: S>F and F>S First Revision

On Apr 13, 5:30 am, Andrew Haley <andre...@littlepinkcloud.invalid>
wrote:
> Krishna Myneni <krishna.myn...@ccreweb.org> wrote:
>
> > Btw, we also have FLOOR. The word FCIEL (round towards positive inf)
> > does need to be added for completeness ... as soon as we figure out
> > its proper spelling!
>
> Why should it be added?  "For completeness" isn't a good enough
> reason: it also has to be useful.  On the odd occasion it was really
> needed it'd be easy enough to define with FLOOR .
>
> Andrew.

Several reasons:

1) I have used the ceiling function before in code. It's not that
uncommon.

2) We should learn from the experience of other languages used for
numerical/scientific computation. For example, CEILING has been added
in Fortran 90.

3) There is not a trivial definition of FCEIL using FLOOR, unless I'm
missing seeing it.

Krishna

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

#11305 — Re: RfD: S>F and F>S First Revision

Krishna Myneni wrote:
> 3) There is not a trivial definition of FCEIL using FLOOR, unless I'm
> missing seeing it.

: fceil ( r1 -- r2 ) fnegate floor fnegate ;
: ftrunc ( r1 -- r2 )  fdup f0< IF  fceil  ELSE  floor  THEN ;

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

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

#11306 — Re: RfD: S>F and F>S First Revision

On Apr 14, 7:49 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> Krishna Myneni wrote:
> > 3) There is not a trivial definition of FCEIL using FLOOR, unless I'm
> > missing seeing it.
>
> : fceil ( r1 -- r2 ) fnegate floor fnegate ;
...

Nice. Thanks.

Krishna

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

#11310 — Re: RfD: S>F and F>S First Revision

Krishna Myneni <krishna.myneni@ccreweb.org> wrote:
> On Apr 13, 5:30?am, Andrew Haley <andre...@littlepinkcloud.invalid>
> wrote:
>> Krishna Myneni <krishna.myn...@ccreweb.org> wrote:
>>
>> > Btw, we also have FLOOR. The word FCIEL (round towards positive inf)
>> > does need to be added for completeness ... as soon as we figure out
>> > its proper spelling!
>>
>> Why should it be added? "For completeness" isn't a good enough
>> reason: it also has to be useful. On the odd occasion it was really
>> needed it'd be easy enough to define with FLOOR .
> 
> Several reasons:
> 
> 1) I have used the ceiling function before in code. It's not that
> uncommon.
> 
> 2) We should learn from the experience of other languages used for
> numerical/scientific computation. For example, CEILING has been
> added in Fortran 90.

I'll accept 1 but not 2.  Other languages prize orthogonality, but
Forth prizes usefulness: it's what makes Forth neat and trim.  I know
lots of uses for FLOOR, but CEILING is not so useful.

> 3) There is not a trivial definition of FCEIL using FLOOR, unless I'm
> missing seeing it.

fnegate floor fnegate ?

Andrew.

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

#11316 — Re: RfD: S>F and F>S First Revision

On Apr 15, 3:11 am, Andrew Haley <andre...@littlepinkcloud.invalid>
wrote:
> Krishna Myneni <krishna.myn...@ccreweb.org> wrote:
> > On Apr 13, 5:30?am, Andrew Haley <andre...@littlepinkcloud.invalid>
> > wrote:
> >> Krishna Myneni <krishna.myn...@ccreweb.org> wrote:
>
> >> > Btw, we also have FLOOR. The word FCIEL (round towards positive inf)
> >> > does need to be added for completeness ... as soon as we figure out
> >> > its proper spelling!
>
> >> Why should it be added? "For completeness" isn't a good enough
> >> reason: it also has to be useful. On the odd occasion it was really
> >> needed it'd be easy enough to define with FLOOR .
>
> > Several reasons:
>
> > 1) I have used the ceiling function before in code. It's not that
> > uncommon.
>
> > 2) We should learn from the experience of other languages used for
> > numerical/scientific computation. For example, CEILING has been
> > added in Fortran 90.
>
> I'll accept 1 but not 2.  Other languages prize orthogonality, but
> Forth prizes usefulness: it's what makes Forth neat and trim.  I know
> lots of uses for FLOOR, but CEILING is not so useful.
>

What do you mean by orthogonality? In the mathematical sense,
orthogonality implies that a function can't be expressed in terms of
the existing (basis) functions. Clearly, as you and Bernd show, the
CEILING function is not orthogonal, since it can be defined with
FNEGATE and FLOOR.

I agree that expanding a language spec must be done judiciously, and
we should avoid the temptation to throw everything into the spec.
However, a lean language can be orthogonal to a usable language
(orthogonal used in a geometric sense). When a user has to implement
even basic arithmetic functions in source, that's not particularly
useful. Given a choice of usability (richness of available words) over
lean, I'd pick usability --- the need for very lean systems has
largely disappeared in the desktop world.

Krishna

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

#11317 — Re: RfD: S>F and F>S First Revision

Krishna Myneni <krishna.myneni@ccreweb.org> wrote:
> On Apr 15, 3:11?am, Andrew Haley <andre...@littlepinkcloud.invalid>
> wrote:
>> Krishna Myneni <krishna.myn...@ccreweb.org> wrote:
>> > On Apr 13, 5:30?am, Andrew Haley <andre...@littlepinkcloud.invalid>
>> > wrote:
>> >> Krishna Myneni <krishna.myn...@ccreweb.org> wrote:
>>
>> >> > Btw, we also have FLOOR. The word FCIEL (round towards positive inf)
>> >> > does need to be added for completeness ... as soon as we figure out
>> >> > its proper spelling!
>>
>> >> Why should it be added? "For completeness" isn't a good enough
>> >> reason: it also has to be useful. On the odd occasion it was really
>> >> needed it'd be easy enough to define with FLOOR .
>>
>> > Several reasons:
>>
>> > 1) I have used the ceiling function before in code. It's not that
>> > uncommon.
>>
>> > 2) We should learn from the experience of other languages used for
>> > numerical/scientific computation. For example, CEILING has been
>> > added in Fortran 90.
>>
>> I'll accept 1 but not 2. Other languages prize orthogonality, but
>> Forth prizes usefulness: it's what makes Forth neat and trim. I
>> know lots of uses for FLOOR, but CEILING is not so useful.
> 
> What do you mean by orthogonality? In the mathematical sense,
> orthogonality implies that a function can't be expressed in terms of
> the existing (basis) functions. Clearly, as you and Bernd show, the
> CEILING function is not orthogonal, since it can be defined with
> FNEGATE and FLOOR.

Perhaps that was the wrong word to use: ALGOL 68 used it in the sense
that every language feature should, where possible, work with every
other. But let's not focus on the word.

> I agree that expanding a language spec must be done judiciously,
> and we should avoid the temptation to throw everything into the
> spec.  However, a lean language can be orthogonal to a usable
> language (orthogonal used in a geometric sense). When a user has to
> implement even basic arithmetic functions in source, that's not
> particularly useful.

True, but CEILING is so unusual that usually they won't.

> Given a choice of usability (richness of available words) over lean,
> I'd pick usability --- the need for very lean systems has largely
> disappeared in the desktop world.

Oh for God's sake, this is Forth!  What is Forth, if not the leanest
cleanest practical programming language and environment?  You don't
just put stuff in for the sake of symmetry; every word must prove its
worth.  This is the defining design principle of Forth, as everyone
who has read _The Evolution Of Forth_ knows.

But maybe CEILING really is useful.  If so, I'm sure you can tell us
how useful it is.

Andrew.

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

#11340 — Re: RfD: S>F and F>S First Revision

On Apr 15, 9:39 am, Andrew Haley <andre...@littlepinkcloud.invalid>
wrote:
> Krishna Myneni <krishna.myn...@ccreweb.org> wrote:
> > On Apr 15, 3:11?am, Andrew Haley <andre...@littlepinkcloud.invalid>
> > wrote:
> >> Krishna Myneni <krishna.myn...@ccreweb.org> wrote:
> >> > On Apr 13, 5:30?am, Andrew Haley <andre...@littlepinkcloud.invalid>
> >> > wrote:
> >> >> Krishna Myneni <krishna.myn...@ccreweb.org> wrote:
>
> >> >> > Btw, we also have FLOOR. The word FCIEL (round towards positive inf)
> >> >> > does need to be added for completeness ... as soon as we figure out
> >> >> > its proper spelling!
>
> >> >> Why should it be added? "For completeness" isn't a good enough
> >> >> reason: it also has to be useful. On the odd occasion it was really
> >> >> needed it'd be easy enough to define with FLOOR .
>
> >> > Several reasons:
>
> >> > 1) I have used the ceiling function before in code. It's not that
> >> > uncommon.
>
> >> > 2) We should learn from the experience of other languages used for
> >> > numerical/scientific computation. For example, CEILING has been
> >> > added in Fortran 90.
>
> >> I'll accept 1 but not 2. Other languages prize orthogonality, but
> >> Forth prizes usefulness: it's what makes Forth neat and trim. I
> >> know lots of uses for FLOOR, but CEILING is not so useful.
>
> > What do you mean by orthogonality? In the mathematical sense,
> > orthogonality implies that a function can't be expressed in terms of
> > the existing (basis) functions. Clearly, as you and Bernd show, the
> > CEILING function is not orthogonal, since it can be defined with
> > FNEGATE and FLOOR.
>
> Perhaps that was the wrong word to use: ALGOL 68 used it in the sense
> that every language feature should, where possible, work with every
> other. But let's not focus on the word.
>
> > I agree that expanding a language spec must be done judiciously,
> > and we should avoid the temptation to throw everything into the
> > spec.  However, a lean language can be orthogonal to a usable
> > language (orthogonal used in a geometric sense). When a user has to
> > implement even basic arithmetic functions in source, that's not
> > particularly useful.
>
> True, but CEILING is so unusual that usually they won't.
>
> > Given a choice of usability (richness of available words) over lean,
> > I'd pick usability --- the need for very lean systems has largely
> > disappeared in the desktop world.
>
> Oh for God's sake, this is Forth!  What is Forth, if not the leanest
> cleanest practical programming language and environment?  You don't
> just put stuff in for the sake of symmetry; every word must prove its
> worth.  This is the defining design principle of Forth, as everyone
> who has read _The Evolution Of Forth_ knows.
>

Can't say I've read it. I believe we will disagree, if not on what
Forth is, at least on what Forth should be.

> But maybe CEILING really is useful.  If so, I'm sure you can tell us
> how useful it is.
>

No, I'm not going to go to the trouble of looking through my code at
the moment. But we can take a pretty obvious example which is quite
common. Let's say we want to discretize the range of a value, e.g. the
interval [xmin, xmax), by an amount delta. Here xmin, xmax, and delta
are floating point values. In order to allocate an array for the
discrete values of x in this interval, we might do something like,

xmax f@ xmin f@ f- delta f@ f/ fceil f>d d>s


Krishna

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

#11341 — Re: RfD: S>F and F>S First Revision

Krishna Myneni <krishna.myneni@ccreweb.org> writes:
> discrete values of x in this interval, we might do something like,
> xmax f@ xmin f@ f- delta f@ f/ fceil f>d d>s

What if the quotient is 3.0000000001?  I think you want something more
like:

   xmax f@ xmin f@ f- delta f@ f/ 1e-5 f+ floor f>d d>s

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

#11343 — Re: RfD: S>F and F>S First Revision

On Apr 15, 9:23 pm, Paul Rubin <no.em...@nospam.invalid> wrote:
> Krishna Myneni <krishna.myn...@ccreweb.org> writes:
> > discrete values of x in this interval, we might do something like,
> > xmax f@ xmin f@ f- delta f@ f/ fceil f>d d>s
>
> What if the quotient is 3.0000000001?  I think you want something more
> like:
>
>    xmax f@ xmin f@ f- delta f@ f/ 1e-5 f+ floor f>d d>s

I should have been more clear about my requirements, and my notation
for the interval should have been [xmin, xmax]. I want the discretized
set of x values to bound xmax. So, even in the case the quotient is
3.000...1, the number of discretized values should be 4. This permits,
for example, the value of any function calculated at the x-values to
be interpolated at xmax.

Krishna

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

#11345 — Re: RfD: S>F and F>S First Revision

On Apr 15, 9:23 pm, Paul Rubin <no.em...@nospam.invalid> wrote:
> Krishna Myneni <krishna.myn...@ccreweb.org> writes:
> > discrete values of x in this interval, we might do something like,
> > xmax f@ xmin f@ f- delta f@ f/ fceil f>d d>s
>
> What if the quotient is 3.0000000001?  I think you want something more
> like:
>
>    xmax f@ xmin f@ f- delta f@ f/ 1e-5 f+ floor f>d d>s

Btw, I'm not sure what you're aiming at. Do you want the result to be
3 or 4? Your example will give 3, and the "1e-5 f+" doesn't accomplish
anything.

Krishna

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

#11346 — Re: RfD: S>F and F>S First Revision

Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>>    xmax f@ xmin f@ f- delta f@ f/ 1e-5 f+ floor f>d d>s
> Btw, I'm not sure what you're aiming at. Do you want the result to be
> 3 or 4? Your example will give 3, and the "1e-5 f+" doesn't accomplish
> anything.

I misunderstood what you were trying to do.  I thought xmax-xmin was
supposed to be an exact multiple of delta (say 3) and that you were
using ceiling to deal with roundoff error making the quotient 2.999999,
by rounding it up to 3.  Your requirement turns out to be different
though roundoff errors are still possible.

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

#11350 — Re: RfD: S>F and F>S First Revision

: fceil floor 1.0 f+ ; // ?

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

#11351 — Re: RfD: S>F and F>S First Revision

jacko <jackokring@gmail.com> wrote:
> : fceil floor 1.0 f+ ; // ?

Not quite.  It's more like

: fceil 1.0e0 fpred f+ floor ;

where FPRED is the IEEE-754 predecessor.  Even then, I think you'd
have to be very careful with rounding and overflow conditions.  The
other technique, FNEGATE FLOOR FNEGATE , cannot round or overflow.

Andrew.

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

#11352 — Re: RfD: S>F and F>S First Revision

jacko <jackokring@gmail.com> writes:
>: fceil floor 1.0 f+ ; // ?

Let's see:

: fceil floor 1e f+ ;  ok
0e fceil f. 1.  ok

Bzzt, wrong.

- 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 2011: http://www.euroforth.org/ef11/

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

#11270 — Re: RfD: S>F and F>S First Revision

In article <8ec72b2c-780b-48ae-96b4-8fa9726a7df6@9g2000yqp.googlegroups.com>,
Krishna Myneni  <krishna.myneni@ccreweb.org> wrote:
>On Apr 10, 3:02=A0pm, C G Montgomery <c...@physics.utoledo.edu> wrote:
>> RfD: =A0S>F and F>S
>> version 1.1 =A0First Revision =A009 April 2012
>> Charles G. Montgomery <c...@physics.utoledo.edu>
>>
>...
>> A)
>> F>S =A0 =A0 "f-to-s" =A0 =A0 =A0 =A0( -- 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.
>>
>> 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. =A0It 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. =A0Of course it's an
>> "as if" specification. =A0The value n is what would result from
>> executing F>D D>S , although it need not be obtained that way.
>>
>> B)
>> F>S =A0 =A0 "f-to-s" =A0 =A0 =A0 =A0( -- n ) ( F: r -- ) or ( r -- n )
>> n is one of the single-cell values that corresponds to the floating-
>> point value r. =A0If 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. =A0A 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 .) ...
>
>This is a particularly *bad* idea, IMO. The specification of F>S, as
>with the existing spec. for F>D, should specify the type of rounding.
>Leaving this specification open will almost certainly lead to non-
>portability of code and vicious bugs. This is why I believe the
>primitives, FROUND>S, FTRUNC>S, and maybe FCEIL>S are more important
>to standardize.

I agree with you, but I  dislike these names, because they suggest that
the result is F. Further >S suggest that it is a conversion while it is
a calculation (!).  The combination is bud-ugly.

    F>S-ROUND
    F>S-TRUNC
    F>S-CEIL
would be slightly better, but I want just
    ROUND
    TRUNC
    CEIL

>
>Krishna

Groetjes Albert

--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web