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

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

How to solve this problem in FORTH?

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  How to solve this problem in FORTH? lehs <skydda.barnen@gmail.com> - 2015-10-26 00:02 -0700
    Re: How to solve this problem in FORTH? Paul Rubin <no.email@nospam.invalid> - 2015-10-26 00:58 -0700
      Re: How to solve this problem in FORTH? lehs <skydda.barnen@gmail.com> - 2015-10-26 02:36 -0700
        Re: How to solve this problem in FORTH? Paul Rubin <no.email@nospam.invalid> - 2015-10-26 21:56 -0700
      Re: How to solve this problem in FORTH? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-10-26 03:09 -0700
        Re: How to solve this problem in FORTH? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-10-26 03:14 -0700
          Re: How to solve this problem in FORTH? lehs <skydda.barnen@gmail.com> - 2015-10-26 04:55 -0700
            Re: How to solve this problem in FORTH? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-10-26 05:11 -0700
              Re: How to solve this problem in FORTH? humptydumpty <ouatubi@gmail.com> - 2015-10-26 06:35 -0700
                Re: How to solve this problem in FORTH? lehs <skydda.barnen@gmail.com> - 2015-10-26 12:25 -0700
                  Re: How to solve this problem in FORTH? humptydumpty <ouatubi@gmail.com> - 2015-10-27 00:47 -0700
                    Re: How to solve this problem in FORTH? lehs <skydda.barnen@gmail.com> - 2015-10-27 08:06 -0700
                      Re: How to solve this problem in FORTH? humptydumpty <ouatubi@gmail.com> - 2015-10-27 23:43 -0700
                        Re: How to solve this problem in FORTH? lehs <skydda.barnen@gmail.com> - 2015-10-28 01:30 -0700
                          Re: How to solve this problem in FORTH? humptydumpty <ouatubi@gmail.com> - 2015-10-28 01:58 -0700
                            Re: How to solve this problem in FORTH? franck.bensusan@gmail.com - 2015-10-28 02:56 -0700
                            Re: How to solve this problem in FORTH? lehs <skydda.barnen@gmail.com> - 2015-10-28 03:36 -0700
                        Re: How to solve this problem in FORTH? Hans Bezemer <the.beez.speaks@gmail.com> - 2015-10-28 15:31 +0100
        Re: How to solve this problem in FORTH? Paul Rubin <no.email@nospam.invalid> - 2015-10-26 21:58 -0700
          Re: How to solve this problem in FORTH? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-10-26 23:38 -0700
          Re: How to solve this problem in FORTH? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-27 09:24 +0000
            Re: How to solve this problem in FORTH? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-10-27 02:54 -0700
      Re: How to solve this problem in FORTH? mhx@iae.nl - 2015-10-26 11:31 -0700
    Re: How to solve this problem in FORTH? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-10-26 04:54 -0400
      Re: How to solve this problem in FORTH? Paul Rubin <no.email@nospam.invalid> - 2015-10-26 02:09 -0700
        Re: How to solve this problem in FORTH? Ron Aaron <rambamist@gmail.com> - 2015-10-26 11:16 +0200
        Re: How to solve this problem in FORTH? Lars Brinkhoff <lars.spam@nocrew.org> - 2015-10-26 10:49 +0100
        Re: How to solve this problem in FORTH? Hans Bezemer <the.beez.speaks@gmail.com> - 2015-10-28 11:22 +0100
          Re: How to solve this problem in FORTH? Howerd <howerdo@yahoo.co.uk> - 2015-10-28 04:09 -0700
          Re: How to solve this problem in FORTH? hughaguilar96@gmail.com - 2015-10-29 19:52 -0700
          Re: How to solve this problem in FORTH? "WJ" <w_a_x_man@yahoo.com> - 2015-10-30 09:00 +0000
      Re: How to solve this problem in FORTH? lehs <skydda.barnen@gmail.com> - 2015-10-26 02:44 -0700

Page 2 of 2 — ← Prev page 1 [2]

#42869

Paul Rubin <no.email@nospam.invalid> writes:
>Raimond Dragomir <raimond.dragomir@gmail.com> writes:
>> : vadd2
>>   local{ v1 v2 v3 | vadd }
>>   { >r v1 @ r@ th @  v2 @ r@ th @  v3 @ r> th ! } vadd !
>>   0 vadd @ execute
>>   1 vadd @ execute
>>   2 vadd @ execute
>> ;
>
>That is nice.

