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

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

Re: Dynamic programming 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

  Re: Dynamic programming in Forth lehs <skydda.barnen@gmail.com> - 2017-02-14 03:53 -0800
    Re: Dynamic programming in Forth "David N. Williams" <williams@umich.edu> - 2017-02-14 08:19 -0500
      Re: Dynamic programming in Forth lehs <skydda.barnen@gmail.com> - 2017-02-14 06:03 -0800
        Re: Dynamic programming in Forth minforth@arcor.de - 2017-02-14 07:44 -0800
          Re: Dynamic programming in Forth Alex <alex@rivadpm.com> - 2017-02-14 16:34 +0000

#54848 — Re: Dynamic programming in Forth

Last year I started this project to incorporate nested sets in Forth, using separate stacks representing sets, in princip, as counted bundles of numbers:

n1 ... nk k

To be able to form nested sets (also including ordered n-tuples) the bundles are implemented

n1 ... nk -2k    for (unordered) sets and
n1 ... nk -2k-1  for ordered n-tuples.

I'm very pleased with the result as I can program efficiently on a higher level now. Of course the code could be much more efficient using computer scientific state of the art concepts, but this would probably be far more complicated and less general. Using stacks for implementing new data structures in Forth is very easy to do and to use and results in fairly effective code and code writing.

By know - except from singles, doubles and floating points - I have stacks for big integers, nested sets and strings and I have no problem with using this. I can remain a productive forther and all the time I'm using my inventions.

A long time ago I implemented lists in the conventional way with cells and a list of free cells and some garbage collection, but I never used it. I'm aware of that a lot of interesting programming is possible with the general concept of lists, but a list is nothing more than a simple graph which easily can be implemented using sets:

{(1,2),(2,3),(3,4),(4,1)}

represents the circular list [1,2,3,4,1]. Etc.

Concepts for Lisp-type lists can be generalized to general graphs and used in all kind of smart programming.

I really think this is ONE way to extend Forth in an adequate manner, which at least is adequate for experimenting and for making prototypes.

http://forthmath.blogspot.se

[toc] | [next] | [standalone]

#54849

On 2/14/17 6:53 AM, lehs wrote:
 > Last year I started this project to incorporate nested sets in Forth,
 > using separate stacks representing sets, in princip, as counted
 > bundles of numbers:
 >
 > n1 ... nk k
 >
 > To be able to form nested sets (also including ordered n-tuples) the
 > bundles are implemented
 >
 > n1 ... nk -2k    for (unordered) sets and
 > n1 ... nk -2k-1  for ordered n-tuples.
 >
 > I'm very pleased with the result as I can program efficiently on a
 > higher level now. Of course the code could be much more efficient
 > using computer scientific state of the art concepts, but this would
 > probably be far more complicated and less general. Using stacks for
 > implementing new data structures in Forth is very easy to do and to
 > use and results in fairly effective code and code writing.
 >
 > By know - except from singles, doubles and floating points - I have
 > stacks for big integers, nested sets and strings and I have no problem
 > with using this. I can remain a productive forther and all the time
 > I'm using my inventions.

I always liked the idea of freely introducing new stacks.  They're easy
to do, convenient to use, and can be implemented relatively efficiently.
As far as I'm concerned, stacks are *the* way to do data types in Forth,
as long as it's not overdone.  :-)

-- David

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

#54850

