Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #57543 > unrolled thread
| Started by | krishna.myneni@ccreweb.org |
|---|---|
| First post | 2017-04-18 04:49 -0700 |
| Last post | 2017-04-26 01:55 -0700 |
| Articles | 20 on this page of 78 — 16 participants |
Back to article view | Back to comp.lang.forth
real to rational number krishna.myneni@ccreweb.org - 2017-04-18 04:49 -0700
Re: real to rational number lehs <skydda.barnen@gmail.com> - 2017-04-18 06:48 -0700
Re: real to rational number krishna.myneni@ccreweb.org - 2017-04-18 19:09 -0700
Re: real to rational number lehs <skydda.barnen@gmail.com> - 2017-04-18 22:53 -0700
Re: real to rational number krishna.myneni@ccreweb.org - 2017-04-19 04:43 -0700
Re: real to rational number rickman <gnuarm@gmail.com> - 2017-04-19 15:41 -0400
Re: real to rational number Paul Rubin <no.email@nospam.invalid> - 2017-04-19 13:03 -0700
Re: real to rational number "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-20 17:26 +0000
Re: real to rational number hughaguilar96@gmail.com - 2017-04-20 14:29 -0700
Re: real to rational number "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-19 23:44 +0000
Re: real to rational number Paul Rubin <no.email@nospam.invalid> - 2017-04-19 19:30 -0700
Re: real to rational number "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-20 17:08 +0000
Re: real to rational number Paul Rubin <no.email@nospam.invalid> - 2017-04-20 11:46 -0700
Re: real to rational number "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-21 09:47 +0000
Re: real to rational number lehs <skydda.barnen@gmail.com> - 2017-04-20 20:49 -0700
Re: real to rational number rickman <gnuarm@gmail.com> - 2017-04-19 15:36 -0400
Re: real to rational number krishna.myneni@ccreweb.org - 2017-04-20 18:44 -0700
Re: real to rational number hughaguilar96@gmail.com - 2017-04-18 07:06 -0700
Re: real to rational number krishna.myneni@ccreweb.org - 2017-04-18 19:17 -0700
Re: real to rational number Paul Rubin <no.email@nospam.invalid> - 2017-04-18 19:45 -0700
Re: real to rational number krishna.myneni@ccreweb.org - 2017-04-18 19:57 -0700
Re: real to rational number anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-19 05:35 +0000
Re: real to rational number hughaguilar96@gmail.com - 2017-04-18 23:42 -0700
Re: real to rational number krishna.myneni@ccreweb.org - 2017-04-19 04:53 -0700
Re: real to rational number hughaguilar96@gmail.com - 2017-04-19 11:32 -0700
Re: real to rational number minforth@arcor.de - 2017-04-18 08:23 -0700
Re: real to rational number krishna.myneni@ccreweb.org - 2017-04-18 19:24 -0700
Re: real to rational number Paul Rubin <no.email@nospam.invalid> - 2017-04-18 19:48 -0700
Re: real to rational number krishna.myneni@ccreweb.org - 2017-04-18 20:01 -0700
Re: real to rational number Paul Rubin <no.email@nospam.invalid> - 2017-04-18 19:39 -0700
Re: real to rational number krishna.myneni@ccreweb.org - 2017-04-18 19:56 -0700
Re: real to rational number Paul Rubin <no.email@nospam.invalid> - 2017-04-19 00:41 -0700
Re: real to rational number krishna.myneni@ccreweb.org - 2017-04-19 04:48 -0700
Re: real to rational number hughaguilar96@gmail.com - 2017-04-19 11:30 -0700
Re: real to rational number albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-20 20:15 +0200
Re: real to rational number krishna.myneni@ccreweb.org - 2017-04-20 15:23 -0700
Re: real to rational number Paul Rubin <no.email@nospam.invalid> - 2017-04-20 18:52 -0700
Re: real to rational number Pablo Hugo Reda <pabloreda@gmail.com> - 2017-04-18 19:58 -0700
Re: real to rational number krishna.myneni@ccreweb.org - 2017-04-18 20:05 -0700
Re: real to rational number Pablo Hugo Reda <pabloreda@gmail.com> - 2017-04-19 05:30 -0700
Re: real to rational number Pablo Hugo Reda <pabloreda@gmail.com> - 2017-04-19 05:35 -0700
Re: real to rational number Pablo Hugo Reda <pabloreda@gmail.com> - 2017-04-19 05:41 -0700
Re: real to rational number krishna.myneni@ccreweb.org - 2017-04-19 19:39 -0700
Re: real to rational number "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-19 23:16 +0000
Re: real to rational number krishna.myneni@ccreweb.org - 2017-04-19 19:42 -0700
Re: real to rational number "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-20 17:15 +0000
Re: real to rational number krishna.myneni@ccreweb.org - 2017-04-20 15:11 -0700
Re: real to rational number hughaguilar96@gmail.com - 2017-04-20 15:49 -0700
Re: real to rational number Alex <alex@rivadpm.com> - 2017-04-21 00:20 +0100
Re: real to rational number krishna.myneni@ccreweb.org - 2017-04-20 18:49 -0700
Re: real to rational number The Beez <the.beez.speaks@gmail.com> - 2017-04-21 03:18 -0700
Re: real to rational number krishna.myneni@ccreweb.org - 2017-04-21 18:39 -0700
Re: real to rational number krishna.myneni@ccreweb.org - 2017-04-21 18:46 -0700
Re: real to rational number Paul Rubin <no.email@nospam.invalid> - 2017-04-21 21:55 -0700
Re: real to rational number krishna.myneni@ccreweb.org - 2017-04-22 08:33 -0700
Re: real to rational number Paul Rubin <no.email@nospam.invalid> - 2017-04-22 13:35 -0700
Re: real to rational number The Beez <the.beez.speaks@gmail.com> - 2017-04-24 00:58 -0700
Re: real to rational number minforth@arcor.de - 2017-04-24 01:08 -0700
Re: real to rational number minforth@arcor.de - 2017-04-23 02:28 -0700
Re: real to rational number hughaguilar96@gmail.com - 2017-04-21 18:43 -0700
rationalising reality, was Re: real to rational number Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2017-04-22 10:28 +0100
Re: rationalising reality, was Re: real to rational number Mark Wills <markwills1970@gmail.com> - 2017-04-22 02:33 -0700
Re: real to rational number krishna.myneni@ccreweb.org - 2017-04-20 16:22 -0700
Re: real to rational number hughaguilar96@gmail.com - 2017-04-20 22:02 -0700
Re: real to rational number Julian Fondren <julian.fondren@gmail.com> - 2017-04-21 00:12 -0700
Re: real to rational number "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-21 09:55 +0000
Re: real to rational number hughaguilar96@gmail.com - 2017-04-25 10:52 -0700
Re: real to rational number "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-29 03:16 +0000
Re: real to rational number "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-21 09:52 +0000
Re: real to rational number lehs <skydda.barnen@gmail.com> - 2017-04-21 05:35 -0700
Re: real to rational number hughaguilar96@gmail.com - 2017-04-21 19:05 -0700
Re: real to rational number The Beez <the.beez.speaks@gmail.com> - 2017-04-24 01:14 -0700
Re: real to rational number Cecil Bayona <cbayona@cbayona.com> - 2017-04-24 11:31 -0500
Re: real to rational number The Beez <the.beez.speaks@gmail.com> - 2017-04-25 00:52 -0700
Re: real to rational number hughaguilar96@gmail.com - 2017-04-24 11:43 -0700
Re: real to rational number The Beez <the.beez.speaks@gmail.com> - 2017-04-25 00:35 -0700
Re: real to rational number The Beez <the.beez.speaks@gmail.com> - 2017-04-25 01:09 -0700
Re: real to rational number minforth@arcor.de - 2017-04-26 01:55 -0700
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
| From | Pablo Hugo Reda <pabloreda@gmail.com> |
|---|---|
| Date | 2017-04-19 05:35 -0700 |
| Message-ID | <737e1f6d-5288-40bb-b07e-e959bdbdcdcf@googlegroups.com> |
| In reply to | #57596 |
El miércoles, 19 de abril de 2017, 9:30:24 (UTC-3), Pablo Hugo Reda escribió: > El miércoles, 19 de abril de 2017, 0:05:41 (UTC-3), krishna...@ccreweb.org escribió: > > On Tuesday, April 18, 2017 at 9:58:24 PM UTC-5, Pablo Hugo Reda wrote: > > ... > > > I convert from fixed point 16.16 to fraction for a calculator > > > > > > the complete lib in > > > https://github.com/phreda4/reda4/blob/master/r4/Lib/frac.txt > > > > > > the lib has 50 lines, make a fraction of decimal part symplify and sum de integer par, I guess. > > > > > > > > > > > > ::gcd | n1 n2 -- gcd > > > ( 1? )( swap over mod ) drop ; > > > > > > ::fsimp | n1 n2 -- n1 n2 > > > 2dup gcd 0? ( drop ; ) > > > >r r / swap r> / swap > > > -? ( swap neg swap neg ) ; > > > > > > ::fix2f | fix -- n1 d1 > > > dup 16 >> swap $10000 fsimp rot over * rot + swap ; > > > > Hi Pablo, > > > > Can you give me an example of using this to solve the originally stated problem? > > > > Krishna > > Krishna > > I found a bug!,not work for number with not zero integer part, the code for test is > > :main > show clrscr > > 0.6190 | 7.619 not work > dup "%f " print | print fixpoint > fix2f 2dup | convert to fraction > swap "%d/%d" print | print in fraction > 16 <</ " %f" print | back to fixed point > > 'exit >esc< > cminiflecha ; > > I don't remenber how code this. > for 0.619 work ok but for 7.619 give me 14.619, the integer part is doubled! > sorry. well try this and work: ::fix2f | fix -- n1 d1 dup 16 >> swap $ffff and $10000 fsimp rot over * rot + swap ; clear the fractional part for make the fraction.. remenber my fixed point number are 16.16, not great precision.
[toc] | [prev] | [next] | [standalone]
| From | Pablo Hugo Reda <pabloreda@gmail.com> |
|---|---|
| Date | 2017-04-19 05:41 -0700 |
| Message-ID | <33a396b9-fe68-44ab-b67c-158024423a51@googlegroups.com> |
| In reply to | #57597 |
El miércoles, 19 de abril de 2017, 9:35:26 (UTC-3), Pablo Hugo Reda escribió:
> El miércoles, 19 de abril de 2017, 9:30:24 (UTC-3), Pablo Hugo Reda escribió:
> > El miércoles, 19 de abril de 2017, 0:05:41 (UTC-3), krishna...@ccreweb.org escribió:
> > > On Tuesday, April 18, 2017 at 9:58:24 PM UTC-5, Pablo Hugo Reda wrote:
> > > ...
> > > > I convert from fixed point 16.16 to fraction for a calculator
> > > >
> > > > the complete lib in
> > > > https://github.com/phreda4/reda4/blob/master/r4/Lib/frac.txt
> > > >
> > > > the lib has 50 lines, make a fraction of decimal part symplify and sum de integer par, I guess.
> > > >
> > > >
> > > >
> > > > ::gcd | n1 n2 -- gcd
> > > > ( 1? )( swap over mod ) drop ;
> > > >
> > > > ::fsimp | n1 n2 -- n1 n2
> > > > 2dup gcd 0? ( drop ; )
> > > > >r r / swap r> / swap
> > > > -? ( swap neg swap neg ) ;
> > > >
> > > > ::fix2f | fix -- n1 d1
> > > > dup 16 >> swap $10000 fsimp rot over * rot + swap ;
> > >
> > > Hi Pablo,
> > >
> > > Can you give me an example of using this to solve the originally stated problem?
> > >
> > > Krishna
> >
> > Krishna
> >
> > I found a bug!,not work for number with not zero integer part, the code for test is
> >
> > :main
> > show clrscr
> >
> > 0.6190 | 7.619 not work
> > dup "%f " print | print fixpoint
> > fix2f 2dup | convert to fraction
> > swap "%d/%d" print | print in fraction
> > 16 <</ " %f" print | back to fixed point
> >
> > 'exit >esc<
> > cminiflecha ;
> >
> > I don't remenber how code this.
> > for 0.619 work ok but for 7.619 give me 14.619, the integer part is doubled!
> > sorry.
>
> well try this and work:
>
> ::fix2f | fix -- n1 d1
> dup 16 >> swap $ffff and $10000 fsimp rot over * rot + swap ;
>
> clear the fractional part for make the fraction..
> remenber my fixed point number are 16.16, not great precision.
0.0761
dup "%f " print
fix2f 2dup
swap "%d/%d" print
16 <</ " %f" print
give me
0.0760 4987/65536 0.0760
[toc] | [prev] | [next] | [standalone]
| From | krishna.myneni@ccreweb.org |
|---|---|
| Date | 2017-04-19 19:39 -0700 |
| Message-ID | <044998db-6fae-4a79-9904-1e5e3c95aa51@googlegroups.com> |
| In reply to | #57598 |
On Wednesday, April 19, 2017 at 7:41:56 AM UTC-5, Pablo Hugo Reda wrote: ... > > well try this and work: > > > > ::fix2f | fix -- n1 d1 > > dup 16 >> swap $ffff and $10000 fsimp rot over * rot + swap ; > > > > clear the fractional part for make the fraction.. > > remenber my fixed point number are 16.16, not great precision. > > 0.0761 > dup "%f " print > fix2f 2dup > swap "%d/%d" print > 16 <</ " %f" print > > give me > 0.0760 4987/65536 0.0760 I'm not sure I understand how this works; will have to study it. Thanks. Krishna
[toc] | [prev] | [next] | [standalone]
| From | "Rudy Velthuis" <newsgroups@rvelthuis.de> |
|---|---|
| Date | 2017-04-19 23:16 +0000 |
| Message-ID | <xn0koxwci84sk9g004@nntp.aioe.org> |
| In reply to | #57543 |
krishna.myneni@ccreweb.org wrote: > Rosetta Code has a number of entries for code to converting a > (computer representation) of a real number into a rational number, or > to the nearest expressible fraction, a/b, where both a and b are > integers. There is even a Forth entry! What a coincidence! I just looked at that page only a few days ago, looking for optimized versions of my code to convert BigDecimals to BigRationals (not in Forth, though, in Delphi). -- Rudy Velthuis http://www.rvelthuis.de "He who hesitates is a damned fool." -- Mae West (1892-1980)
[toc] | [prev] | [next] | [standalone]
| From | krishna.myneni@ccreweb.org |
|---|---|
| Date | 2017-04-19 19:42 -0700 |
| Message-ID | <acd98288-1c49-4250-8af0-c3ef690e6ad2@googlegroups.com> |
| In reply to | #57611 |
On Wednesday, April 19, 2017 at 6:16:06 PM UTC-5, Rudy Velthuis wrote:
> krishna.myneni@ccreweb.org wrote:
>
> > Rosetta Code has a number of entries for code to converting a
> > (computer representation) of a real number into a rational number, or
> > to the nearest expressible fraction, a/b, where both a and b are
> > integers. There is even a Forth entry!
>
> What a coincidence! I just looked at that page only a few days ago,
> looking for optimized versions of my code to convert BigDecimals to
> BigRationals (not in Forth, though, in Delphi).
>...
The Forth version at Rosetta Code is not my style, and, I think, perhaps a poor representative for Forth 2011. The use of locals is overdone, perhaps to make programmers from other languages feel more comfortable. Anyway, below is my Forth-94 (aka ANS Forth) version.
Krishna
--
\ rational.4th
\
\ Brute force search, optimized to search only
\ within integer bounds surrounding target.
\
\ Requires:
\ ans-words.4th ( for kForth )
\
\ From Rosetta code:
\ https://rosettacode.org/wiki/Convert_decimal_number_to_rational#Forth
\
\ Examples:
\
\ 1.618033988e 100 RealToRational swap . . 144 89
\ 3.14159e 1000 RealToRational swap . . 355 113
\ 2.71828e 1000 RealToRational swap . . 1264 465
\ 0.9054054e 100 RealToRational swap . . 67 74
fvariable besterror
0 value numtor
0 value denom
0 value realscale
false value neg?
[undefined] ftrunc>s [IF]
: ftrunc>s ( r -- s ) ftrunc f>d d>s ;
[THEN]
: RationalError ( |r| num den -- rerror ) >r s>f r> s>f f/ f- fabs ;
: RealToRational ( r den_limit -- numerator denominator )
0 to numtor 1 to denom
9999999e besterror f! \ very large error that will surely
\ be improved upon
>r \ r --
fdup f0< to neg? \ save sign for later
fabs
\ realscale helps set integer bounds around target
fdup ftrunc>s 1+ to realscale
\ search through possible denominators ( 1 to denlimit)
r> 1+ 1 ?DO
\ |r| --
\ search through numerator within integer limits bounding
\ the real, e.g. for 3.1419e search only between 3 and 4
I realscale * I realscale 1- * ?DO
fdup I J RationalError
fdup besterror f@ f< IF
besterror f!
I to numtor J to denom
ELSE fdrop
THEN
LOOP
LOOP
fdrop
numtor neg? IF negate THEN denom
;
[toc] | [prev] | [next] | [standalone]
| From | "Rudy Velthuis" <newsgroups@rvelthuis.de> |
|---|---|
| Date | 2017-04-20 17:15 +0000 |
| Message-ID | <xn0koyorm8h4orx003@nntp.aioe.org> |
| In reply to | #57627 |
krishna.myneni@ccreweb.org wrote: > The Forth version at Rosetta Code is not my style, and, I think, > perhaps a poor representative for Forth 2011. The use of locals is > overdone, perhaps to make programmers from other languages feel more > comfortable. Anyway, below is my Forth-94 (aka ANS Forth) version. <snip> > fvariable besterror > 0 value numtor > 0 value denom > 0 value realscale > false value neg? You say the use of locals in the Rosetta version is overdone but you don't mind using global variables/values instead? -- Rudy Velthuis http://www.rvelthuis.de "I've just learned about his illness. Let's hope it's nothing trivial." -- Irvin S. Cobb
[toc] | [prev] | [next] | [standalone]
| From | krishna.myneni@ccreweb.org |
|---|---|
| Date | 2017-04-20 15:11 -0700 |
| Message-ID | <69b22acc-b15b-47d4-96d6-0690edc03089@googlegroups.com> |
| In reply to | #57647 |
On Thursday, April 20, 2017 at 12:15:06 PM UTC-5, Rudy Velthuis wrote: > krishna.myneni@ccreweb.org wrote: > ... > > > fvariable besterror > > 0 value numtor > > 0 value denom > > 0 value realscale > > false value neg? > > You say the use of locals in the Rosetta version is overdone but you > don't mind using global variables/values instead? > .. Nope, I don't mind, as long as I have no concerns about re-entrancy or name masking. This is Forth and I can redefine those "globals" without affecting the code which relies on them. But, I don't want to divert the present thread into a debate on the merits of locals versus "globals" versus use of the stack -- that has been debated numerous times over the years in c.l.f. I'm not opposed to using locals in moderation, and, in fact, I think several of the quantities such as the numerator and denominator are best kept as locals in this code. However, assigning a local to the real number argument leads to a lot of unneeded visual clutter. Krishna
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-04-20 15:49 -0700 |
| Message-ID | <453ddeb9-b675-4b1c-b0a1-35270421ba4a@googlegroups.com> |
| In reply to | #57671 |
On Thursday, April 20, 2017 at 3:11:16 PM UTC-7, krishna...@ccreweb.org wrote: > I think several of the quantities such as the numerator and denominator are best kept as locals in this code. However, assigning a local to the real number argument leads to a lot of unneeded visual clutter. One of the many blunders of ANS-Forth was to make locals with with TO --- it would have been much better to make the local provide an address and then use @ and ! on that address --- if the local is big enough to contain a double or a float, then D@ and D! as well as F@ and F! can also be used on the local's address. Elizabeth Rather says: ---------------------------------------------------------------- I hate locals :-) ---------------------------------------------------------------- Could this be why locals were completely f'ed up in ANS-Forth? What I described above, with the local providing an address and being big enough to hold any primitive data-type, is obvious. Only a low-grade moron would use TO and consequently limit locals to only single-cell values. Also, Elizabeth Rather got the parameters for LOCALS| backwards, which also indicates the intelligence level of a low-grade moron. Elizabeth Rather should be kicked out of the Forth community. Being a low-grade moron would be okay if she were willing to learn, but claiming to be the "leading expert" of the Forth community implies that she is unwilling to learn --- so, she has to go! --- there is no other way for Forth to ever be taken seriously in the real world.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-04-21 00:20 +0100 |
| Message-ID | <odbfhv$fj7$1@dont-email.me> |
| In reply to | #57673 |
On 4/20/2017 23:49, hughaguilar96@gmail.com wrote: > On Thursday, April 20, 2017 at 3:11:16 PM UTC-7, > krishna...@ccreweb.org wrote: >> I think several of the quantities such as the numerator and >> denominator are best kept as locals in this code. However, >> assigning a local to the real number argument leads to a lot of >> unneeded visual clutter. > > One of the many blunders of ANS-Forth was to make locals with with TO > --- it would have been much better to make the local provide an > address and then use @ and ! on that address --- if the local is big > enough to contain a double or a float, then D@ and D! as well as F@ > and F! can also be used on the local's address. (direct quote) Gforth currently supports cells (W:, W^), doubles (D:, D^), floats (F:, F^) and characters (C:, C^) in two flavours: a value-flavoured local (defined with W:, D: etc.) produces its value and can be changed with TO. A variable-flavoured local (defined with W^ etc.) produces its address (which becomes invalid when the variable's scope is left). https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Gforth-locals.html You could write up an RfD to get this in the standard. Could, but won't. > > Elizabeth Rather says: > ---------------------------------------------------------------- I > hate locals :-) > ---------------------------------------------------------------- > As do I. I just put my Forth up on github, and you'll find very little use of locals. They're largely a distraction with a limited number of use cases. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | krishna.myneni@ccreweb.org |
|---|---|
| Date | 2017-04-20 18:49 -0700 |
| Message-ID | <23b48329-e07a-4947-9dc9-82e2333f7fab@googlegroups.com> |
| In reply to | #57674 |
On Thursday, April 20, 2017 at 6:20:29 PM UTC-5, Alex wrote: > ... I just put my Forth up on github, and you'll find very little > use of locals. They're largely a distraction with a limited number of > use cases. > I've not implemented locals in kForth, nor do I feel any compulsion to do so. Krishna
[toc] | [prev] | [next] | [standalone]
| From | The Beez <the.beez.speaks@gmail.com> |
|---|---|
| Date | 2017-04-21 03:18 -0700 |
| Message-ID | <c094a6f0-88d7-4a4e-bb15-8f90fc7bb4ba@googlegroups.com> |
| In reply to | #57678 |
On Friday, April 21, 2017 at 3:49:51 AM UTC+2, krishna...@ccreweb.org wrote: > I've not implemented locals in kForth, nor do I feel any compulsion to do so. > > Krishna I feel with you. I have a kind of crude "bolt-on" libraries for 4tH, which I mainly (exclusively?) use for porting purposes. Sure, I could do locals in native 4tH, but then I'd increase the function call overhead for everything and everyone - turning it into some kind of C. I learned from the old FIG editor that one could use R@ as some kind of local constant - and that helped me a lot through the years. When 3.63.0 comes out I will increase that to the first three items on the return stack, r@, r'@ and r"@. That will IMHO even lessen the need for locals since you can park loop limits, pointers and other constants there, freeing up space on the data stack. Note the added advantage is that they are "random access" - no stack juggling. Sure, you can do that in 4tH right now, but either "illegally" or with some serious overhead. Hans Bezemer
[toc] | [prev] | [next] | [standalone]
| From | krishna.myneni@ccreweb.org |
|---|---|
| Date | 2017-04-21 18:39 -0700 |
| Message-ID | <4a10f5fc-1b15-40e8-ac90-59002d014239@googlegroups.com> |
| In reply to | #57711 |
On Friday, April 21, 2017 at 5:18:34 AM UTC-5, The Beez wrote:
> On Friday, April 21, 2017 at 3:49:51 AM UTC+2, krishna...@ccreweb.org wrote:
> > I've not implemented locals in kForth, nor do I feel any compulsion to do so.
> >
> > Krishna
>
> I feel with you. I have a kind of crude "bolt-on" libraries for 4tH, which I mainly (exclusively?) use for porting purposes. Sure, I could do locals in native 4tH, but then I'd increase the function call overhead for everything and everyone - turning it into some kind of C.
>
Yes, while I appreciate the language, "C", I have no desire to use Forth as a reverse notation, syntax-free, C-like language. I'm glad that someone went to the trouble of putting in a Forth entry into Rosetta code for the rational approximation problem. However, I am critical (in the positive sense of the word) of the use of locals in this example. Take, for example, the following code:
...
thereal F- FABS to temperror
temperror besterror F< IF
temperror to besterror I to numtor J to denom
THEN
...
The local, "temperror", is frivolous, because it is used nowhere else in the code and the fp value is available on the stack, to be used as follows
...
thereal F- FABS
FDUP besterror F< IF besterror F! ... ELSE FDROP THEN
...
Similarly, with the local, "thereal". It's simple enough without obfuscating the code to leave it on the stack. Anyway, I didn't want to make this a thread about the dangers of locals, but I guess I started it.
> I learned from the old FIG editor that one could use R@ as some kind of local constant - and that helped me a lot through the years. When 3.63.0 comes out I will increase that to the first three items on the return stack, r@, r'@ and r"@. That will IMHO even lessen the need for locals since you can park loop limits, pointers and other constants there, freeing up space on the data stack.
>
> Note the added advantage is that they are "random access" - no stack juggling.
True, but you've got to be careful to pop them, and especially be careful inside a loop.
Krishna
[toc] | [prev] | [next] | [standalone]
| From | krishna.myneni@ccreweb.org |
|---|---|
| Date | 2017-04-21 18:46 -0700 |
| Message-ID | <c22d4527-816b-432e-a82f-237a7ce1c58a@googlegroups.com> |
| In reply to | #57761 |
On Friday, April 21, 2017 at 8:39:48 PM UTC-5, krishna...@ccreweb.org wrote:
...
> thereal F- FABS
> FDUP besterror F< IF besterror F! ... ELSE FDROP
...
Oops. That should have been,
...
thereal F- FABS
FDUP besterror F@ F< IF besterror F! ... ELSE FDROP THEN
...
The local "besterror" should have been an fvariable, in case we needed to do a post-mortem on it.
Krishna
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-04-21 21:55 -0700 |
| Message-ID | <87efwl11nl.fsf@nightsong.com> |
| In reply to | #57761 |
>> increase that to the first three items on the return stack, r@, r'@ >> and r"@. ... > True, but you've got to be careful to pop them, and especially be > careful inside a loop. Is this really much different from using PICK on the data stack? Also it seems like just a small step from that to having a frame pointer that you can index from, that gets set to the top of the return stack (TOR) when entering a word, and then TOR is set to it on returning.
[toc] | [prev] | [next] | [standalone]
| From | krishna.myneni@ccreweb.org |
|---|---|
| Date | 2017-04-22 08:33 -0700 |
| Message-ID | <3ceeeb6c-cad5-4315-af0c-414f1718ece0@googlegroups.com> |
| In reply to | #57777 |
On Friday, April 21, 2017 at 11:56:01 PM UTC-5, Paul Rubin wrote: > >> increase that to the first three items on the return stack, r@, r'@ > >> and r"@. ... > > True, but you've got to be careful to pop them, and especially be > > careful inside a loop. > > Is this really much different from using PICK on the data stack? > RPICK ? That doesn't look right. KM
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-04-22 13:35 -0700 |
| Message-ID | <87wpacyydb.fsf@nightsong.com> |
| In reply to | #57823 |
krishna.myneni@ccreweb.org writes: >> Is this really much different from using PICK on the data stack? > RPICK ? That doesn't look right. RPICK exists in many implementations but I meant regular PICK.
[toc] | [prev] | [next] | [standalone]
| From | The Beez <the.beez.speaks@gmail.com> |
|---|---|
| Date | 2017-04-24 00:58 -0700 |
| Message-ID | <190549d0-45d5-4f1b-96ef-34d2acb08711@googlegroups.com> |
| In reply to | #57761 |
On Saturday, April 22, 2017 at 3:39:48 AM UTC+2, krishna...@ccreweb.org wrote: > Yes, while I appreciate the language, "C", I have no desire to use Forth as a reverse notation, syntax-free, C-like language. Likewise ;-) 4tH is written in C. A few years ago I had to add a "gcc" like executable and I was surprised how little fun that was. Adding a few snippets to enhance an existing program isn't too "disturbing", however writing an entire program is nowadays. > I'm glad that someone went to the trouble of putting in a Forth entry into Rosetta code for the rational approximation problem. However, I am critical (in the positive sense of the word) of the use of locals in this example. Take, for example, the following code <snip> That's exactly the point: locals invite easy solutions that aren't very "Forth-like" anymore. I've added a lot of "local free" code to Rosetta. > > Note the added advantage is that they are "random access" - no stack juggling. > True, but you've got to be careful to pop them, and especially be careful inside a loop. I wouldn't do it in a DO..LOOP for obvious reasons, however BEGIN..REPEAT is pretty painless as long as you put stuff up there which value doesn't change during execution, e.g. array offsets, loop limits, etc. Note the entire advantage disappears when you have to update a three-item deep return stack item. And at the end of the loop you simple move 'em off and drop 'em. Hans Bezemer
[toc] | [prev] | [next] | [standalone]
| From | minforth@arcor.de |
|---|---|
| Date | 2017-04-24 01:08 -0700 |
| Message-ID | <70cf1998-9ce9-4163-92a7-a70cf4608e30@googlegroups.com> |
| In reply to | #57974 |
Am Montag, 24. April 2017 09:58:33 UTC+2 schrieb The Beez: > On Saturday, April 22, 2017 at 3:39:48 AM UTC+2, krishna...@ccreweb.org wrote: > > Yes, while I appreciate the language, "C", I have no desire to use Forth as a reverse notation, syntax-free, C-like language. > > Likewise ;-) 4tH is written in C. A few years ago I had to add a "gcc" like executable and I was surprised how little fun that was. Adding a few snippets to enhance an existing program isn't too "disturbing", however writing an entire program is nowadays. > > > I'm glad that someone went to the trouble of putting in a Forth entry into Rosetta code for the rational approximation problem. However, I am critical (in the positive sense of the word) of the use of locals in this example. Take, for example, the following code <snip> > > That's exactly the point: locals invite easy solutions that aren't very "Forth-like" anymore. I've added a lot of "local free" code to Rosetta. > > > > Note the added advantage is that they are "random access" - no stack juggling. > > True, but you've got to be careful to pop them, and especially be careful inside a loop. > > I wouldn't do it in a DO..LOOP for obvious reasons, however BEGIN..REPEAT is pretty painless as long as you put stuff up there which value doesn't change during execution, e.g. array offsets, loop limits, etc. Note the entire advantage disappears when you have to update a three-item deep return stack item. And at the end of the loop you simple move 'em off and drop 'em. > > Hans Bezemer Yes, counted loops are slower because they are counting. ;-) But honestly, I have not encountered big delays so far. But perhaps it is because I do address the return stack like any other array in memory. Since my locals live also in the return stack, locals access time is pretty fast too.
[toc] | [prev] | [next] | [standalone]
| From | minforth@arcor.de |
|---|---|
| Date | 2017-04-23 02:28 -0700 |
| Message-ID | <6d146587-ff53-45f5-95c2-e4b683ae45e3@googlegroups.com> |
| In reply to | #57711 |
Am Freitag, 21. April 2017 12:18:34 UTC+2 schrieb The Beez: > I learned from the old FIG editor that one could use R@ as some kind of local constant - and that helped me a lot through the years. When 3.63.0 comes out I will increase that to the first three items on the return stack, r@, r'@ and r"@. Been there, done that, left, because it's ugly and still limited IMO. Because: When do programmers like locals? When they have _many_ parameters to a function, not just three. The more general solution is to introduce a stack frame for words with locals. At compile-time you can use colon-sys (modified by locals|) to signal to ; (semis) that it shall compile a frame-cleaning next/return instead of a normal one. Yes, stackframes smell of C, but it is a clean and simple way, not altoo difficult to implement, and with practically no runtime costs.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-04-21 18:43 -0700 |
| Message-ID | <977360a9-5caf-4da0-bab2-2092f159391d@googlegroups.com> |
| In reply to | #57678 |
On Thursday, April 20, 2017 at 6:49:51 PM UTC-7, krishna...@ccreweb.org wrote:
> On Thursday, April 20, 2017 at 6:20:29 PM UTC-5, Alex wrote:
> > ... I just put my Forth up on github, and you'll find very little
> > use of locals. They're largely a distraction with a limited number of
> > use cases.
> >
>
> I've not implemented locals in kForth, nor do I feel any compulsion to do so.
>
> Krishna
One of the many blunders of Elizabeth Rather is in section 3.2.3.2:
-------------------------------------------------------------------
The control-flow stack may, but need not, physically exist in an
implementation. If it does exist, it may be, but need not be, implemented
using the data stack. The format of the control-flow stack is
implementation defined. Since the control-flow stack may be implemented
using the data stack, items placed on the data stack are unavailable to a
program after items are placed on the control-flow stack and remain
unavailable until the control-flow stack items are removed.
-------------------------------------------------------------------
What happened here is that some of the ANS-Forth committee members wanted the control-flow stack to be distinct from the data-stack because this is obviously a good idea. Forth Inc. uses the data-stack for control-flow data however (Elizabeth Rather has described this as being "convenient"). So, the solution as always, was ambiguity. She just said that either behavior would be standard. As a practical matter, what this means is that Forth Inc.'s idiotic method becomes the standard. Everybody has to assume that the control-flow stack is the data-stack, because otherwise their code won't work under SwiftForth and they will get blamed for writing a non-standard program.
When meta-compiling, it is necessary to put your data somewhere. The obvious place would be the data-stack. This can't be done however, because the control-flow data (generated by IF BEGIN etc.) is on the data-stack getting in the way of you accessing your own data. So, you need to put your data somewhere else. The two choices are the return-stack and locals. The return-stack can be used (Bernd Paysan has posted code on comp.lang.forth that uses the return-stack), but this only works when you have very little data. Locals work a lot better.
Here is an example:
----------------------------------------------------------------------------
true value bounds-check?
\ Use TO to set BOUNDS-CHECK? to FALSE when you are ready for your production version.
: check1 ( x1 dim1 -- x1 ) over u> not abort" *** array index 1 out of bounds ***" ;
: check2 ( x2 dim2 -- x2 ) over u> not abort" *** array index 2 out of bounds ***" ;
: check3 ( x3 dim3 -- x3 ) over u> not abort" *** array index 3 out of bounds ***" ;
: check4 ( x4 dim4 -- x4 ) over u> not abort" *** array index 4 out of bounds ***" ;
: check5 ( x5 dim4 -- x5 ) over u> not abort" *** array index 5 out of bounds ***" ;
: check6 ( x6 dim4 -- x6 ) over u> not abort" *** array index 6 out of bounds ***" ;
: <check1> ( dim1 -- ) bounds-check? if lit, postpone check1 else drop then ;
: <check2> ( dim2 -- ) bounds-check? if lit, postpone check2 else drop then ;
: <check3> ( dim3 -- ) bounds-check? if lit, postpone check3 else drop then ;
: <check4> ( dim4 -- ) bounds-check? if lit, postpone check4 else drop then ;
: <check5> ( dim4 -- ) bounds-check? if lit, postpone check5 else drop then ;
: <check6> ( dim4 -- ) bounds-check? if lit, postpone check6 else drop then ;
: <3array> { dim1 dim2 dim3 siz1 name | adr siz siz2 siz3 -- } \ 3-dimensional array
dim1 siz1 * to siz2 dim2 siz2 * to siz3 dim3 siz3 * to siz
align here to adr siz allot
name get-current :name \ runtime: x1 x2 x3 -- element-adr
dim3 <check3>
siz3 lit*, swap, \ runtime: x1 x3*s3 x2
dim2 <check2>
siz2 lit*, +, swap, \ runtime: x3*s3+x2*s2 x1
dim1 <check1>
siz1 lit*, +, adr lit+, ;, \ runtime: x3*s3+x2*s2+x1*s1+adr
c" ^" name get-current :2name \ runtime: -- adr
adr lit, ;,
c" lim-" name get-current :2name \ runtime: -- adr-past
adr siz + lit, ;,
name c" -zero" get-current :2name \ runtime: --
adr lit, siz lit, s" erase ; " evaluate
name c" -size" get-current :2name \ runtime: -- siz1
siz1 lit, ;,
name c" -dim" get-current :2name \ runtime: -- dim1 dim2 dim3
dim1 lit, dim2 lit, dim3 lit, ;,
;
: 3array ( dim1 dim2 dim3 size -- ) bl word hstr dup >r <3array> r> dealloc ;
----------------------------------------------------------------------------
You said:
"I've not implemented locals in kForth, nor do I feel any compulsion to do so."
This tells me that you have never written any meta-compiling words. How else do you work around Elizabeth Rather's idiotic rule that control-flow data may be on the data-stack getting in your way?
[toc] | [prev] | [next] | [standalone]
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
Back to top | Article view | comp.lang.forth
csiph-web