Is there anything wrong with loops?  I did not follow the whole
thread, so maybe somebody has posted a similar solution already, but
anyway, here's my take, based on the above:

: vadd2 {: v1 v2 v3 -- :}
  3 0 ?do
    v1 i th @ v2 i th @ + v3 i th ! 
  loop ;

And that's easy to generalize to vectors of arbitrary length.

- 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 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#42870

marți, 27 octombrie 2015, 11:34:18 UTC+2, Anton Ertl a scris:
> Paul Rubin <no.email@nospam.invalid> writes:
> >Raimond Dragomir <raimond.dragomir@gmail.com> writes:
> >> : vadd2
> >>   local{ v1 v2 v3 | vadd }
> >>   { >r v1 @ r@ th @  v2 @ r@ th @  v3 @ r> th ! } vadd !
> >>   0 vadd @ execute
> >>   1 vadd @ execute
> >>   2 vadd @ execute
> >> ;
> >
> >That is nice.
> 
> Is there anything wrong with loops?  I did not follow the whole
> thread, so maybe somebody has posted a similar solution already, but
> anyway, here's my take, based on the above:
> 
> : vadd2 {: v1 v2 v3 -- :}
>   3 0 ?do
>     v1 i th @ v2 i th @ + v3 i th ! 
>   loop ;
> 
> And that's easy to generalize to vectors of arbitrary length.
> 
> - 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 2015: http://www.rigwit.co.uk/EuroForth2015/

No, there's nothing wrong with loops. Only that the C example wasn't with
loops. If it would have been:
void vadd(int *v1, int *v2, int *v3)
{
  int i;
  for (i = 0; i < 3; i++) {
    v3[i] = v1[i] + v2[i];
  }
}
probably everybody here would have come with loops in the first place.

Anyway, here it is with loops:

: vadd2_loop
  local{ v1 v2 v3 | vadd }
  { >r v1 @ r@ th @  v2 @ r@ th @ +  v3 @ r> th ! } vadd !
  3 for r@ vadd @ execute next
;

and:

: vadd3_loop
  local{ v1 v2 v3 }
  3 for v1 @ v2 @ v3 @ r@ vadd next
;

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

#42853

On Monday, October 26, 2015 at 8:58:34 AM UTC+1, Paul Rubin wrote:
> It's not too bad with gforth locals:
> 
>     : v& ( addr i -- addr ) cells + ;
>     : vadd { v1 v2 v3 -- }
>         3 0 do  v1 i v& @  v2 i v& @ +  v3 i v& !  loop ;

: vadd ( a a a n -- ) cells bounds do @+ rot @+ rot + i ! cell +loop 2drop ;
here 1 , 2 , 3 ,  4 , 5 , 6 , ( addr) dup 3 cells +  pad  3 vadd  
cr .( result: ) pad @+ . @+ . ?

-marcel

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

#42822

On Mon, 26 Oct 2015 03:02:05 -0400, lehs <skydda.barnen@gmail.com> wrote:

> I think your solution is nice, but it's unfair comparing languages
> in such a limited perspective. In Forth arrays have a simple, not
> a complex and static,  implementation.  But what ever buillt in
> system other languages might have, any forther could extend Forth
> to be competitive.
>

Your post is being sent from Google Groups out to Usenet where this
forum exists.  You trimmed all prior content, such as what was said
and who said what, so we don't easily know who you responded to here.
Yes, this is an actual problem.  Some people might not have received
the post you responded to, and others might not have it because it's
almost a year old now.

So, who was this in response too?  ...

 From the message-reply to line in the post's header, it appears
to be in response to the OP (original poster), Marek Brunda, on
Jan 13, 2015, not quite a year ago ...

It's also impolite on Usenet to post to old threads as they aren't
preserved for long time periods on  most Usenet servers, unlike
website forums or Google Groups or Google Groups archive of Usenet.
Not posting to old threads also goes for a few others who just
posted, who should know better.


Rod Pemberton


-- 
When El Chapo is the most beloved man in Mexico and Trump is the most hated,
it shows that Mexico is truly fouled up.

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

#42825