Den tisdag 14 februari 2017 kl. 14:19:08 UTC+1 skrev David N. Williams:
> On 2/14/17 6:53 AM, lehs wrote:
>  > Last year I started this project to incorporate nested sets in Forth,
>  > using separate stacks representing sets, in princip, as counted
>  > bundles of numbers:
>  >
>  > n1 ... nk k
>  >
>  > To be able to form nested sets (also including ordered n-tuples) the
>  > bundles are implemented
>  >
>  > n1 ... nk -2k    for (unordered) sets and
>  > n1 ... nk -2k-1  for ordered n-tuples.
>  >
>  > I'm very pleased with the result as I can program efficiently on a
>  > higher level now. Of course the code could be much more efficient
>  > using computer scientific state of the art concepts, but this would
>  > probably be far more complicated and less general. Using stacks for
>  > implementing new data structures in Forth is very easy to do and to
>  > use and results in fairly effective code and code writing.
>  >
>  > By know - except from singles, doubles and floating points - I have
>  > stacks for big integers, nested sets and strings and I have no problem
>  > with using this. I can remain a productive forther and all the time
>  > I'm using my inventions.
> 
> I always liked the idea of freely introducing new stacks.  They're easy
> to do, convenient to use, and can be implemented relatively efficiently.
> As far as I'm concerned, stacks are *the* way to do data types in Forth,
> as long as it's not overdone.  :-)
> 
> -- David

I do agree. It's the only way to keep the Forth way of programming, a simple and complete idea of how to manage computing. Other methods would either be more complicated to implement och more complicated to use.

I love it and it makes me productive.

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

#54851

Am Dienstag, 14. Februar 2017 15:03:09 UTC+1 schrieb lehs:
> Den tisdag 14 februari 2017 kl. 14:19:08 UTC+1 skrev David N. Williams:
> > On 2/14/17 6:53 AM, lehs wrote:
> >  > Last year I started this project to incorporate nested sets in Forth,
> >  > using separate stacks representing sets, in princip, as counted
> >  > bundles of numbers:
> >  >
> >  > n1 ... nk k
> >  >
> >  > To be able to form nested sets (also including ordered n-tuples) the
> >  > bundles are implemented
> >  >
> >  > n1 ... nk -2k    for (unordered) sets and
> >  > n1 ... nk -2k-1  for ordered n-tuples.
> >  >
> >  > I'm very pleased with the result as I can program efficiently on a
> >  > higher level now. Of course the code could be much more efficient
> >  > using computer scientific state of the art concepts, but this would
> >  > probably be far more complicated and less general. Using stacks for
> >  > implementing new data structures in Forth is very easy to do and to
> >  > use and results in fairly effective code and code writing.
> >  >
> >  > By know - except from singles, doubles and floating points - I have
> >  > stacks for big integers, nested sets and strings and I have no problem
> >  > with using this. I can remain a productive forther and all the time
> >  > I'm using my inventions.
> > 
> > I always liked the idea of freely introducing new stacks.  They're easy
> > to do, convenient to use, and can be implemented relatively efficiently.
> > As far as I'm concerned, stacks are *the* way to do data types in Forth,
> > as long as it's not overdone.  :-)
> > 
> > -- David
> 
> I do agree. It's the only way to keep the Forth way of programming, a simple and complete idea of how to manage computing. Other methods would either be more complicated to implement och more complicated to use.
> 
> I love it and it makes me productive.

That's the right attitude: just do it and get the work done. Optimize later.

In real world applications lists can become quite longish and dynamic. Using LIFO buffers (stacks) to store lists has the additional charm that one can take advantage of Forth's stack-cleaning CATCH/THROW mechanism to avoid garbage collection.

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

#54852

On 2/14/2017 15:44, minforth@arcor.de wrote:
> the additional charm that one can take advantage of Forth's
> stack-cleaning CATCH/THROW mechanism

Which is exacty how I feel about CATCH and THROW. They are, to me, not a 
means of indicating errors or exceptions, but a means of providing a 
type of checkpoint with backtracking.

There are limitations; there's no guarantee that your newly 
depth-restored stack will have usable contents for example, or that some 
other global-ish variable or event hasn't hosed your environment. And 
restoring the input source is a hard trick, given that a THROW might 
happen a very long way indeed from the original CATCH.

But given these known limitations, they're still a very useful pair of 
words.

-- 
Alex

[toc] | [prev] | [standalone]

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

csiph-web