"Rod Pemberton" <boo@fasdfrewar.cdm> writes:
> It's also impolite on Usenet to post to old threads as they aren't
> preserved for long time periods on  most Usenet servers, 

Lots of them including eternal-september are quite persistent these days.
Anyway the problem asked for a Forth implementation of some C code
from  http://prog21.dadgum.com/33.html -- implement the equivalent of:

     void vadd(int *v1, int *v2, int *v3)
     {
          v3[0] = v1[0] + v2[0];
          v3[1] = v1[1] + v2[1];
          v3[2] = v1[2] + v2[2];
     }

to add a pair of 3-d vectors.  It's annoying to do without locals and
somewhat unsatisfying even with them.

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

#42827

On 10/26/2015 11:09, Paul Rubin wrote:

>
>       void vadd(int *v1, int *v2, int *v3)
>       {
>            v3[0] = v1[0] + v2[0];
>            v3[1] = v1[1] + v2[1];
>            v3[2] = v1[2] + v2[2];
>       }
>
> to add a pair of 3-d vectors.  It's annoying to do without locals and
> somewhat unsatisfying even with them.
>

It's pretty simple in 8th (since you got me started on that):

   [1,2] [3,4] ' n:+ a:op

results in:
   [4,6]

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

#42830

Paul Rubin wrote:
> void vadd(int *v1, int *v2, int *v3)
> {
>      v3[0] = v1[0] + v2[0];
>      v3[1] = v1[1] + v2[1];
>      v3[2] = v1[2] + v2[2];
> }

Another solution:

: v+   @ swap @ + swap ! ;
: next   cell+ rot cell+ rot cell+ rot ;
: vadd   3dup v+ next 3dup v+ next v+ ;

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

#42896

Paul Rubin wrote:
> Lots of them including eternal-september are quite persistent these days.
> Anyway the problem asked for a Forth implementation of some C code
> from  http://prog21.dadgum.com/33.html -- implement the equivalent of:
> 
>      void vadd(int *v1, int *v2, int *v3)
>      {
>           v3[0] = v1[0] + v2[0];
>           v3[1] = v1[1] + v2[1];
>           v3[2] = v1[2] + v2[2];
>      }
> 
> to add a pair of 3-d vectors.  It's annoying to do without locals and
> somewhat unsatisfying even with them.

IMHO it's always easy to come up with come kind of problem where lots of
parameters are involved or lots of intermediate results have to be
preserved.

It's also easy to throw lots of locals to it. Hey, we can port straight from
C here without giving it a second thought. We could also be writing C
without ever bothering with Forth. Let's face it: things with a lot of
parameter juggling is just not Forth's thing.

What nobody ever asks is: what does this thing do in its context? If it's
something that is low level and rarely (or may be even totally not) is
gonna change in its lifetime, I have no problem coding it like this. It
works within its context and that all I wanna know. No maintenance there.
It's snug, it's fast, it's doing its job - don't bother.

: add-vector                             ( a1 a2 a3 --)
  >r 0 >r begin                          \ a3[] = a1[]+a2[]
    r@ 3 <                               \ loop through element 0-2
  while
    over r@ th @ over r@ th @ +          \ add the values of both arrays
    r> r@ over th swap 1+ >r !           \ save 'em in the target array
  repeat r> r> drop drop drop drop       \ clean it up
;

Wanna do the Forthy thing? Can do:

: @@+ >r over r@ th @ over r@ th @ + r> ;  ( a1 a2 n -- a1 a2 a1@+a2@ n)
: th++ over th swap 1+ ;                   ( n a -- a+n n+1)
: v+ >r 0 >r begin r@ 3 < while r> @@+ r@ th++ >r ! repeat r> r> 2drop
2drop ;

Some neat 3 lines - doubt whether this will help you maintain it better, but
ok.

But all this is academic. It's not what Forth is all about. Note that C
getopts() is also a horrible over-one-legal-letter size routine - and there
are more, no doubt. It's code that has been crunched a million times. It
works ok. It's not there where the maintenance is.

An example: yesterday I updated my uBasic interpreter by adding over a half
dozen functions. What does it look like?

: (shift) exp,exp shift ;              ( -- n)
: (and)   exp,exp and ;                ( -- n)
: (or)    exp,exp or ;                 ( -- n)
: (xor)   exp,exp xor ;                ( -- n)

And adding them to the symboltable. Now that's Forth, IMHO. I don't care
about how the token is translated to executable code (that works), I don't
care how this is parsed:

  XOR(a+35,b-(30/3))

That's all been done. That's not where the maintenance is.

I don't think we need to get lured in proving that Forth can efficiently
handle this kind of problem. Yes, in the real world you might encounter
problems where Forth has trouble coping. 

But the solution is not in the facilities that a language provides, but in
the context where such a problem occurs. A good design overall and a clear
understanding of the requirements will make the problem either disappear or
make it irrelevant.

Fact remains, in the real world I blow most C programmers out of the window
where productivity and real world problem solving is concerned.

Hans Bezemer

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

#42898

On Wednesday, 28 October 2015 10:20:52 UTC, The Beez  wrote:
> Paul Rubin wrote:
> > Lots of them including eternal-september are quite persistent these days.
> > Anyway the problem asked for a Forth implementation of some C code
> > from  http://prog21.dadgum.com/33.html -- implement the equivalent of:
> > 
> >      void vadd(int *v1, int *v2, int *v3)
> >      {
> >           v3[0] = v1[0] + v2[0];
> >           v3[1] = v1[1] + v2[1];
> >           v3[2] = v1[2] + v2[2];
> >      }
> > 
> > to add a pair of 3-d vectors.  It's annoying to do without locals and
> > somewhat unsatisfying even with them.
> 
> IMHO it's always easy to come up with come kind of problem where lots of
> parameters are involved or lots of intermediate results have to be
> preserved.
> 
> It's also easy to throw lots of locals to it. Hey, we can port straight from
> C here without giving it a second thought. We could also be writing C
> without ever bothering with Forth. Let's face it: things with a lot of
> parameter juggling is just not Forth's thing.
> 
> What nobody ever asks is: what does this thing do in its context? If it's
> something that is low level and rarely (or may be even totally not) is
> gonna change in its lifetime, I have no problem coding it like this. It
> works within its context and that all I wanna know. No maintenance there.
> It's snug, it's fast, it's doing its job - don't bother.
> 
> : add-vector                             ( a1 a2 a3 --)
>   >r 0 >r begin                          \ a3[] = a1[]+a2[]
>     r@ 3 <                               \ loop through element 0-2
>   while
>     over r@ th @ over r@ th @ +          \ add the values of both arrays
>     r> r@ over th swap 1+ >r !           \ save 'em in the target array
>   repeat r> r> drop drop drop drop       \ clean it up
> ;
> 
> Wanna do the Forthy thing? Can do:
> 
> : @@+ >r over r@ th @ over r@ th @ + r> ;  ( a1 a2 n -- a1 a2 a1@+a2@ n)
> : th++ over th swap 1+ ;                   ( n a -- a+n n+1)
> : v+ >r 0 >r begin r@ 3 < while r> @@+ r@ th++ >r ! repeat r> r> 2drop
> 2drop ;
> 
> Some neat 3 lines - doubt whether this will help you maintain it better, but
> ok.
> 
> But all this is academic. It's not what Forth is all about. Note that C
> getopts() is also a horrible over-one-legal-letter size routine - and there
> are more, no doubt. It's code that has been crunched a million times. It
> works ok. It's not there where the maintenance is.
> 
> An example: yesterday I updated my uBasic interpreter by adding over a half
> dozen functions. What does it look like?
> 
> : (shift) exp,exp shift ;              ( -- n)
> : (and)   exp,exp and ;                ( -- n)
> : (or)    exp,exp or ;                 ( -- n)
> : (xor)   exp,exp xor ;                ( -- n)
> 
> And adding them to the symboltable. Now that's Forth, IMHO. I don't care
> about how the token is translated to executable code (that works), I don't
> care how this is parsed:
> 
>   XOR(a+35,b-(30/3))
> 
> That's all been done. That's not where the maintenance is.
> 
> I don't think we need to get lured in proving that Forth can efficiently
> handle this kind of problem. Yes, in the real world you might encounter
> problems where Forth has trouble coping. 
> 
> But the solution is not in the facilities that a language provides, but in
> the context where such a problem occurs. A good design overall and a clear
> understanding of the requirements will make the problem either disappear or
> make it irrelevant.
> 
> Fact remains, in the real world I blow most C programmers out of the window
> where productivity and real world problem solving is concerned.
> 
> Hans Bezemer

Hi The Beez,

> But the solution is not in the facilities that a language provides, but in 
> the context where such a problem occurs. A good design overall and a clear 
> understanding of the requirements will make the problem either disappear or 
> make it irrelevant.
Couldn't have put it better myself :-)

Best regards,
Howerd

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

#42987

On Wednesday, October 28, 2015 at 3:20:52 AM UTC-7, The Beez wrote:
> It's also easy to throw lots of locals to it. Hey, we can port straight from
> C here without giving it a second thought. We could also be writing C
> without ever bothering with Forth. Let's face it: things with a lot of
> parameter juggling is just not Forth's thing.

This is a quote from my text: http://www.forth.org/Stundurd.txt
----------------------------------------------------------------------------
A good way to avoid stack-juggling is to use structs, and only have the pointers to the structs on the data-stack. Our LINE.LENGTH function shown earlier was an example of this. Stundurd provides a heap (that is something else we can expect that Charles Moore won't provide ever), so the heap should be used. Whenever several data are used together and are only meaningful in relation to each other (like the X and Y coordinates of a point), then these data should be packed together into a struct and the struct held in the heap, and only the pointer to the struct passed around on the stack. This greatly reduces the amount of data on the stack, which increases both readability and efficiency.
----------------------------------------------------------------------------

> Yes, in the real world you might encounter
> problems where Forth has trouble coping. 
> ...
> Fact remains, in the real world I blow most C programmers out of the window
> where productivity and real world problem solving is concerned.

These statements are contradictory.

What real world problems are you having trouble with? Are you asking for help in solving them?

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

#42990

Hans Bezemer wrote:

> I don't think we need to get lured in proving that Forth can efficiently
> handle this kind of problem. Yes, in the real world you might encounter
> problems where Forth has trouble coping.

Ruby:

"I don't think we need to get lured in proving that Forth can efficiently
handle this kind of problem. Yes, in the real world you might encounter
problems where Forth has trouble coping.".split.rotate(3).drop(7).
rotate(9).drop(10).join " "

 ===>
"Forth has trouble coping. I don't think that Forth can efficiently handle
this kind of problem."

-- 
The report card by the American Society of Civil Engineers showed the national
infrastructure a single grade above failure, a step from declining to the point
where everyday things simply stop working the way people expect them to. ---
washingtonpost.com/local/trafficandcommuting/us-infrastructure-gets-d-in-annual-report/2013/03/19/c48cb010-900b-11e2-9cfd-36d6c9b5d7ad_story.html

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

#42829

Den måndag 26 oktober 2015 kl. 09:54:03 UTC+1 skrev Rod Pemberton:
> On Mon, 26 Oct 2015 03:02:05 -0400, lehs <skydda.barnen@gmail.com> wrote:
> 
> > I think your solution is nice, but it's unfair comparing languages
> > in such a limited perspective. In Forth arrays have a simple, not
> > a complex and static,  implementation.  But what ever buillt in
> > system other languages might have, any forther could extend Forth
> > to be competitive.
> >
> 
> Your post is being sent from Google Groups out to Usenet where this
> forum exists.  You trimmed all prior content, such as what was said
> and who said what, so we don't easily know who you responded to here.
> Yes, this is an actual problem.  Some people might not have received
> the post you responded to, and others might not have it because it's
> almost a year old now.
> 
> So, who was this in response too?  ...
> 
>  From the message-reply to line in the post's header, it appears
> to be in response to the OP (original poster), Marek Brunda, on
> Jan 13, 2015, not quite a year ago ...
> 
> It's also impolite on Usenet to post to old threads as they aren't
> preserved for long time periods on  most Usenet servers, unlike
> website forums or Google Groups or Google Groups archive of Usenet.
> Not posting to old threads also goes for a few others who just
> posted, who should know better.
> 
> 
> Rod Pemberton
> 
> 
> -- 
> When El Chapo is the most beloved man in Mexico and Trump is the most hated,
> it shows that Mexico is truly fouled up.

Okay, I got Your point, sir. 

Actually my answer was addressed to the original poster but after been reading the other solutions it could have been addressed to any of them.
____________________
Lars-Erik Svahn
http://forthmath.blogspot.se
https://github.com/Lehs/BIG-INTEGER-ANS-FORTH

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web