"deep" stack questions
Judges1318
Recently I have been trying to distill a base set
of stack operators - a small set from which everything
else derives. A few questions bug me, on how to access
elements deeper on (in) the stack.
My set of absolutely necessary operators are DIG and BURY
(those are my provisional names, they may already exist under
other names).
DIG ( n -- d ) ( consumes 'n', copies the value from the cell at depth
'n' to the top )
so
: DUP 0 DIG ;
: OVER 1 DIG ;
etc.
BURY ( d n -- ) ( consumes 'n', copies the top of stack to the cell at
depth 'n+1', then drops the top of stack )
so
: NIP 0 BURY ;
: DROP 1 DIG 0 BURY 0 BURY
: SWAP 1 DIG 1 DIG 2 BURY 0 BURY ;
etc., efficiency notwithstanding.
I have no definite conclusion as yet,
so, could someone please kindly comment on these?
Jerry Avins
I'm too sleepy to grok BURY right now. Your DIG is called PICK .
Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
George Morrison
It's usually considered bad style to access items deep in the stack. If
you're doing it, you probably need to factor more.
As I see it there are three fundamental types of operation on the stack
1. Duplicate an item (DUP, OVER)
2. Discard an item (DROP, NIP)
3. Reorder the stack (SWAP, ROT)
You've sort of combined the last two in BURY.
You might want to look up PICK and ROLL in the standard
http://lars.nocrew.org/dpans/dpans.htm
PICK is the same as your DIG.
Charles Moore's colorforth
www.colorforth.com
has 5 stack operators DUP, DROP, OVER, PUSH and POP (those last two are
the same as >R and R> in the standard).
--
George Morrison | george morrison gedamo demon co uk
Aberdeen, Scotland | . @ . . .
billy
runtime, makes code difficult to read, analyse, and write. It's also
not needed.
The Yahoo group "concatenative" has discussed this issue in the past;
the question is, what is the minimal set of dataflow combinators that
can generate all the others?
What you need is DROP, SWAP, >R, and R>. You can dive to any depth on
the stack by shoving things onto the return stack, then grab the thing
you want and come to the surface. You can make runtime effects using
loops, if you want.
-Billy
rickman
How do you move n things to the return stack using a loop in a standard
way? I belive you can use the return stack in a loop, but that makes
the loop variables inaccessible, further the return stack must be
restored to its original state before reaching the end of the loop, so
you can't use it for storage between iterations.
I looked at this long and hard when I was defining my CPU instruction
set. I eventually decided that implementing PICK and ROLL in an
efficient way was not required. But in analyzing the problem, I did
decide that it was important to optimize looping and found a simple
way.
--
Rick "rickman" Collins
rick.c...@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.
Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX
Jeff
> What you need is DROP, SWAP, >R, and R>.
How do you make a DUP using these ?
I actually would replace your DROP (you drop with >R) by a DUP
no?
Jerry Avins
R@ is a great help. DUP could be >R R@ R> . But isn't it a rather
academic discussion? Wouldn't you do all those words as primitives?
Roger Ivie
If you drop with >R, all you've done is move the hot potato to the
return stack. How do you DROP it from the return stack?
--
Roger Ivie
ri...@ridgenet.net
http://anachronda.webhop.org/
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/P d- s:+++ a+ C++ UB--(++++) !P L- !E W++ N++ o-- K w O- M+ V+++ PS+
PE++ Y+ PGP t+ 5+ X-- R tv++ b++ DI+++ D+ G e++ h--- r+++ z+++
------END GEEK CODE BLOCK------
Jeff
>>> What you need is DROP, SWAP, >R, and R>.
>>
>> How do you make a DUP using these ?
>> I actually would replace your DROP (you drop with >R) by a DUP
>
> If you drop with >R, all you've done is move the hot potato to the
> return stack. How do you DROP it from the return stack?
I don't drop it from the rstack, I let it there ;)
what about dup ? How do you dup with only drop swap >r and r> ?
You can't I guess
Jerry Avins
> Le Mon, 30 Aug 2004 01:23:14 +0000, Roger Ivie a écrit :
>
>
>>>>What you need is DROP, SWAP, >R, and R>.
>>>
>>>How do you make a DUP using these ?
>>>I actually would replace your DROP (you drop with >R) by a DUP
>>
>>If you drop with >R, all you've done is move the hot potato to the
>>return stack. How do you DROP it from the return stack?
>
>
> I don't drop it from the rstack, I let it there ;)
Then what do you return to? In some implementations, R> DROP exits the
calling word. In most implementations, unbalanced return-stack
operations between colon and semicolon will crash. On processors without
an instruction that jumps to the address in a register, the affect can
be achieved by pushing an address onto the stack and executing
subroutine return.
> what about dup ? How do you dup with only drop swap >r and r> ?
>
> You can't I guess
You need R@ , as I wrote earlier.
Judges1318
George Morrison wrote:
> Judges1318 wrote:
>>
>> DIG ( n -- d ) ( consumes 'n', copies the value from the cell at
>> depth 'n' to the top )
>> so
>> : DUP 0 DIG ;
>> : OVER 1 DIG ;
>> etc.
>>
>> BURY ( d n -- ) ( consumes 'n', copies the top of stack to the cell at
>> depth 'n+1', then drops the top of stack )
>> so
>> : NIP 0 BURY ;
>> : DROP 1 DIG 0 BURY 0 BURY
>> : SWAP 1 DIG 1 DIG 2 BURY 0 BURY ;
>> etc., efficiency notwithstanding.
>>
> PICK is the same as your DIG.
I realise that, however, I deliberately wanted to
give "new" names, to make a sort of separation.
> It's usually considered bad style to access items deep in the stack. If
> you're doing it, you probably need to factor more.
>
It is not so much a case for factoring, but to find a
base for stack operators similar to, say, nor being a
base for all (1 and 2 argument) boolean functions:
: not dup nor ;
: or nor not ;
: and not swap not nor ;
etc.
Can something similar be done with stack operators?
Are PICK and ROLL (and perhaps DROP) a base?
What is the smallest base? What is the richest or most
efficient base, in the sense that it gives most of useful
stack operators with least effort either programming or
computational?
andr...@littlepinkcloud.invalid
> George Morrison wrote:
>
>> It's usually considered bad style to access items deep in the stack. If
>> you're doing it, you probably need to factor more.
>>
> It is not so much a case for factoring, but to find a
> base for stack operators similar to, say, nor being a
> base for all (1 and 2 argument) boolean functions:
> : not dup nor ;
> : or nor not ;
> : and not swap not nor ;
> etc.
> Can something similar be done with stack operators?
Yes, certainly.
> Are PICK and ROLL (and perhaps DROP) a base?
> What is the smallest base?
SWAP, DUP, DROP, R> and >R.
: pick ?dup if swap >r 1- recurse r> swap else dup then ;
: roll ?dup if swap >r 1- recurse r> swap then ;
> What is the richest or most efficient base, in the sense that it
> gives most of useful stack operators with least effort either
> programming or computational?
You'd perhaps want to add OVER and R@ to the above set for
efficiency's sake.
ROT is trivially >R SWAP R> SWAP so there's no need to define
it as a primitive.
Andrew.
Anton Ertl
[minimal set of stack words]
>But isn't it a rather
>academic discussion?
No.
>Wouldn't you do all those words as primitives?
Eventually, probably yes. But during development of a new target it's
useful to just have to define a minimum set of primitives, and be able
to test that. Once the Forth system works with that, you can add more
primitives for better efficiency. Since you can add and remove them
one at a time, finding bugs is relatively easy.
Or at least that's what the Gforth EC people tell me. However, AFAIK
they cheat and use sp@.
- 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
EuroForth 2004: http://www.complang.tuwien.ac.at/anton/euroforth2004/
Deadline (refereed): August 28, 2004; Conference: November 19-21, 2004
Julian V. Noble
>
> Recently I have been trying to distill a base set
> of stack operators - a small set from which everything
> else derives. A few questions bug me, on how to access
> elements deeper on (in) the stack.
>
> My set of absolutely necessary operators are DIG and BURY
> (those are my provisional names, they may already exist under
> other names).
My general advice re: deep stacks is "Don't".
--
Julian V. Noble
Professor Emeritus of Physics
j...@lessspamformother.virginia.edu
^^^^^^^^^^^^^^^^^^
http://galileo.phys.virginia.edu/~jvn/
"For there was never yet philosopher that could endure the
toothache patiently."
-- Wm. Shakespeare, Much Ado about Nothing. Act v. Sc. 1.
ur2c
> My set of absolutely necessary operators are DIG and BURY
> DIG ( n -- d ) ( consumes 'n', copies the value from the cell at depth
> 'n' to the top )
> so
> : DUP 0 DIG ;
> : OVER 1 DIG ;
> etc.
>
> BURY ( d n -- ) ( consumes 'n', copies the top of stack to the cell at
> depth 'n+1', then drops the top of stack )
> so
> : NIP 0 BURY ;
> : DROP 1 DIG 0 BURY 0 BURY
> : SWAP 1 DIG 1 DIG 2 BURY 0 BURY ;
> etc., efficiency notwithstanding.
I choose to use a variation of PICK , but allowing negative parameters
by parameterizing the stack elements from 1 instead of 0.
Call the operator S .
S takes an integer n as an argument, where abs(n) =< DEPTH .
S ( X[n] .. X[1] -n -- X[n-1] .. X[1] )
S ( X[n] .. X[1] 0 -- X[n] .. X[1] )
S ( X[n] .. X[1] +n -- X[n] .. X[1] X[n] )
So " -n S " is actually a shorhand for " n -S " .
S substitutes DIG and BURY .
My motivation for doing this has been to unify
stack operation names.
If I write
...
: -1S -1 S ;
: 0S 0 S ;
: 1S 1 S ;
...
then
' nip alias -2S
' drop alias -1S
' noop alias 0S
' dup alias 1S
' over alias 2S
' pluck alias 3S
in which the S-names are arguably easier to remember and to operate
upon than the original names in the same way as the month names are
easier in Chinese (1-month, 2-month, ...) than in English.
Likewise I define " n T " to mean
" 1- roll " if n is positive and " negate 1- -roll " if n is negative
so that
' -rot alias -3T
' swap alias -2T
' noop alias -1T
' abort alias 0T
' noop alias 1T
' swap alias 2T
' rot alias 3T
ur2c
rickman
Ok, I'll bite. How exactly is "0T" easier to remember than "abort"? I
would never consider coding *unrelated* operations in this way. I see
little relation between dup, drop or rot and I see *no* relation between
any stack op and noop or abort that would make me even consider a
notation like this. What exactly is the advantage?
Your analogy to the Chinese calendar is not valid because all months are
pretty equivalent to the others. So most names are very arbitrary and
the numbers are only a slight improvement. But most of the functions
you are combining are very distinct. Combining them with this sort of
nomenclature obfucates their function and makes them *harder* to
remember in my opinion.
Jerry Avins
...
> I choose to use a variation of PICK , but allowing negative parameters
> by parameterizing the stack elements from 1 instead of 0.
I see the word PLUCK below and that gives me hope that you didn't change
the function without changing the name.
...
Elizabeth D Rather
news:413388D5...@yahoo.com...
> ur2c wrote:
> >
> > Judges1318 <acc...@beaurat.at.hotpop.stop.com> wrote in message
news:<413174C0...@beaurat.at.hotpop.stop.com>...
> > " 1- roll " if n is positive and " negate 1- -roll " if n is negative
> > so that
> >
> > ' -rot alias -3T
> > ' swap alias -2T
> > ' noop alias -1T
> > ' abort alias 0T
> > ' noop alias 1T
> > ' swap alias 2T
> > ' rot alias 3T
>
> Ok, I'll bite. How exactly is "0T" easier to remember than "abort"? I
> would never consider coding *unrelated* operations in this way. I see
> little relation between dup, drop or rot and I see *no* relation between
> any stack op and noop or abort that would make me even consider a
> notation like this. What exactly is the advantage?
I think the intent is that 0T is supposed to be an error, and hence abort.
But I completely agree that these names are really obfuscating what's going
on, and make code lots harder to read.
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-491-3356
5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
billy
observed).
There may be more efficient combinator sets; I forget the results of
the discussion. It's notable that the most efficient set we found for
Joy (a functional Forthlike) was not only capable of forming any stack
arrangement, it was actually computationally complete.
-Billy
Judges1318
Julian V. Noble wrote:
>
> My general advice re: deep stacks is "Don't".
>
>
Well, it is "don't unless you have to", really.
It is neat if I can put everything onto the data stack,
so to my preference, PICK and ROLL (actually DIG and BURY)
take priority over R> and >R, and they both take priority
over allocating a VARIABLE. I find VARIABLEs so unforthly.
andr...@littlepinkcloud.invalid
> Julian V. Noble wrote:
They are. However, putting a lot of variables on the stack is also
unforthly,
Andrew.
Michael L Gassanenko
> Jerry Avins <j...@ieee.org> writes:
> [minimal set of stack words]
> >But isn't it a rather
> >academic discussion?
>
> No.
>
> >Wouldn't you do all those words as primitives?
>
> Eventually, probably yes. But during development of a new target it's
> useful to just have to define a minimum set of primitives, and be able
> to test that.
> Once the Forth system works with that, you can add more
> primitives for better efficiency. Since you can add and remove them
> one at a time, finding bugs is relatively easy.
As to new targets, I usually debug data stack operators first,
then look at the return stack ones.
If data stack primitives may be done without return stack access,
they should be done this way.
(BTW, there are "underwater stones" with the implementation of
PICK/ROLL via r-stack access: theoretically correct code may
break when shallow return stack overflows.)
ur2c
> How exactly is "0T" easier to remember than "abort"?
Assuming that someone knows the definition of T,
that person can easily guess that "0 T" should mean to ABORT .
That means at least one less word name to remember.
> Your analogy to the Chinese calendar is not valid because all months are
> pretty equivalent to the others.
Whether things are alike or not depends on the viewpoint.
The S operator provides a viewpoint such that many stack operations
with different names look "pretty equivalent to" each other.
ursc
Elizabeth D Rather
news:2004Aug3...@mips.complang.tuwien.ac.at...
> Jerry Avins <j...@ieee.org> writes:
...
> >Wouldn't you do all those words as primitives?
>
> Eventually, probably yes. But during development of a new target it's
> useful to just have to define a minimum set of primitives, and be able
> to test that. Once the Forth system works with that, you can add more
> primitives for better efficiency. Since you can add and remove them
> one at a time, finding bugs is relatively easy.
Well, we start with the stack operations as primitives because that helps us
adapt the model to the architecture we're doing the implementation for. We
pick register allocations, for example, and then test that design by writing
the primitives. Occasionally we'll realize that a different allocation will
make the primitives better, and it's good to know that sooner rather than
later.
rickman
>
> rickman <spamgo...@yahoo.com> wrote in message news:<413388D5...@yahoo.com>...
>
> > How exactly is "0T" easier to remember than "abort"?
>
> Assuming that someone knows the definition of T,
> that person can easily guess that "0 T" should mean to ABORT .
> That means at least one less word name to remember.
Ok, what is the definition of "T"? If you just list a table, like in
the other post, then I don't see how this is "easy" to remember, rather
it is just arbitrary. Even if "0 T" represents an error, I don't see
how this implies an abort rather than just an error which will produce
incorrect operation.
> > Your analogy to the Chinese calendar is not valid because all months are
> > pretty equivalent to the others.
>
> Whether things are alike or not depends on the viewpoint.
> The S operator provides a viewpoint such that many stack operations
> with different names look "pretty equivalent to" each other.
I am not trying to be arguementative about this, but I really don't see
the advantage unless you are writing some sort of program generating
program. I don't think the S operator is any more intuitive or easier
to remember than the few stack words. Are there any programmers who do
not know what NOOP means? Is DUP a difficult thing to remember? On the
other hand, the two functions of S, duplicating and deleting, are not
automatically intuitive from the + and - number supplied. If this
replaced a dozen words, then I would agree with you. But from what I
have read here and elsewhere when I did a survey, of the words you
equate to an S operation, only DROP, DUP and OVER are frequently used in
Forth programs. I guess NIP may have some useage, but I have not seen
it much and there was a recent discussion about PLUCK, ROLL and PICK
where examples were given showing that they are very seldom used and
mostly considered to have been used poorly.
Do I misunderstand your intent? Are you thinking in terms of a standard
form to be used by software, or is this intended to help people use
these stack operations?
andr...@littlepinkcloud.invalid
> (BTW, there are "underwater stones" with the implementation of
> PICK/ROLL via r-stack access: theoretically correct code may
> break when shallow return stack overflows.)
Sure, but that's mostly on a small embedded target. And you have to
ask why anyone is using PICK/ROLL on a small embedded target. These
words are, in any case, only necessary for ANS compliance.
Andrew.
Julian V. Noble
It is also a remarkably good way to get lost. If stuff has
to be PICKed from deep on a stack, it is a signal that it should
have been placed in VARIABLEs, VALUEs or some other data structure.
I have written some fairly long and complex programs by now. At
first I thought deep stacks were often inevitable. Now I know better.
They can be avoided with a little thought.
Here is how you can lose your way with deep stacks: suppose you have a
word that needs to PICK the 17th item on the stack. So you would say
16 PICK ( ... NOS #17)
but now you have to make a change: In between where you did 16 PICK and
the preceding word, you need to do something else. This other word may
take some items off the stack, meaning you now want to say
14 PICK
rather than 16 PICK. That means you have to recall exactly where you
did the PICKing and fix it right away. Can you do that? Probably you
say, "Well, I'll fix that up later." This means you will probably
forget to fix it, and now you have a hard-to-find bug.
Deep stacks are un-Forth-ish because they negate a primary advantage
of programming in Forth: making word definitions brief, structured,
self-contained, and easily check-able. Forth lets you avoid many of the
pitfalls that other languages naturally seem to place in one's way.
Why go out of your way to re-introduce them?
Jeff Fox
> Forth lets you avoid many of the
> pitfalls that other languages naturally seem to place in one's way.
> Why go out of your way to re-introduce them?
Since it is what almost all new (and many not-so-new) Forth programmers
do it is interesting to question why they do it.
One of my theories is that most of the problem solving that they do
by habit is solving the problems that are built into the enviroment
that they are used to. Avoiding those problms is not their habit,
solving them is, so they have to re-introduce them in order to keep
solving them.
Most c.l.f threads are examples of exactly this, I am used to doing
... (describe feature) in ... (name language or evironment). Much
of the discussion is about how the feature works in C or Java or C++
or VB or whatever. There is also some discussion of how to implement
it in Forth and re-introduce a whole set of problems when Forth already
has a set of facilites to obsolete the said feature.
It seems the most natural thing to say I know how to ... in ... and
Forth can be extended to do it that way. As they are more familar
with ... you just can't expect them to know that Forth either just
doesn't have to deal with ... or has an alternate Forth mechanism
that fits nicely with Forth but which works in a way that they
have not yet made habit. This happened to me a lot for the first
twenty years that I was using Forth.
Deep stacks is a good example. 'Deep stack access' is an oximoron.
Deep access is fine for stack frames, stacks are accessed from the
top. Deep stack access? You mean ROT?
A good rule of thumb for what shallow/deep mean in regard to
Forth stacks is to say that you should be able to keep the mental
picture easily. Can you remember two or three random 32-bit
numbers or Forth names in sequence for half an hour while doing
some mentally demanding task? Can you remember 17 random 32-bit
numbers or Forth names in sequence the same way?
Even people who can remember 17 random 32-bit numbers easily and
keep the image in their mind easily while programming need to remember
that other people trying to read their code will not be able to do
it. Even stack diagrams with these >17 deep stack pictures won't
help that much. They just make it really obvious that some code
despirately needs rethinking and rewriting.
Best Wishes,
Jeff Fox
m-coughlin
[snip]
>
> One of my theories is that most of the problem solving that they do
> by habit is solving the problems that are built into the enviroment
> that they are used to. Avoiding those problms is not their habit,
> solving them is, so they have to re-introduce them in order to keep
> solving them.
>
> Most c.l.f threads are examples of exactly this, I am used to doing
> ... (describe feature) in ... (name language or evironment). Much
> of the discussion is about how the feature works in C or Java or C++
> or VB or whatever. There is also some discussion of how to
> implement it in Forth and re-introduce a whole set of problems
> when Forth already has a set of facilites to obsolete the said
> feature.
Well Forth may already have a set of facilities to obsolete
the problem features of other languages or operating systems.
But there is one area where all those other programming systems
beat Forth. That is in the education and training of new
programmers. A good way to show the advantages of Forth is to
use it teach new programmers before they can only think in terms
of other languages. Why don't we do this? Why don't we even seem
to worry much about why we don't do this?
[snip]
> Deep stacks is a good example. 'Deep stack access' is an oximoron.
> Deep access is fine for stack frames, stacks are accessed from the
> top. Deep stack access? You mean ROT?
>
> A good rule of thumb for what shallow/deep mean in regard to
> Forth stacks is to say that you should be able to keep the mental
> picture easily. Can you remember two or three random 32-bit
> numbers or Forth names in sequence for half an hour while doing
> some mentally demanding task? Can you remember 17 random
> 32-bit numbers or Forth names in sequence the same way?
>
> Even people who can remember 17 random 32-bit numbers easily
> and keep the image in their mind easily while programming need
> to remember that other people trying to read their code will not
> be able to do it. Even stack diagrams with these >17 deep stack
> pictures won't help that much. They just make it really obvious
> that some code despirately needs rethinking and rewriting.
Keeping things simple so people can understand Forth
listings is an excellent reason to use shallow stacks. But does
this lead to a less efficient method of programming? Suppose you
were dealing with an easily remembered set of data, such as
points for a discrete Fourier transform or the elements of a
matrix to be inverted. Is there a proof that keeping the data in
arrays and using shallow stacks is just as fast as some scheme
for putting all the data on one or more deep stacks?
--
Michael Coughlin m-cou...@comcast.net Cambridge, MA USA
don groves
coug...@comcast.net wrote...
> Jeff Fox wrote:
>
> > 32-bit numbers or Forth names in sequence the same way?
> >
> > Even people who can remember 17 random 32-bit numbers easily
> > and keep the image in their mind easily while programming need
> > to remember that other people trying to read their code will not
> > be able to do it. Even stack diagrams with these >17 deep stack
> > pictures won't help that much. They just make it really obvious
> > that some code despirately needs rethinking and rewriting.
>
> Keeping things simple so people can understand Forth
> listings is an excellent reason to use shallow stacks. But does
> this lead to a less efficient method of programming? Suppose you
> were dealing with an easily remembered set of data, such as
> points for a discrete Fourier transform or the elements of a
> matrix to be inverted. Is there a proof that keeping the data in
> arrays and using shallow stacks is just as fast as some scheme
> for putting all the data on one or more deep stacks?
On the other hand, how likely is it that a beginning Forther
would be reading code having to do with Fourier transforms?
Keeping code easy to read at the upper levels of a program and
burying the more complex stuff would seem to do what is proposed
and is good programming practice as well.
--
dg
Marcel Hendrix
> In article <413D24FA...@comcast.net>, m-cou...@comcast.net wrote...
>> Keeping things simple so people can understand Forth
>> listings is an excellent reason to use shallow stacks. But does
>> this lead to a less efficient method of programming? Suppose you
>> were dealing with an easily remembered set of data, such as
>> points for a discrete Fourier transform or the elements of a
>> matrix to be inverted. Is there a proof that keeping the data in
>> arrays and using shallow stacks is just as fast as some scheme
>> for putting all the data on one or more deep stacks?
I'm sure it doesn't matter for Forths that apply some amount
of optimization. On the other hand, it may matter on which
CPU one runs the resulting program. On a Pentium most of my FP
codes run fastest out of memory.
> On the other hand, how likely is it that a beginning Forther
> would be reading code having to do with Fourier transforms?
I consider this quite likely, especially if these beginning
Forthers are using iForth as their test vehicle :-)
-marcel
Julian V. Noble
>
> Well Forth may already have a set of facilities to obsolete
> the problem features of other languages or operating systems.
> But there is one area where all those other programming systems
> beat Forth. That is in the education and training of new
> programmers. A good way to show the advantages of Forth is to
> use it teach new programmers before they can only think in terms
> of other languages. Why don't we do this? Why don't we even seem
> to worry much about why we don't do this?
I have just retired from many years of teaching physics at UVa. In the
mid-1990's I introduced a course in scientific programming (mainly numerical
analysis arising in physical problems). In that course I did everything I
could short of standing on my head and dancing upside-down to interest
my students in Forth. In particular, I did many real-time, in-class
examples of short programs, projected on a screen and with no safety
net. Many of the programs were completely extemporaneous, because they
dealt with problems suggested by the students.
Naturally I used Forth for this. (Having a FORmula TRANslator
made it a bit easier for the students to follow.) The colleague who
took over the course when I retired uses C for classroom illustrations
since that is what most of our students learn in the CS course. He is
expert in C. But nevertheless he never tries extemporaneous classroom
illustrations. It's just too hard in C to get a modest program running in
the available time.
In the seven years I taught the course I managed to get perhaps five students
to learn Forth. Students mostly don't want to bother unless they have a flair
for the eccentric.
Re: venue, few CS departments at universities will offer a Forth course,
because few of the decision makers in these departments know of or believe
in Forth. I have found no argument that can convince them even to try it.
When it comes to off-beat languages, MIT is, I think, unique in requiring
Scheme for beginning programmers. And I would be willing to bet that they
teach a lot of C nowadays.
Basically, you are seeing Gresham's Law in operation.
don groves
wrote...
...
> I have just retired from many years of teaching physics at UVa. In the
> mid-1990's I introduced a course in scientific programming (mainly numerical
> analysis arising in physical problems). In that course I did everything I
> could short of standing on my head and dancing upside-down to interest
> my students in Forth. In particular, I did many real-time, in-class
> examples of short programs, projected on a screen and with no safety
> net. Many of the programs were completely extemporaneous, because they
> dealt with problems suggested by the students.
>
> Naturally I used Forth for this. (Having a FORmula TRANslator
> made it a bit easier for the students to follow.) The colleague who
> took over the course when I retired uses C for classroom illustrations
> since that is what most of our students learn in the CS course. He is
> expert in C. But nevertheless he never tries extemporaneous classroom
> illustrations. It's just too hard in C to get a modest program running in
> the available time.
>
> In the seven years I taught the course I managed to get perhaps five students
> to learn Forth. Students mostly don't want to bother unless they have a flair
> for the eccentric.
My own take is that Forth does something to the mind of those
susceptible to it. A switch is thrown, and once thrown, it can
never be retracted; a thing of beauty and simplicity is seen that
once glimpsed, can never be entirely forgotten. I first read
about Forth in the mid-70s and since then, through 25+ years of
various languages (including only two Forth projects) I still am
invariably drawn back.
However, Forth susceptibility seems to be a scarce resource. We
can do what we can to expose Forth to as many as possible but we
can't control how many will be hooked. Obviously, part of the
reason is that infix is pounded into our heads from the time we
start arithmetic, so right away it takes an uncommon mind to
appreciate Forth.
I find it interesting that we use prefix and postfix commonly in
our speech and use infix primarily only when writing out problems
algebraically. A teacher may very well say, "Please add the
following numbers" (prefix) or, "There's a column of numbers on
the board, who wants to add them up" (postfix). Word problems are
another area where non-postfix thinking is common. But the habits
formed by doing lots of algebraic style homework problems are
hard to break for most.
--
dg
Jeff Fox
> Well Forth may already have a set of facilities to obsolete
> the problem features of other languages or operating systems.
> But there is one area where all those other programming systems
> beat Forth. That is in the education and training of new
> programmers.
Nonsense. We have a couple of posters who repeatedly point to
their own failure in this area and assume that everyone else
has failed in the same way. Forth has many examples of superior
education and training that are as good as anything else out
there or better.
I have recently been researching why some people seem to have
the impression that you have. It is one of those things that
puzzled me for many years.
> A good way to show the advantages of Forth is to
> use it teach new programmers before they can only think in terms
> of other languages.
Yes.
> Why don't we do this?
We? Who is this WE that you always ask about? Since it must
include you, let me ask, why don't you?
> Why don't we even seem to worry much about why we
> don't do this?
I don't know who your 'we' are, but people who do it don't have
to worry about it, or worry about why they don't do it.
> Keeping things simple so people can understand Forth
> listings is an excellent reason to use shallow stacks.
Yes.
> But does
> this lead to a less efficient method of programming?
No.
> Suppose you
> were dealing with an easily remembered set of data, such as
> points for a discrete Fourier transform or the elements of a
> matrix to be inverted.
Sure. I was looking at an example of this just recently. I
don't think the example supports you points.
> Is there a proof that keeping the data in
> arrays and using shallow stacks is just as fast as some scheme
> for putting all the data on one or more deep stacks?
Bizzare question. It really needs lots of context to mean anything.
How big is the array? How big are the stacks? In the contexts where
I work with Forth the question is nonsense. Deep stack access, you
mean ROT?
Without lots of context there can be no proof. For a give system,
problem and context there can be evidence. I have a problem
trying to picture doing a DFT on stack only, the question seems to
be outside of a sane Forth context.
Best Wishes
m-coughlin
> m-coughlin <m-cou...@comcast.net> wrote in message news:<413D24FA...@comcast.net>...
> > Well Forth may already have a set of facilities to
> > obsolete the problem features of other languages or
> > operating systems. But there is one area where all those
> > other programming systems beat Forth. That is in the
> > education and training of new programmers.
>
> Nonsense. We have a couple of posters who repeatedly point to
> their own failure in this area and assume that everyone else
> has failed in the same way. Forth has many examples of superior
> education and training that are as good as anything else out
> there or better.
>
> I have recently been researching why some people seem to have
> the impression that you have. It is one of those things that
> puzzled me for many years.
It a good thing that I brought this up. Let me inform you
that the use of Forth has declined over the past decades. I
believe you mentioned something about the fig chapters in
northern California having less attendance than years ago. This
a sign of trouble.
> > A good way to show the advantages of Forth is to
> > use it teach new programmers before they can only think in
> > terms of other languages.
>
> Yes.
>
> > Why don't we do this?
>
> We? Who is this WE that you always ask about? Since it must
> include you, let me ask, why don't you?
I do. I tell new owners of computers that if they want to
learn to program, Forth is the easiest language to learn. Then I
contradict myself by telling them they can't go to the bookstore
and buy a text book or find good examples to teach themselves.
Unless, of course, they are familiar enough with programming to
reverse engineer tricky code. When I speak about Forth with
programmers who do earn their living writing good code and
dealing with the other kind, they tell me they haven't written
any Forth code in twenty years and ask me if anybody still uses
it to write programs.
> > Why don't we even seem to worry much about why we
> > don't do this?
>
> I don't know who your 'we' are, but people who do it don't have
> to worry about it, or worry about why they don't do it.
You should get out more and talk to programmers who work in
different areas than you do.
m-coughlin
>
> m-coughlin <m-cou...@comcast.net> wrote in message news:<413D24FA...@comcast.net>...
[snip]
> > Keeping things simple so people can understand Forth
> > listings is an excellent reason to use shallow stacks.
>
> Yes.
>
> > But does
> > this lead to a less efficient method of programming?
>
> No.
>
> > Suppose you
> > were dealing with an easily remembered set of data, such as
> > points for a discrete Fourier transform or the elements of a
> > matrix to be inverted.
>
> Sure. I was looking at an example of this just recently. I
> don't think the example supports you points.
>
> > Is there a proof that keeping the data in
> > arrays and using shallow stacks is just as fast as some scheme
> > for putting all the data on one or more deep stacks?
> Bizzare question. It really needs lots of context to mean
> anything. How big is the array? How big are the stacks? In the
> contexts where I work with Forth the question is nonsense.
> Deep stack access, you mean ROT?
An array as big as possible. The ultimate limit I've heard
about is where numerical errors from not being able to do
arithmetic to unlimited precision cause the computation to
become unstable and generate random results.
> Without lots of context there can be no proof. For a given
> system, problem and context there can be evidence. I have a
> problem trying to picture doing a DFT on stack only, the
> question seems to be outside of a sane Forth context.
I guess this is a topic too specialized to be of interest to
you. Optimum connections and arrangement of memory is something
that gets a lot of attention in some places. I once read the
best configuration for a parallel processing network was a
hyper-cube since it would result in the fastest computation of
discrete Fourier transforms. Each processor in the network would
send its result to the next processor and receive exactly the
right data for its next step from another processor with no need
for a wait state or other delay. It might be like having a stack
arranged in a four dimensional geometry. Since things like that
intrigue me, I'm willing to ask if seemingly overly complicated
things like deep stacks in Forth might have some practical use
in certain situations.
m-coughlin
Here is a topic that should be of great interest and I wish
people who have taught Forth would have written more about it
over the years.
"Julian V. Noble" wrote:
>
> m-coughlin wrote:
> > Well Forth may already have a set of facilities to
> > obsolete the problem features of other languages or operating
> > systems. But there is one area where all those other
> > programming systems beat Forth. That is in the education
> > and training of new programmers. A good way to show the
> > advantages of Forth is to use it teach new programmers before
> > they can only think in terms of other languages. Why don't
> > we do this? Why don't we even seem to worry much about why
> > we don't do this?
>
> Well, one problem is students. The other is venue.
>
> I have just retired from many years of teaching physics at UVa.
> In the mid-1990's I introduced a course in scientific
> programming (mainly numerical analysis arising in physical
> problems). In that course I did everything I could short of
> standing on my head and dancing upside-down to interest
> my students in Forth. In particular, I did many real-time,
> in-class examples of short programs, projected on a screen
> and with no safety net. Many of the programs were completely
> extemporaneous, because they dealt with problems suggested by
> the students.
>
> Naturally I used Forth for this. (Having a FORmula TRANslator
> made it a bit easier for the students to follow.)
Well I don't see how having a FORmula TRANslator in Forth is
going to be of help to somebody unless they also know something
about Fortran. I would try to let Forth stand on its own and
show a student that Forth is a calculator that pushes its own buttons.
> The colleague
> who took over the course when I retired uses C for classroom
> illustrations since that is what most of our students learn in
> the CS course. He is expert in C. But nevertheless he never
> tries extemporaneous classroom illustrations. It's just too
> hard in C to get a modest program running in the available
> time.
The biggest mystery to me is why the advantages of Forth
don't lead to it being more widely used.
> In the seven years I taught the course I managed to get perhaps
> five students to learn Forth. Students mostly don't want to
> bother unless they have a flair for the eccentric.
I see a connection with programming in Forth and teaching
freshmen about group theory. When I first saw it, I thought
group theory was an interesting topic for eccentric
mathematicians. Imagine my surprise when I discovered years
later that it had an application in Physics. The difference
between Forth and group theory is that nobody has yet used Forth
to discover something new in Physics or make something old
clearer and easier to understand.
> Re: venue, few CS departments at universities will offer a
> Forth course, because few of the decision makers in these
> departments know of or believe in Forth. I have found no
> argument that can convince them even to try it. When it comes
> to off-beat languages, MIT is, I think, unique in requiring
> Scheme for beginning programmers. And I would be willing to
> bet that they teach a lot of C nowadays.
>
> Basically, you are seeing Gresham's Law in operation.
I don't see much of a connection with Gresham's Law, but you
are absolutely right about the teaching of C at MIT. They still
use Fortran as well as Lisp and Scheme, but C is more common.
Now why is C so popular with computer science departments? Its
because somebody used it to make computers do something of
interest. I first saw C and Forth at about the same time, when
they were both rare and only of academic interest. The C
programmers were busy writing systems that crashed less than the
things that were written in assembly, PL/I, and whatever, while
Forth programmers were working on astronomical instruments and
couldn't read their own code. There are many more programs
written in C that a student would want to understand than
programs written in Forth. What program written in Forth comes
to mind if you ask the question, "What should I suggest to a
student to study?"
I could write more about this, but I'll stop now and hope
I've done enough to get a thread going that will be as of much
interest as blocks vs. files and shallow vs. deep stacks.
Jeff Fox
> My own take is that Forth does something to the mind of those
> susceptible to it. A switch is thrown, and once thrown, it can
> never be retracted; a thing of beauty and simplicity is seen that
> once glimpsed, can never be entirely forgotten.
Descriptions like that are often seen as the bane of Forth. People
will tell you that you sound like religious fanatic, prostelizing
your religion instead of a programming language. People will say
that they don't see why one has to have a mystical experience
like that to undertand or appreciate a language. This is one
manifestation of what has traditionally been called the Forth curse.
I have recently come up with a theory about Forth and other
programming languages that explains the description of the above
experience in terms of known brain functionalit and theories about
learning and language. The theory fits with every example that
I have seen of a phenomona known as Forth hating which is often
almost a reflex reaction to statements like the ones above. That
is exactly what people hate most about Forth.
> I first read
> about Forth in the mid-70s and since then, through 25+ years of
> various languages (including only two Forth projects) I still am
> invariably drawn back.
>
> However, Forth susceptibility seems to be a scarce resource.
"Susecptibility" to learning is on the decline. Susceptibility to
learning Forth is an odd term, I suspect that the experience of a
teacher and the quality of the materials and examples used are big
factors although external to the learner themselves. But there is
a sort of pre-conditioning or pre-anti-conditioning that should be
taken into account on a student's susceptibility to learning.
> We
> can do what we can to expose Forth to as many as possible but we
> can't control how many will be hooked.
That seems more like conjecture than anything proven. For one thing
the term Forth means different things to different people. What interests
one person about Forth may not be what interests someone else.
> Obviously, part of the
> reason is that infix is pounded into our heads from the time we
> start arithmetic, so right away it takes an uncommon mind to
> appreciate Forth.
My theory says that you are close there. 'Pounding' arithmetic into
heads is not the source of the problem except that it is hard to learn
anything with someone pounding on your head. I think the problem is
more a matter of a tiny something being missing, understanding.
You are close because some other things get 'pounded' into people's
heads that do make it nearly impossible for them to learn certain
other things in the future. It is not a question of infix vs postfix
so much as rote vs understanding.
> I find it interesting that we use prefix and postfix commonly in
> our speech and use infix primarily only when writing out problems
> algebraically.
Yes, but the real problem there is that the way we read, write,
pronounce, and actually calculate algebraic expressions are so
different. It is a problem for teaching mathematical concepts
but I don't think it is really a big factor in Forth, at least
not nearly as big a mental factor as something else.
> A teacher may very well say, "Please add the
> following numbers" (prefix) or, "There's a column of numbers on
> the board, who wants to add them up" (postfix). Word problems are
> another area where non-postfix thinking is common.
Word problems are also another area whre non-prefix thinking is
common. Thinking, prefix or postfix? Perhaps the first and
primary natural language that a person learns strongly influences
aspects of their thinking. Understanding of mathematics and logic
will influence thinking too but the terms prefix and postfix really
have little meaning when refering to thought.
> But the habits
> formed by doing lots of algebraic style homework problems are
> hard to break for most.
Habits is the issue, algebraic style homework habits is not the
problem. But it is close in that it refers to a style of
thinking involved in a style of problem solving. The fact that
it becomes a habit is the issue.
Habits cannot be broken. Habits can be replaced. Neural nets
get reinforced by repeated use, they become stronger and influence
more things. Nets that get used less, or that are replaced by
more effective nets become weaker and have less influence over
other things.
When people see skills for B as being in such conflict with skills
for A they often think that they will have lose all skills to do
A to be able to do B. They are likely to value their skills to do
A, they are those skills, they are unlikely to wish to give them
up on the chance that B skills will be of more value.
In fact people who learn B may stop doing A once they gain the
ability to choose to do either A or B. They may be willing to
give up on doing A if they know from experience that B has
greater value to them.
Some of it is what you are taught, some of it is when you are
taught it. I think the issue has to do with nature of our
educational system and the human brain.
Best Wishes
don groves
f...@ultratechnology.com wrote...
> don groves <no-...@nowhere.not> wrote in message news:<MPG.1ba7b87cb...@news.web-ster.com>...
> > My own take is that Forth does something to the mind of those
> > susceptible to it. A switch is thrown, and once thrown, it can
> > never be retracted; a thing of beauty and simplicity is seen that
> > once glimpsed, can never be entirely forgotten.
>
> Descriptions like that are often seen as the bane of Forth. People
> will tell you that you sound like religious fanatic, prostelizing
> your religion instead of a programming language. People will say
> that they don't see why one has to have a mystical experience
> like that to undertand or appreciate a language. This is one
> manifestation of what has traditionally been called the Forth curse.
In my experience, hating Forth is not based on hearing mystical
descriptions but rather on it being so different from what the
individual is used to. I've worked with very intelligent
programmers who dislike Forth intensely strictly because of its
syntax, not what someone has evangelized to them about it.
> > However, Forth susceptibility seems to be a scarce resource.
>
> "Susecptibility" to learning is on the decline. Susceptibility to
> learning Forth is an odd term, I suspect that the experience of a
> teacher and the quality of the materials and examples used are big
> factors although external to the learner themselves. But there is
> a sort of pre-conditioning or pre-anti-conditioning that should be
> taken into account on a student's susceptibility to learning.
I wasn't referring to susceptibility to "learning" Forth, I was
referring to susceptibility to "wanting" to learn it. I was
referring to grokking Forth at first exposure, like what happened
to me, just getting it, it just feels right. I didn't learn it in
much depth until a few years later, on my first Forth project,
but I was already hooked.
...
If they can find enough work to support themselves doing B, then
that is likely, but when 95% or more of the available work is
doing A, well, you know the result.
But here again, the person has to want to make the effort, she
has to be motivated by some desire, some spark, to modify old
habits. Most people educated in our system and already exposed
to C++ or whatever, don't seem to feel that spark when confronted
with Forth. My feeling is that it looks and feels too alien and
while postfix, as you say, is only part of the problem, given the
many comments I've heard from co-workers, it's a big part.
They're used to the compiler doing that sort of thing for them
and don't want to give up what's comfortable.
This is why I use the examples above of where we use postfix
often in our speech patterns, it really isn't all that alien when
you think about it. Kitchen recipes are another example, most
often giving a list of ingredients and then saying what to do
with them.
We need to find a way to introduce Forth in the 3rd or 4th grade.
Given how kids that age take to Logo, it would be good for all
concerned.
Interesting concepts.
Best regards,
dg
Jeff Fox
> It a good thing that I brought this up. Let me inform you
> that the use of Forth has declined over the past decades. I
Let me ask you, are you talking about a decline in quantity,
quality, or percentage of some language pie?
> I believe you mentioned something about the fig chapters in
> northern California having less attendance than years ago. This
> a sign of trouble.
Quantity is down.
> > > Why don't we do this?
> >
> > We? Who is this WE that you always ask about? Since it must
> > include you, let me ask, why don't you?
>
> I do.
Then why do you repeatedly ask "Why don't we do this?"
I don't quite get your point. You say at 'we' don't teach
Forth and ask why. I ask who this 'we' are as it must be
you and someone else. But now you say that you do it.
I guess your original question should have been "I do this but
why don't you?" (When you said 'we' you meant people other than
you.)
> I tell new owners of computers that if they want to
> learn to program, Forth is the easiest language to learn.
That's a good start, that's a grabber, a teaser, a lead in
to get their attention. Unless of course you are just jerking
their chain and teasing them with something that you don't
intend to deliver.
> Then I
> contradict myself by telling them they can't go to the bookstore
> and buy a text book or find good examples to teach themselves.
Sorry, you lost me. You tell em Forth is easiest language to learn,
and that they can't teach it to themselves easily by picking one
of many good textbooks at the bookstore. Ok. There are lots and
lots of things that can't be learned easily by someone teaching
themselves from a random choice of textbooks. If there were not so
many things that required teaching with teachers we would not need
places like Universities. I don't see the contradition.
I expect that then you pull out your private supply of textbooks
with tutorial notes and prove your point. Or were you just
torturing those poor folks with intentionally false promisses?
> Unless, of course, they are familiar enough with programming to
> reverse engineer tricky code.
Yikes? Now you are certainly just trying to be silly with over
the top hyperbole. Certainly no one would suggest that easiest
way to learn the easiest to learn language would be to reverse
engineer some secret tricky code. That's a good one. ;-)
> When I speak about Forth with
> programmers who do earn their living writing good code and
(For readers not familiar with Michael's point of view, substitute
the phrase 'non-forth code' for 'good code' in the above. As he
defines good code as non-Forth code it gets pretty hard to
discuss Forth with Mike. I pity the poor folks who hear about
Forth from Mike.)
> dealing with the other kind, they tell me they haven't written
> any Forth code in twenty years and ask me if anybody still uses
> it to write programs.
Yes. We know. Forth haters often say that they did Forth 20
years ago, but now do modern programming in something else.
They jokingly ask if anybody still uses such an antique language.
Yes. We know. There are more of these people out there than
there are people using Forth. To these folks Forth programmers
are non-people. And after all folks like Mike will tell them
about Forth and agree that there is good code and then there
is Forth...
Oh, yes, I forgot, Mike is also likely to tell them Forth
programmers are geneitically incapable of writing documentation.
(Another favorite myth promoted by Forth haters. ;-)
> > > Why don't we even seem to worry much about why we
> > > don't do this?
> >
> > I don't know who your 'we' are, but people who do it don't have
> > to worry about it, or worry about why they don't do it.
>
> You should get out more and talk to programmers who work in
> different areas than you do.
I am very happy to deal with Forth, and deal with programmers who
want to learn Forth, do, and are very happy with the result. If
I want to know about JAVA I ask programmers who use it, if I want
to know about C++ I ask programmers who use it.
You are suggesting that if I get out and ask these JAVA or C++
programmers about Forth that I will learn that they don't know
much about it. I know that they don't. I don't need to ask.
I maintain that those who want to get good training get it and
that those who don't don't. Anyone who seriously wants to learn
Forth can. Anyone who doesn't give a damn won't.
You maintain that since you agree with those programmers that Forth
is virtually dead and question if anyone still uses it and tell them
that you personally can't teach them Forth (the best you can to is
to tell them that they could teach themselves if they had the right
textbooks) that 'we' (meaning people other than you) are failing
to teach Forth. Replace 'we' with yourself and your arguement is
a good example of self-fufilling prophecy. You can't teach Forth
so you can't teach Forth, you can't write documentation so you
can't write documenation.
Now if you could just learn to stop jerking people's chains and
pretending to promote Forth while simply promoting the myths and
negative stereotypes that you already find common in the programmers
that you know who write 'good code' (ie. non-Forth code.)
Best Wishes
Jeff Fox
> > > Is there a proof that keeping the data in
> > > arrays and using shallow stacks is just as fast as some scheme
> > > for putting all the data on one or more deep stacks?
>
> > Bizzare question. It really needs lots of context to mean
> > anything. How big is the array? How big are the stacks? In the
> > contexts where I work with Forth the question is nonsense.
> > Deep stack access, you mean ROT?
>
> An array as big as possible. The ultimate limit I've heard
> about is where numerical errors from not being able to do
> arithmetic to unlimited precision cause the computation to
> become unstable and generate random results.
Would you not expect addressable memory in a system to have more
cells than the paramter stack? Which should hold this 'as big
as possible' thing?
> > Without lots of context there can be no proof. For a given
> > system, problem and context there can be evidence. I have a
> > problem trying to picture doing a DFT on stack only, the
> > question seems to be outside of a sane Forth context.
>
> I guess this is a topic too specialized to be of interest to
> you.
No. The topic of what should be in memory and what should be
on the stacks for well written Forth interest me. The topic
of a DFT example interests me, and doubly so in the context
of what should be on the stacks and what should be in memory.
I just think that your example of a DFT as something where
any sane person would keep all data on the parameter stack
betrays a total lack of understand of Forth and of problems
like a DFT. It interests me a little just because it looks
like you have said another incredibly dumb thing and are now
going to try to change the subject.
Can you provide some DFT stack-only code vs DFT in memory code
so that we can see why you asked the question in the first
place. The topic is specialized, but it interests me, really.
> Optimum connections and arrangement of memory is something
> that gets a lot of attention in some places.
Er. Yeah, DFT stack-only vs DFT in memory was the subject.
Yes, the best arrangement of memory, cache, registers, stacks,
etc. is something that gets lots of attention.
> I once read the
> best configuration for a parallel processing network was a
> hyper-cube since it would result in the fastest computation of
> discrete Fourier transforms. Each processor in the network would
> send its result to the next processor and receive exactly the
> right data for its next step from another processor with no need
> for a wait state or other delay.
Ok. I have read a lot of things too. And worked out comparisons
for hardware and software architectural variations.
> It might be like having a stack
> arranged in a four dimensional geometry. Since things like that
> intrigue me, I'm willing to ask if seemingly overly complicated
> things like deep stacks in Forth might have some practical use
> in certain situations.
It might be like angels dancing on the head of a pin. But you
win an award for the quickest retreat into hyper-space.
Best Wishes
Jeff Fox
> The biggest mystery to me is why the advantages of Forth
> don't lead to it being more widely used.
For years it was a mystery to me too. I wondered why there was
not just a lack of acceptance but a strong and open hostility
from many camps. The idea that Forth is a superbly disruptive
technology could only explain so much. Forth's preference for
productivity and performance seem at first glance to be strong
factors to promote Forth and offset the negative aspects of
the disruptive alternative methods used in Forth.
I thought for years that perhaps it was an issue of fear. Was
Forth so disruptive that people just feared and hated the idea
that perhaps it could be as productive as many of its users claimed?
(I recalled that the first time Chuck talked about F21 publicly
that I worried that he would say something negative about C or
Intel's chips and put people off. I was pleased that he never
mentioned C or Intel's chips. But some guy in the back said that
he 'hated' Chuck's presentation because he heard Chuck say that
he was an idiot for using C. A good example of someone's fear
that what Chuck said about his work and Forth was true.)
> The difference
> between Forth and group theory is that nobody has yet used Forth
> to discover something new in Physics or make something old
> clearer and easier to understand.
Sorry, we don't agree about that. Forth is different than group
theory, but not for those reasons.
> Now why is C so popular with computer science departments?
Now that's really the million dollar question isn't it?
> Its
> because somebody used it to make computers do something of
> interest.
Self-referential statement. C wrote Unix, Unix hosted C,
isn't that interesting?
When taught it becomes intersting because it is being taught.
I am afraid that you are substituting a self-referential
circular definition as the answer to the above question.
I think the real answer is very intersting.
> I first saw C and Forth at about the same time, when
> they were both rare and only of academic interest. The C
> programmers were busy writing systems that crashed less than the
> things that were written in assembly, PL/I, and whatever, while
> Forth programmers were working on astronomical instruments and
> couldn't read their own code.
Troll. Typical Forth hater myth. Sure some Forth programmers
couldn't read their own code. We have a couple of people in C.L.F
who proclaim that they were unable to teach people to write Forth
code that they or others could read. I guess if they learned to
write Forth code themselves they never learned to teach the skill
to others. So they tell us that their students never learned Forth
well, duh.
> There are many more programs written in C
Yes, Yes. There is more C than Forth. Forth is not the average code.
> that a student would want to understand than programs written in Forth.
Since there are vastly more C programs there are probably more that
people 'want to understand.' But again this is getting at the real
million dollar question. What makes them want to learn and understand
one program but not another?
No one has discovered a gene that they can say causes people to
'want' to learn C and 'not want' to learn Forth. They will learn
about C and why they should want to learn it. They are likely to
learn little if anything about Forth so are unlikely to have any
interest.
The arguement that there is more C because there is more C does
not address the issue of why some people want something else.
Perhaps the question should be why are most people average or
why more people are not interested in exploration and leadership.
When you find the answer to those questions it is pretty obvious
why Forth has a small niche.
> What program written in Forth comes
> to mind if you ask the question, "What should I suggest to a
> student to study?"
Student of what? What student? What is their background? What
do they want to learn about Forth?
(What is the one textbook that one should read to learn medicine?)
(What if they haven't learned to read yet?)
> I could write more about this, but I'll stop now and hope
> I've done enough to get a thread going that will be as of much
> interest as blocks vs. files and shallow vs. deep stacks.
blocks vs files
shallow vs deep stack
and
C textbooks vs Forth textbooks
are all just troll threads that subvert any postive progress
in Forth. Those are all topics where there is little but negative
mudslinging and attacks that demean Forth and those who use it.
They contribute virtually nothing to anyone's better
understanding of Forth, just the opposite in fact.
Best Wishes
m-coughlin
>
> m-coughlin <m-cou...@comcast.net> wrote in message news:<413E5BF3...@comcast.net>...
> > > > Is there a proof that keeping the data in
> > > > arrays and using shallow stacks is just as fast as some
> > > > scheme for putting all the data on one or more deep
> > > > stacks?
> >
> > > Bizzare question. It really needs lots of context to mean
> > > anything. How big is the array? How big are the stacks? In
> > > the contexts where I work with Forth the question is
> > > nonsense. Deep stack access, you mean ROT?
> >
> > An array as big as possible. The ultimate limit I've heard
> > about is where numerical errors from not being able to do
> > arithmetic to unlimited precision cause the computation to
> > become unstable and generate random results.
>
> Would you not expect addressable memory in a system to have more
> cells than the paramter stack? Which should hold this 'as big
> as possible' thing?
Apologies to everyone on comp.lang.forth for luring Jeff Fox
into pointless discussions. But I see a glimmer of hope that the
right questions could be asked and perhaps even answered.
If stacks are implemented in hardware then operations like
PICK are ugly and inefficient. A shallow stack is definitely
best. But if you emulate your stacks in software, storing the
data in RAM, then you can leap around the stack with ease. This
discussion of deep stacks seems to me to be mostly about this
difference. Shouldn't you be able to write more and better
algorithms if you can use all of the megabytes of RAM available
as a giant stack instead of restricting yourself to the small
amount of memory you have on a hardware stack on the CPU chip?
Or will the speed difference between on-processor and
off-processor memory always make a large stack impractical? What
is the situation if the stack data can be stored in cache RAM?
How does the situation change with different methods of
threading and the various machine instructions of different
processors?
> > > Without lots of context there can be no proof. For a given
> > > system, problem and context there can be evidence. I have a
> > > problem trying to picture doing a DFT on stack only, the
> > > question seems to be outside of a sane Forth context.
> >
> > I guess this is a topic too specialized to be of interest
> > to you.
>
> No. The topic of what should be in memory and what should be
> on the stacks for well written Forth interest me. The topic
> of a DFT example interests me, and doubly so in the context
> of what should be on the stacks and what should be in memory.
>
> I just think that your example of a DFT as something where
> any sane person would keep all data on the parameter stack
> betrays a total lack of understand of Forth and of problems
> like a DFT. It interests me a little just because it looks
> like you have said another incredibly dumb thing and are now
> going to try to change the subject.
Good idea. I'm glad you suggested it. A discrete Fourier
transform is not the right example to use.
> Can you provide some DFT stack-only code vs DFT in memory code
> so that we can see why you asked the question in the first
> place. The topic is specialized, but it interests me, really.
>
> > Optimum connections and arrangement of memory is something
> > that gets a lot of attention in some places.
>
> Er. Yeah, DFT stack-only vs DFT in memory was the subject.
> Yes, the best arrangement of memory, cache, registers, stacks,
> etc. is something that gets lots of attention.
> > I once read the
> > best configuration for a parallel processing network was a
> > hyper-cube since it would result in the fastest computation of
> > discrete Fourier transforms. Each processor in the network
> > would send its result to the next processor and receive
> > exactly the right data for its next step from another
> > processor with no need for a wait state or other delay.
>
> Ok. I have read a lot of things too. And worked out comparisons
> for hardware and software architectural variations.
What references would you recommend for further study of the
situation? Now I might not actually get around to reading or
studying such things, but I think there would be other people
who are interested in the topic and would like to be as well
informed as possible.
> > It might be like having a stack
> > arranged in a four dimensional geometry. Since things like
> > that intrigue me, I'm willing to ask if seemingly overly
> > complicated things like deep stacks in Forth might have some
> > practical use in certain situations.
>
> It might be like angels dancing on the head of a pin. But you
> win an award for the quickest retreat into hyper-space.
Learning to use unconventional ideas like Forth frees my
mind from narrow thinking.
Brad Eckert
>
> I do. I tell new owners of computers that if they want to
> learn to program, Forth is the easiest language to learn. Then I
> contradict myself by telling them they can't go to the bookstore
> and buy a text book or find good examples to teach themselves.
> Unless, of course, they are familiar enough with programming to
> reverse engineer tricky code. When I speak about Forth with
> programmers who do earn their living writing good code and
> dealing with the other kind, they tell me they haven't written
> any Forth code in twenty years and ask me if anybody still uses
> it to write programs.
>
real problem: fitting the most features in the smallest program space.
Okay, you already know that.
Maybe we are looking at Forth the wrong way. If Forth is a language
you use to tell a computer what to do, there are lots of languages
that do that just fine. What Forth is good for is abstracting
problems.
Many Forthers (especially ANS Forthers) concentrate on C style
portability. Portability is not the problem, appropriate use of
abstraction is the problem. Perhaps Forth should be taught as an
interactive abstraction tool, not as a programming language. After
all, there are plenty of programming languages.
I think this is an easier way to "sell" Forth, instead of competing
head to head.
Brad
John Doty
> Apologies to everyone on comp.lang.forth for luring Jeff Fox
> into pointless discussions.
Nah, Jeff's an interesting character. Just switch in about 20 dB of
attenuation before reading his stuff, and it'll all make sense :-)
> If stacks are implemented in hardware then operations like
> PICK are ugly and inefficient. A shallow stack is definitely best. But
> if you emulate your stacks in software, storing the data in RAM, then
> you can leap around the stack with ease. This discussion of deep stacks
> seems to me to be mostly about this difference. Shouldn't you be able to
> write more and better algorithms if you can use all of the megabytes of
> RAM available as a giant stack instead of restricting yourself to the
> small amount of memory you have on a hardware stack on the CPU chip? Or
> will the speed difference between on-processor and off-processor memory
> always make a large stack impractical? What is the situation if the
> stack data can be stored in cache RAM? How does the situation change
> with different methods of threading and the various machine instructions
> of different processors?
For reasons of programmer sanity (and often implementation efficiency), it
is a really good idea to keep the number stack shallow. It seems to me
that if you want a deep stack, the Forthy way is to define an extra stack,
along with the words to access it in a way that's well suited to your
application. Algolish stack frames may be useful in some cases, but I
think it undesirable to put them on the number stack.
I once wrote a parser in LSE where I kept the token stack separate from
the number stack. Various words needed to inspect the current and/or
previous token, but putting them on the number stack would have caused
them to be buried under variable amounts of more volatile stuff. A
separate stack made it much easier to keep track of where they were.
-jpd
Bill Spight
My shop teacher stressed to us the importance of using the right tool
for the job. With that in mind, my question is, why use a stack as an
array? (OC, we know that we really use an array (RAM) for stacks and
other data structures. ;-))
> If stacks are implemented in hardware then operations like
> PICK are ugly and inefficient. A shallow stack is definitely
> best. But if you emulate your stacks in software, storing the
> data in RAM, then you can leap around the stack with ease.
Because it "really" is an array.
> This
> discussion of deep stacks seems to me to be mostly about this
> difference. Shouldn't you be able to write more and better
> algorithms if you can use all of the megabytes of RAM available
> as a giant stack instead of restricting yourself to the small
> amount of memory you have on a hardware stack on the CPU chip?
Why go to the trouble to treat it as a stack to start with, if we really
want to treat it as an array, "leaping around" in it? Doesn't that just
create potential for confusion?
Best regards,
Bill
Guy Macon
m-coughlin <m-cou...@comcast.net> says...
>If stacks are implemented in hardware then operations like
>PICK are ugly and inefficient. A shallow stack is definitely
>best. But if you emulate your stacks in software, storing the
>data in RAM, then you can leap around the stack with ease. This
>discussion of deep stacks seems to me to be mostly about this
>difference.
I see it as a matter of philosophy; many people think that deep
stacks are a sign that your overall design is too complex.
Creating an additional stack to hold those large amounts of
data is, in my opinion, a far cleaner solution.
Julian V. Noble
operators. The students who took my course had some programming
experience, by and large. (In 7 years I only had two who did not
know any programming language. One learned Forth from me. The other
learned C from her fellow students.) The languages they were
familiar with were Fortran, C and Basic. These all TRANslate FORmulas.
Th point is, it is much clearer to someone who has just had a Runge-
Kutta algorithm explained on the blackboard to understand it as
a sequence of formulas a la Fortran than as a RPN-decomposed string
of Forth. I mean, which is easier to read,
f" k1 = h*fdummy(x+[a10]*k0,t+[c1]*h)"
or
h F@ x F@ a10 k0 F@ F* F+ t F@ c1 h F@ F* F+ fdummy F* k1 F!
?
(Note I am now using ftran202.f, in which [a10] means "treat a10 as an
FVALUE or FCONSTANT" i.e. omit the F@ that accompanies an FVARIABLE
such as h or k0 .)
Elizabeth D Rather
> Keeping things simple so people can understand Forth
> listings is an excellent reason to use shallow stacks. But does
> this lead to a less efficient method of programming? Suppose you
> were dealing with an easily remembered set of data, such as
> points for a discrete Fourier transform or the elements of a
> matrix to be inverted. Is there a proof that keeping the data in
> arrays and using shallow stacks is just as fast as some scheme
> for putting all the data on one or more deep stacks?
The main argument is that archecturally arrays are *designed* to keep
sequences of data, and stacks are *designed* to pass parameters (such as the
address and length of an array to be processed). And on most processors
(actually, all that I'm aware of ) there are few hardware stacks, and
potentially many arrays. Having worked on many applications involving
Fourier and other transforms, images being processed, and databases being
managed, I am quite comfortable asserting that keeping data in arrays in
memory or disk and passing simple parameters on the stack is better both in
terms of programming time as well as execution time.
Bill Spight
> The point is, it is much clearer to someone who has just had a Runge-
> Kutta algorithm explained on the blackboard to understand it as
> a sequence of formulas a la Fortran than as a RPN-decomposed string
> of Forth. I mean, which is easier to read,
>
> f" k1 = h*fdummy(x+[a10]*k0,t+[c1]*h)"
>
> or
>
> h F@ x F@ a10 k0 F@ F* F+ t F@ c1 h F@ F* F+ fdummy F* k1 F!
>
How much of resistance to Forth has to do with unfamiliarity with RPN?
(What about Japanese speakers? The typical sentence structure of
Japanese is Topic, Subject, Object, Verb. They also use postpositions
instead of prepositions.)
But there is more to it. Let's try an intermediate RPN version:
h [ci] * t + k0 [a10] * x + fdummy h * k1 =
The virtue of RPN is that you can eliminate parentheses. The problem
with RPN is that you eliminate parentheses. ;-)
In the original the parentheses and comma tell us that fdummy is a
binary function. This information is missing in the RPN versions. You
have to know about fdummy to read those versions. The quotation marks
serve as parentheses in the original. I am guessing that f" A = B"
translates to A B =. If not, I goofed. Anyway, f"..." seems to have
disappeared in the Forth version. Whatever information it provided must
be inferred. (Also, equality has been replaced by assignment, with a
slight change in meaning.)
Using parentheses and commas improves readability, doesn't it?
((h [ci] * t +, k0 [a10] * x +)fdummy h *, k1)=
Vive redundancy! ;-)
Best regards,
Bill
Jerry Avins
> Dear Julian,
>
>
>>The point is, it is much clearer to someone who has just had a Runge-
>>Kutta algorithm explained on the blackboard to understand it as
>>a sequence of formulas a la Fortran than as a RPN-decomposed string
>>of Forth. I mean, which is easier to read,
>>
>> f" k1 = h*fdummy(x+[a10]*k0,t+[c1]*h)"
>>
>>or
>>
>> h F@ x F@ a10 k0 F@ F* F+ t F@ c1 h F@ F* F+ fdummy F* k1 F!
>>
>
>
> How much of resistance to Forth has to do with unfamiliarity with RPN?
> (What about Japanese speakers? The typical sentence structure of
> Japanese is Topic, Subject, Object, Verb. They also use postpositions
> instead of prepositions.)
>
> But there is more to it. Let's try an intermediate RPN version:
>
> h [ci] * t + k0 [a10] * x + fdummy h * k1 =
>
> The virtue of RPN is that you can eliminate parentheses. The problem
> with RPN is that you eliminate parentheses. ;-)
In Forth, one replaces parenthesis marks with suitable factoring. Show
me a snippet that's clarified by parentheses, and you've a good
candidate for a descriptive word to replace it all.
>
> In the original the parentheses and comma tell us that fdummy is a
> binary function. This information is missing in the RPN versions.
Forth words are no more typed than Forth variables. In the phrase
standard > IF
"standard" can be a constant or a function that returns a reference
value (or neither). The program can start out one way and evolve to the
other without changing anything but standard's definition.
It's not hard for me to imagine that Forth isn't a good fit to the way
you've become accustomed to thinking. If that's a fault, whose is it?
> You have to know about fdummy to read those versions. The quotation marks
> serve as parentheses in the original. I am guessing that f" A = B"
> translates to A B =. If not, I goofed. Anyway, f"..." seems to have
> disappeared in the Forth version. Whatever information it provided must
> be inferred. (Also, equality has been replaced by assignment, with a
> slight change in meaning.)
>
> Using parentheses and commas improves readability, doesn't it?
See above. (So does requiring whitespace as a delimiter.)
> ((h [ci] * t +, k0 [a10] * x +)fdummy h *, k1)=
>
> Vive redundancy! ;-)
What does the symbol "k1)=" represent?
>
> Best regards,
>
> Bill
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Elizabeth D Rather
...
> > We? Who is this WE that you always ask about? Since it must
> > include you, let me ask, why don't you?
>
> I do. I tell new owners of computers that if they want to
> learn to program, Forth is the easiest language to learn. Then I
> contradict myself by telling them they can't go to the bookstore
> and buy a text book or find good examples to teach themselves.
Poor dears, no internet access? Have to actually go to a store? Clearly
unequipped to deal with anything as sophisticated as Forth.
Of course, if they do have internet access, they can just go to
www.forth.com where we have two books for sale that are great for learners.
Jeff Fox
> Apologies to everyone on comp.lang.forth for luring Jeff Fox
> into pointless discussions. But I see a glimmer of hope that the
> right questions could be asked and perhaps even answered.
>
> If stacks are implemented in hardware then operations like
> PICK are ugly and inefficient.
Stacks will be hardware or hardware/software. Hardware will always
be needed. PICK is an ugly and inefficient idea no matter how
efficiently one makes the hardware do it.
You can hold one item, no juggling needed. If you have two hands
you can hold two items, no juggling needed. If you only have two
hands and need to juggle three items a little practice is needed.
No amount of practice will allow you to juggle a variable number
of items where the number gets big.
People cannot juggle an arbitrarily large of items in their
minds at one time without dropping some. It is an issue of
the limitations of the minds of programmers.
To confuse the considered design of efficient and useful
hardware to be the reason why somethings that are just bad
are considered bad is a terrible mistake. It is a disservice
to others to simply state these after-this-therefore-because-
of-this arguments as facts.
> A shallow stack is definitely best.
Everyone agrees, but the term shallow is so fuzzy. To some it
means less than ...K to some it means less than ... items or ..
or . items. Everyone agrees 'deep stack access' is just a
bad idea. The term deep is also fuzzy and related to what
someone considers shallow.
> But if you emulate your stacks in software, storing the
> data in RAM, then you can leap around the stack with ease.
A program can, but a human mind can't. I have heard stories about
things like 987654 PICK and whether the software layer to do it
was efficient or not was never the issue. It is just a flawed idea.
> This
> discussion of deep stacks seems to me to be mostly about this
> difference.
No. Just the opposite.
> Shouldn't you be able to write more and better
> algorithms if you can use all of the megabytes of RAM available
> as a giant stack
No. No. No. How many people can visualise megabytes of stack
items and keep that image in their head while programming? Virtually
none. It is a bad idea. Megabytes of memory is fine, I had several
megabytes available even on F21 where programs are really tiny. But
needing megabyteish stacks is very rare. There may be some recursive
algorithms that when dealing with huge datasets might need a huge
return stack. But you are not going to index deep into it the
way one might be tempted to do with 'deep access' to a parameter
stack.
> instead of restricting yourself to the small
> amount of memory you have on a hardware stack on the CPU chip?
It is not an either-or situation. It is simply a good-bad question
because you just can't picture or juggle mega items in your head.
> Or will the speed difference between on-processor and
> off-processor memory always make a large stack impractical?
In the case of F21 stack memory was on-processor while main
memory was not. This meant that stack access tended to be
about 100 times faster than to variables or items in extended
stacks in memory.
With other processors stack memory may be on-processor along
with main memory. Stack memory is still likely to be faster
and mostly for the reason that it is smaller than main memory.
Main memory is for holding things like arrays, stacks are
for passing parameters.
These are the most basic ideas involved in writing code in
Forth. I have a hard time understanding how anyone who claims
to have any real experience with Forth could be so confused
about such basic ideas. Deep stack access is impractical
because of the human mind, it is just a bad idea. It is
very bad idea to bring that idea into Forth. Forth will
amplify such a bad idea very nicely.
> What
> is the situation if the stack data can be stored in cache RAM?
That is a typical situation on processors that have cached RAM.
Many implemenations today move what the code designated as stack
parameters around in registers. Many processors will cache the
RAM used for stacks in RAM. None of that has anything to do
with the fact that deep stack access in a Forth context is a
flawed idea.
> How does the situation change with different methods of
> threading and the various machine instructions of different
> processors?
It doesn't really. There are a few exceptions if you look
hard enough, but generally everyone agrees that stack access
should be kept shallow and that deep stack access should
be avoided because it is bad.
> Learning to use unconventional ideas like Forth frees my
> mind from narrow thinking.
Do you have a permit to let that thing wander free?
Best Wishes
Brad Eckert
>
> The point is, it is much clearer to someone who has just had a Runge-
> Kutta algorithm explained on the blackboard to understand it as
> a sequence of formulas a la Fortran than as a RPN-decomposed string
> of Forth. I mean, which is easier to read,
>
> f" k1 = h*fdummy(x+[a10]*k0,t+[c1]*h)"
>
> or
>
> h F@ x F@ a10 k0 F@ F* F+ t F@ c1 h F@ F* F+ fdummy F* k1 F!
>
> ?
I think I can turn my brain back 15 years to Physics class. I'll have
to use a simple example. Acceleration is the second derivative of
position wrt time. The kids who didn't know calculus were given magic
formulas to work the problems. If you integrate acceleration (in one
dimension) twice you get:
x(t) = x0 + v0*t + 0.5*a*t^2
Physics has lots of these kinds of formulas, which are derived and
then expressed so that you can plug in numbers and get an answer.
Although this produces real world results (what physicists are paid
for), it might not be the best way for students to understand the
underlying physics. In the above example, you have three terms that
contribute to x(t).
x(t) = initial + travel + fall
The name of the acceleration term requires you to imagine falling
sideways, but you get the picture. This kind of named factoring makes
sense for other formulas. For example, the term that determines
whether a system is under/over/critically damped has a name. The
determinant?
But I think that
: final ( time -- ) initial travel + fall + ;
is easier to read and remember than
final := x0 + v0*t + 0.5*a*t^2;
even though it isn't calculator friendly.
I would like to see a non-trivial derivation that makes use of
factoring. Especially factoring as a means of abstraction. But maybe
picking good names would be a problem. Anyone want to give it a try?
Brad
Bernd Paysan
> Poor dears, no internet access? Have to actually go to a store? Clearly
> unequipped to deal with anything as sophisticated as Forth.
>
> Of course, if they do have internet access, they can just go to
> www.forth.com where we have two books for sale that are great for
> learners.
And they can download various Forths (trial versions and free ones), which
come with screen-readable/print-yourself books. Including, but not limited
to the one on www.forth.com.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Bill Spight
Thanks for your response. :-)
Julian Noble:
> >>The point is, it is much clearer to someone who has just had a Runge-
> >>Kutta algorithm explained on the blackboard to understand it as
> >>a sequence of formulas a la Fortran than as a RPN-decomposed string
> >>of Forth. I mean, which is easier to read,
> >>
> >> f" k1 = h*fdummy(x+[a10]*k0,t+[c1]*h)"
> >>
> >>or
> >>
> >> h F@ x F@ a10 k0 F@ F* F+ t F@ c1 h F@ F* F+ fdummy F* k1 F!
> >>
Bill:
> > How much of resistance to Forth has to do with unfamiliarity with RPN?
> > (What about Japanese speakers? The typical sentence structure of
> > Japanese is Topic, Subject, Object, Verb. They also use postpositions
> > instead of prepositions.)
> >
> > But there is more to it. Let's try an intermediate RPN version:
> >
> > h [ci] * t + k0 [a10] * x + fdummy h * k1 =
> >
> > The virtue of RPN is that you can eliminate parentheses. The problem
> > with RPN is that you eliminate parentheses. ;-)
Jerry Avins:
> In Forth, one replaces parenthesis marks with suitable factoring. Show
> me a snippet that's clarified by parentheses, and you've a good
> candidate for a descriptive word to replace it all.
Bill:
> > In the original the parentheses and comma tell us that fdummy is a
> > binary function. This information is missing in the RPN versions.
Jerry:
> Forth words are no more typed than Forth variables. In the phrase
> standard > IF
> "standard" can be a constant or a function that returns a reference
> value (or neither). The program can start out one way and evolve to the
> other without changing anything but standard's definition.
>
> It's not hard for me to imagine that Forth isn't a good fit to the way
> you've become accustomed to thinking. If that's a fault, whose is it?
>
It seemed to me that Julian was saying that poor readability in RPN was
a major factor keeping students away from Forth. I suspect that lack of
familiarity with RPN is part of that, and I think that he would agree.
OC, you also have to know some Forth words, such as F@, but that's true
for any language you learn, so I suppose that he was assuming that the
reader knew those words, and still had trouble reading the Forth code.
RPN is like an SOV (Subject-Object-Verb) natural language, as arguments
precede their predicates or functors and operands precede their
operators. There is nothing inherently difficult about thinking in RPN.
Lack of familiarity is the main obstacle, I believe. So Julian's "which
is easier to read" depends mainly upon the question of familiarity.
However, in his specific example, there is a loss of information in the
translation. From fdummy(... , ...) we can infer that fdummy is a
function that takes two values and yields another, even if we do not
know its definition. We do not have that information in the Forth
version. All we know is that fdummy is a word. We do not know that it is
going to consume the top two items on the stack and put another on
there. That information is lost.
My comment was merely about the loss of information, not about types.
The loss of information reduces readability.
Bill:
> > You have to know about fdummy to read those versions. The quotation marks
> > serve as parentheses in the original. I am guessing that f" A = B"
> > translates to A B =. If not, I goofed. Anyway, f"..." seems to have
> > disappeared in the Forth version. Whatever information it provided must
> > be inferred. (Also, equality has been replaced by assignment, with a
> > slight change in meaning.)
> >
> > Using parentheses and commas improves readability, doesn't it?
Jerry:
> See above. (So does requiring whitespace as a delimiter.)
Bill:
> > ((h [ci] * t +, k0 [a10] * x +)fdummy h *, k1)=
> >
> > Vive redundancy! ;-)
Bill:
> What does the symbol "k1)=" represent?
k1 is a variable, ) is an ending parenthesis, and = is an equal sign.
Here is what I was doing.
Infix notation:
A = B
Polish notation:
= A B
Predicate:
=(A, B)
The predicate form looks like the Polish notation with the addition of
parentheses and comma.
Reverse Polish notation:
A B =
RPN style predicate:
(A, B)=
I just formed a predicate from the RPN notation in the same fashion as
forming a predicate from the Polish notation.
Best regards,
Bill
JosefG
> Jeff Fox wrote:
>
> > m-coughlin <m-cou...@comcast.net> wrote in message news:<413D24FA...@comcast.net>...
>
> I do. I tell new owners of computers that if they want to
> learn to program, Forth is the easiest language to learn. Then I
> contradict myself by telling them they can't go to the bookstore
> and buy a text book or find good examples to teach themselves.
> Unless, of course, they are familiar enough with programming to
> reverse engineer tricky code.
I've really been trying to learn FORTH for the past couple of years
(yeah I know I'm slow). My college has me taking C++ for engineering
students. I can't stand it. Declare what type of number I'm working
with? I can't print that? Why do we have so many variables?
C++ seems so clunky. I feel like I'm looking for a function that
my problem fitts. With FORTH, I look at the problem factor it and
program it.
I'll tell you what though, when I have a problem with C++ I can
just grab the book. With FORTH, it takes a while find the right help.
I have found some great FORTH documentation online, but every language
has great documentation online. It would be nice to have my choice
between a couple of FORTH books to check, besides the 1981 copy of
Starting FORTH the library has.
As Julian said, students are part of the problem. Most students
just want the grade. They really don't care about what they're
learning. They could care less a lot of the time. The only idea I have
involves scraping the current education system, but I don't think
that's going to happen anytime soon.
Josef
Elizabeth D Rather
news:7a4a41d2.04091...@posting.google.com...
Try one of these:
http://www.forth.com/catalog/index.php?cPath=22&osCsid=c97b48dd7fb107b0b2c76a352ead17fd.
Doug Hoffman
"Julian V. Noble" <j...@virginia.edu> wrote:
> m-coughlin wrote:
> >
[snip]
> > Well I don't see how having a FORmula TRANslator in Forth is
> > going to be of help to somebody unless they also know something
> > about Fortran. I would try to let Forth stand on its own and
> > show a student that Forth is a calculator that pushes its own buttons.
>
> Because most students are used to evaluating expressions with infix
> operators. The students who took my course had some programming
> experience, by and large. (In 7 years I only had two who did not
> know any programming language. One learned Forth from me. The other
> learned C from her fellow students.) The languages they were
> familiar with were Fortran, C and Basic. These all TRANslate FORmulas.
>
> Th point is, it is much clearer to someone who has just had a Runge-
> Kutta algorithm explained on the blackboard to understand it as
> a sequence of formulas a la Fortran than as a RPN-decomposed string
> of Forth. I mean, which is easier to read,
>
> f" k1 = h*fdummy(x+[a10]*k0,t+[c1]*h)"
>
> or
>
> h F@ x F@ a10 k0 F@ F* F+ t F@ c1 h F@ F* F+ fdummy F* k1 F!
>
> ?
>
> (Note I am now using ftran202.f, in which [a10] means "treat a10 as an
> FVALUE or FCONSTANT" i.e. omit the F@ that accompanies an FVARIABLE
> such as h or k0 .)
Julian,
I have looked at your FORmula TRANslator code and think that it is
absolutely great! I don't view it as a departure from Forth at all, but
rather an elegant extension of Forth to solve specific types of
problems. I can understand that engineering/physics students would warm
up to Forth a bit quicker with that extension available (I was once just
such a student).
I think your Formula TRANslator approach is one of those "leap"
paradigms such as local variables, text files, and OOP that helps make
Forth as useful as it is.
Regards,
-Doug
Ed
"Bill Spight" <bsp...@pacXbell.net> wrote in message
news:41406D37...@pacXbell.net...
> Dear Julian,
>
> > The point is, it is much clearer to someone who has just had a Runge-
> > Kutta algorithm explained on the blackboard to understand it as
> > a sequence of formulas a la Fortran than as a RPN-decomposed string
> > of Forth. I mean, which is easier to read,
> >
> > f" k1 = h*fdummy(x+[a10]*k0,t+[c1]*h)"
> >
> > or
> >
> > h F@ x F@ a10 k0 F@ F* F+ t F@ c1 h F@ F* F+ fdummy F* k1 F!
> >
>
> How much of resistance to Forth has to do with unfamiliarity with RPN?
> (What about Japanese speakers? The typical sentence structure of
> Japanese is Topic, Subject, Object, Verb. They also use postpositions
> instead of prepositions.)
That's right, but it becomes less readable as the sequence
increases - as in the case of a complex formula!
Humans cope adequately with RPN while the number of
items 'stacked' (i.e. to be remembered) is low. Brackets
in infix notation serve as a collating aid for the brain
allowing it to deal with less objects. Now that's not to say
that what's good for the brain is necessarily efficient for
a calculating machine!
> [snip]
> The virtue of RPN is that you can eliminate parentheses. The problem
> with RPN is that you eliminate parentheses. ;-)
Precisely. The fact that Julian had to develop an infix
parser for expressing complex formulas says it all.
However, this doesn't 'disprove' the benefit of forth
as the vast majority of forth code written won't involve
complex sequences.
The 'resistance to Forth' (and the reasons 'for Forth') has
much to do with ideology. It is quite likely to remain the
case that the majority of programmers, including CS
professionals, will insist that programming source should
be written primarily for humans; that it is the job of the
language compiler is to translate the infix notation etc to
machine form. Forth programmers, OTOH, believe that
is a function best done by the programmer.
So ultimately it's a matter of choice. Were it possible
to 'prove' that one language was better than another, then
no choice would be possible :)
Ed
Bill Spight
> Humans cope adequately with RPN while the number of
> items 'stacked' (i.e. to be remembered) is low.
That's true for natural language as well. There is some evidence from
cognitive psychology that the short term memory "stack" for processing
natural language has a depth of at most three. (Despite the joke about
the German professor ending his talk with a long string of verbal
particles. ;-) English "stack" example: We strung the rustler the posse
the sherrif swore in brought in up.)
> Brackets
> in infix notation serve as a collating aid for the brain
> allowing it to deal with less objects.
Yes, and they can serve that purpose in RPN, too, I think.
While they help, brackets do not solve the readability problem for infix
notation. Too many brackets indicate poor readability.
>> The virtue of RPN is that you can eliminate parentheses. The problem
>> with RPN is that you eliminate parentheses. ;-)
> Precisely. The fact that Julian had to develop an infix
> parser for expressing complex formulas says it all.
> However, this doesn't 'disprove' the benefit of forth
> as the vast majority of forth code written won't involve
> complex sequences.
Indeed it does not.
Best,
Bill
m-coughlin
>
> "m-coughlin" <m-cou...@comcast.net> wrote in message
> news:413E53A8...@comcast.net...
> ...
> > > We? Who is this WE that you always ask about? Since it
> > > must include you, let me ask, why don't you?
> >
> > I do. I tell new owners of computers that if they want to
> > learn to program, Forth is the easiest language to learn.
> > Then I contradict myself by telling them they can't go to
> > the bookstore and buy a text book or find good examples to
> > teach themselves.
>
> Poor dears, no internet access? Have to actually go to a
> store? Clearly unequipped to deal with anything as
> sophisticated as Forth.
>
> Of course, if they do have internet access, they can just go
> to www.forth.com where we have two books for sale that are
> great for learners.
Back in the days of mainframes and PDP style minicomputers, I
used all sorts of "sophisticated" software. Then I found out
about "minimalist" Forth. Much better. If Forth is changed to
appeal to "sophisticated" users, it will be much worse. I'm sure
you are so busy dealing with your many customers you might not
notice certain things that I do. By the time people get internet
access they also hear about programming in Java, C, and html.
Then they want to read a book or take a course in these topics.
A good time to interest them in programming in a different way
is before they become so "sophisticated".
Ed
"Bill Spight" <bsp...@pacXbell.net> wrote in message
> Dear Ed,
>
> > Humans cope adequately with RPN while the number of
> > items 'stacked' (i.e. to be remembered) is low.
>
> That's true for natural language as well. There is some evidence from
> cognitive psychology that the short term memory "stack" for processing
> natural language has a depth of at most three.
And here I was thinking it was age catching up with me :)
Ed
Peter Knaggs
>
>>Humans cope adequately with RPN while the number of
>>items 'stacked' (i.e. to be remembered) is low.
>
>
> That's true for natural language as well. There is some evidence from
> cognitive psychology that the short term memory "stack" for processing
> natural language has a depth of at most three.
I though the rule was five plus or minus two.
--
Peter Knaggs
Jerry Avins
The horse the man shot died.
The boy the horse the man shot died kicked screamed.
Or something like that!
Jerry
m-coughlin
[snip]
> I am guessing that f" A = B" translates to A B =. If not,
> I goofed.
It does not.
> Anyway, f"..." seems to have disappeared in the Forth
> version. Whatever information it provided must be inferred.
> (Also, equality has been replaced by assignment, with a
> slight change in meaning.)
One thing that confused me when I first tried to learn
programming in Fortran were expressions like A = B which (in
Fortran) means replace whatever is stored in the memory location
designated by "A" with whatever is stored in the memory location
designated by "B". Having an expression like f" A = B" in Forth
leads to confusion for those who do not know how to program in
both Forth and Fortran.
Jerry Avins
In Fortran, I used to write intentionally obscure code by sneaking 3 = 4
in somewhere, and then writing "3" when I wanted "4". (Small constants
were kept in memory and could be corrupted.) I guess writing := for
assignment isn't such a bad idea.
Brad Eckert
>
> But I think that
> : final ( time -- ) initial travel + fall + ;
> is easier to read and remember than
> final := x0 + v0*t + 0.5*a*t^2;
> even though it isn't calculator friendly.
>
I managed to resist for a while, but I just had to write some code to
illustrate this. Although, it's such a simple example that there's not
much chance to build up abstraction. But it's readable:
\ Constant acceleration factoring demo
1 [if] \ for other Forths
: FVALUE ( r <name> -- )
CREATE F, DOES> F@ ;
: FTO ( r <name> --) ' >BODY STATE @
IF POSTPONE LITERAL POSTPONE F!
ELSE F!
THEN ; IMMEDIATE
[then]
\ Define some variables with default settings
0e0 FVALUE T \ elapsed time
0.08e0 FVALUE X0 \ initial position
-0.12e0 FVALUE V0 \ initial velocity
9.8e0 FVALUE ACC \ acceleration 9.8m/s/s
\ Define contributing terms to the final X position
: initial ( -- m ) \ due to starting position
X0 ;
: travel ( -- m ) \ due to initial velocity
T V0 F* ;
: fall ( -- m ) \ due to acceleration
T FDUP F* 0.5e0 F* ACC F* ;
: X ( -- m ) \ due to all
initial travel f+ fall f+ ;
: .X ( sec -- ) \ display result
FDUP FTO T
cr f. ." seconds -> " X f. ." meters" ;
cr .( Final position after elapsed time)
0e0 .X
1e0 .X
2e0 .X
3e0 .X
Something like this would be good in a spreadsheet, which is a
non-Forth solution. Building such a spreadsheet would be a good
exercise for students. They could interact with it and get a good feel
for how the model behaves.
Bigger, more interesting problems might need more than a spreadsheet.
That's where Forth would come in handy. In a physics course, the
students would use an extension of Forth suited to the application
domain.
The bigger problems get into MathCAD and Mathworks. These luxury
vehicles let you explore complex models without doing a lot of
programming. But I wonder if the abstraction possible in Forth becomes
more valuable than the Mathworks way of doing things once the model
grows beyond a certain complexity. In other words, is abstraction
hindered by syntax the way it is in other languages?
Brad
Marcel Hendrix
[..]
> I managed to resist for a while, but I just had to write some code to
> illustrate this. Although, it's such a simple example that there's not
> much chance to build up abstraction. But it's readable:
[..]
> Something like this would be good in a spreadsheet, which is a
> non-Forth solution. Building such a spreadsheet would be a good
> exercise for students. They could interact with it and get a good feel
> for how the model behaves.
Highschool teenagers maybe, but students?
Because of computers a typical problem will be quite "complex",
in the sense that much highlevel functionality is taken for granted.
In this case, students would certainly like to plot and print a curve
of the movement etc.
> Bigger, more interesting problems might need more than a spreadsheet.
> That's where Forth would come in handy. In a physics course, the
> students would use an extension of Forth suited to the application
> domain.
It would be fun to assist teachers who'd like to do this. The problem
is the enormous amount of toolkit code that is necessary before one
can start working on the real problem. Even in your toy problem you
had to define two non-standard words first (FVALUE and FTO).
An effort comparable to writing 10 FSL's is necessary to produce
anything like Matlab, SciLib or Octave!
> The bigger problems get into MathCAD and Mathworks. These luxury
> vehicles let you explore complex models without doing a lot of
> programming. But I wonder if the abstraction possible in Forth becomes
> more valuable than the Mathworks way of doing things once the model
> grows beyond a certain complexity. In other words, is abstraction
> hindered by syntax the way it is in other languages?
I use Matlab almost daily, but would prefer to do all in Forth.
As an example I have added the code of a Matlab program and its translation
to (i)Forth. You will see that Forth would need automatic variables and
a flexible iterator scheme or array indexer to start becoming useful.
I think that at the moment Matlab features and syntax enable it to write
clearer and (much) shorter code than is possible in iForth. But it is not
hopeless, and the fact that Forth code is 2 - 10 times faster than Matlab
is a strong incentive :-)
-marcel
====== matlab code ======
function [U1,phi1,U2,phi2,P1,Q1,P2,Q2] = phroop(b,tst)
% [U1,PHI1,U2,PHI2]=PHROOP(B,TST)
% Connects two inverters in parallel using voltage and phase droop.
% Parameter B increases Rl and L5 simultaneously. With TST, debugging
% info is generated.
% Output the source parameters in Volts (amplitude) and radians (phase).
% The frequency of the sources is always 50 Hz.
%
% .-L1-.-R1--L2-.---Cx----. Cx is a numerical trick.
% | | | | It turns the POCC into a state variable,
% U1 C1 | = so we don't have to solve Kirchoff by hand.
% | | |
% = = | L1=L3 = 1.2mH, C1=C2 = 15uF, Rl = 5, L5 = 26mH
% | R1 = 0.4, L2 = 0.2mH, R2 = 0.3, L4 = 0.1mH
% .-L3-.-R2--L4-'--Rl--L5-.
% | | |
% U2 C2 =
% | |
% = =
%
% Inverter #1: 2 kVA, phase droop 1e-6 rad/Watt, Voltage droop 0.01 V/VAr
% Inverter #2: 1 kVA, phase droop 2e-6 rad/Watt, Voltage droop 0.02 V/VAr
%
% from 'Parallel Operation of Single Phase Inverter Modules With
% No Control Interconnections' Tuladhar, A.; Jin, H.; Unger, T.; Mauch, K.;
% Applied Power Electronics Conference and Exposition, 1997, APEC '97
% Conference Proceedings 1997., Twelfth Annual, Volume: 1, 23-27 Feb. 1997
% Pages: 94-100 Vol.1
%
% Last change: Marcel Hendrix, 6 September 2004
% Last change: Marcel Hendrix, 10 September 2004, 2 equal inverters.
global omega0 phi0 phi1 phi2 U0 U1 U2 p1a p2a q1a q2a verr pherr dbg
global reso_in reso_out
if nargin < 2, dbg = 0; else dbg = tst; end
% -----------------------------------------------------------------------------------
% Components ------------------------------------------------------------------------
% -----------------------------------------------------------------------------------
L1 = 1.2e-3; C1 = 15e-6; R1 = 0.4; L2 = 0.2e-3; % source #1
L3 = 1.2e-3; C2 = 15e-6; R2 = 0.3; L4 = 0.1e-3; % source #2
Cx = 1e-9; L5 = b*26e-3; Rl = b*5; % Load part
% -----------------------------------------------------------------------------------
% Sources ---------------------------------------------------------------------------
% -----------------------------------------------------------------------------------
U0 = 230*sqrt(2); U1 = U0; U2 = U0;
freq = 50; omega0 = 2*pi*freq; phi0 = 0; phi1 = 0; phi2 = 0;
p1a = 1000; p2a = 2000; q1a = 0; q2a = 0;
verr = 100; pherr = 100;
reso_in = 12; % 12 bit resolution minimum?
reso_out = 10; % 10 bit is OK
% -----------------------------------------------------------------------------------
% Simulation parameters -------------------------------------------------------------
% -----------------------------------------------------------------------------------
nsteps = 256; ncycles = 900;
% -----------------------------------------------------------------------------------
% State matrices --------------------------------------------------------------------
% -----------------------------------------------------------------------------------
% i1 i2 i3 i4 i5 v1 v2 vx u1 u2
x0 = [ 0 0 0 0 0 0 0 0 0 0 ]';
A = [ 0 0 0 0 0 -1/L1 0 0 1/L1 0
0 -R1/L2 0 0 0 1/L2 0 -1/L2 0 0
0 0 0 0 0 0 -1/L3 0 0 1/L3
0 0 0 -R2/L4 0 0 1/L4 -1/L4 0 0
0 0 0 0 -Rl/L5 0 0 1/L5 0 0
1/C1 -1/C1 0 0 0 0 0 0 0 0
0 0 1/C2 -1/C2 0 0 0 0 0 0
0 1/Cx 0 1/Cx -1/Cx 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 ];
% -----------------------------------------------------------------------------------
% Computation -----------------------------------------------------------------------
% -----------------------------------------------------------------------------------
xs = zeros(length(x0),nsteps*ncycles); ti = zeros(1,nsteps*ncycles);
% compute the active and reactive powers needed for drooping
P1 = zeros(1,ncycles); P2 = P1; Q1 = P1; Q2 = P1;
sig1 = zeros(1,nsteps); sig3 = sig1;
src1 = zeros(1,nsteps); src3 = src1;
phin = zeros(ncycles,2);
dT = 1/freq/nsteps;
for iy = [1:ncycles]
for i = [1:nsteps]
src1(i) = U1*cos(omega0*(i-1)*dT+phi1);
src3(i) = U2*cos(omega0*(i-1)*dT+phi2);
end
for ix = [1:nsteps]
index = ix + (iy-1)*nsteps;
ti(index) = (index-1)*dT;
x0(9) = src1(ix);
x0(10) = src3(ix);
xs(:,index) = x0;
sig1(ix) = x0(1); sig3(ix) = x0(3);
x0 = expm(A*dT)*x0;
end
if dbg
figure(3); clf; hold on;
plot(src1/U0,sig1/25,'r','LineWidth',2);
plot(src3/U0,sig3/25,'b','LineWidth',2);
pause(0);
end
% Compute active and reactive power of the two sources at 50 Hz.
[P1(iy),Q1(iy)] = powerof(src1,sig1);
[P2(iy),Q2(iy)] = powerof(src3,sig3);
P1(iy) = quant(P1(iy),reso_in);
Q1(iy) = quant(Q1(iy),reso_in);
P2(iy) = quant(P2(iy),reso_in);
Q2(iy) = quant(Q2(iy),reso_in);
control(P1(iy),Q1(iy),P2(iy),Q2(iy));
end
% -----------------------------------------------------------------------------------
% Presentation ----------------------------------------------------------------------
% -----------------------------------------------------------------------------------
figure(1); clf;
n = length(ti);
t = ti (n-2*nsteps+1 : n); ti = t;
x = xs(:,n-2*nsteps+1 : n); xs = x;
subplot(3,1,3); plot(ti*1000,xs(5,:),'blue', 'LineWidth',2); ylabel('\bfi_{L5} [A]');
xlabel('\bftime [ms]'); grid on; zoom on;
subplot(3,1,2); plot(ti*1000,xs(3,:),'red', 'LineWidth',2); ylabel('\bfi_{L3} [A]');
grid on; zoom on;
subplot(3,1,1); plot(ti*1000,xs(1,:),'black','LineWidth',2); ylabel('\bfi_{L1} [A]');
grid on; zoom on;
title('\bfParalleled Inverters');
figure(2); clf;
ylabel('\bfP1,P2,Q1,Q2 [kW,kVA]');
xlabel('\bfperiod [#]'); grid on; zoom on; hold on;
plot(P1*1e-3,'b', 'LineWidth',2);
plot(P2*1e-3,'r', 'LineWidth',2);
plot(Q1*1e-3,'black--','LineWidth',2);
plot(Q2*1e-3,'green--','LineWidth',2);
title('\bfPower Distribution of Paralleled Inverters');
% -----------------------------------------------------------------------------------
% Local functions -------------------------------------------------------------------
% -----------------------------------------------------------------------------------
% -----------------------------------------------------------------------------------
% Compute power in base harmonics ---------------------------------------------------
% -----------------------------------------------------------------------------------
function [P,Q] = powerof(src,sig)
X1 = fft(src); X2 = fft(sig); nsteps = length(X1);
X1 = 2*X1(2)/nsteps; X2 = 2*X2(2)/nsteps;
S = X1*conj(X2)/2; P = real(S); Q = imag(S);
% -----------------------------------------------------------------------------------
% The controller --------------------------------------------------------------------
% -----------------------------------------------------------------------------------
function control(P1,Q1,P2,Q2)
global omega0 phi0 phi1 phi2 U0 U1 U2 p1a p2a q1a q2a verr pherr dbg reso_out
m1 = 1e-6; m2 = 2e-6; % phase droop parameters
n1 = 1e-2; n2 = 2e-2; % voltage droop parameters
k = 0.7; % integration time constant, neither too slow nor too fast
p1a = k*p1a+(1-k)*P1; p2a = k*p2a+(1-k)*P2;
q1a = k*q1a+(1-k)*Q1; q2a = k*q2a+(1-k)*Q2;
phi1 = phi1+min(pi,max(-pi,-m1*p1a)); % integrate the phase error
phi1 = quant(phi1,reso_out);
phi2 = phi2+min(pi,max(-pi,-m2*p2a));
phi2 = quant(phi2,reso_out);
U1 = min(1.4*U0,max(0.6*U0,U0-n1*q1a));
U2 = min(1.4*U0,max(0.6*U0,U0-n2*q2a));
verr = 100*(U1-U2)/U0;
pherr = (phi1-phi2)*180/pi;
if dbg
fprintf('P1 %g Q1 %g P2 %g Q2 %g\n',P1,Q1,P2,Q2);
fprintf('phi1 = %g degrees phi2 = %g degrees U1 = %g V U2 = %g V\n',...
phi1*180/pi,phi2*180/pi,U1,U2);
fprintf('Voltage error %g percent, phase error %g degrees\n',verr,pherr);
end
function y =quant(x,bits)
y = round(x * 2^bits) / 2^bits;
% EOF
=== forth code ===
(*
* LANGUAGE : ANS Forth
* PROJECT : Forth Environments
* DESCRIPTION : 2000 Watt Solar platform
* CATEGORY : Simulation tools
* AUTHOR : Marcel Hendrix
* LAST CHANGE : September 20, 2004, Marcel Hendrix
*)
NEEDS -miscutil
NEEDS -eplot
NEEDS -sketcher
NEEDS -fsl_util
NEEDS -gaussj
REVISION -phroop "--- Phase Drooper Version 1.01 ---"
PRIVATES
DOC
(*
Connects two inverters in parallel using voltage and phase droop.
The frequency of the sources is always 50 Hz.
.-L1-.-R1--L2-.---Cx----. Cx is a numerical trick.
| | | | It turns the POCC into a state variable,
U1 C1 | = so we don't have to solve Kirchoff by hand.
| | |
= = | L1=L3 = 1.2mH, C1=C2 = 15uF, Rl = 5, L5 = 26mH
| R1 = 0.4, L2 = 0.2mH, R2 = 0.3, L4 = 0.1mH
.-L3-.-R2--L4-'--Rl--L5-.
| | |
U2 C2 =
| |
= =
Inverter #1: 2 kVA, phase droop 1e-6 rad/Watt, Voltage droop 0.01 V/VAr
Inverter #2: 1 kVA, phase droop 2e-6 rad/Watt, Voltage droop 0.02 V/VAr
from 'Parallel Operation of Single Phase Inverter Modules With
No Control Interconnections' Tuladhar, A.; Jin, H.; Unger, T.; Mauch, K.;
Applied Power Electronics Conference and Exposition, 1997, APEC '97
Conference Proceedings 1997., Twelfth Annual, Volume: 1, 23-27 Feb. 1997
Pages: 94-100 Vol.1
Last change: Marcel Hendrix, 6 September 2004
Last change: Marcel Hendrix, 10 September 2004, 2 equal inverters.
*)
ENDDOC
-- -----------------------------------------------------------------------------------
-- Simulation parameters -------------------------------------------------------------
-- -----------------------------------------------------------------------------------
50e FCONSTANT freq
320e FCONSTANT U0
1.2e-3 FCONSTANT L1
15e-6 FCONSTANT C1
0.4e FCONSTANT R1
0.2e-3 FCONSTANT L2 -- source #1
1.2e-3 FCONSTANT L3
15e-6 FCONSTANT C2
0.3e FCONSTANT R2
0.1e-3 FCONSTANT L4 -- source #2
1e-9 FCONSTANT Cx
26e-3 FCONSTANT L5
5e FCONSTANT Rl -- Load part
FALSE VALUE debug?
#11 VALUE reso_in
#10 VALUE reso_out
#128 =: nsteps
#900 =: ncycles
1e-6 FCONSTANT m1
2e-6 FCONSTANT m2 -- phase droop parameters
1e-2 FCONSTANT n1
2e-2 FCONSTANT n2 -- voltage droop parameters
0.7e FCONSTANT kk -- integration time constant, neither too slow nor too fast
1e kk F-
FCONSTANT 1-kk -- integration time constant, neither too slow nor too fast
-- -----------------------------------------------------------------------------------
-- Globals ---------------------------------------------------------------------------
-- -----------------------------------------------------------------------------------
freq PI*2 F*
FVALUE omega0 PRIVATE
0e FVALUE phi1 PRIVATE
0e FVALUE phi2 PRIVATE
320e FVALUE U1 PRIVATE
320e FVALUE U2 PRIVATE
1e3 FVALUE p1a PRIVATE
2e3 FVALUE p2a PRIVATE
0e FVALUE q1a PRIVATE
0e FVALUE q2a PRIVATE
freq 1/F nsteps S>F F/
FCONSTANT dT PRIVATE
-- -----------------------------------------------------------------------------------
-- State matrices --------------------------------------------------------------------
-- -----------------------------------------------------------------------------------
nsteps DOUBLE ARRAY src1{ PRIVATE
nsteps DOUBLE ARRAY src3{ PRIVATE
nsteps DOUBLE ARRAY sig1{ PRIVATE
nsteps DOUBLE ARRAY sig3{ PRIVATE
nsteps ncycles * DOUBLE ARRAY ti{
ncycles DOUBLE ARRAY P1{
ncycles DOUBLE ARRAY Q1{
ncycles DOUBLE ARRAY P2{
ncycles DOUBLE ARRAY Q2{
nsteps ncycles * #10 DOUBLE MATRIX xs{{
#10 #10 DOUBLE MATRIX A{{
#10 DOUBLE ARRAY x0{
: INITIALIZE S" phroop.set" INCLUDED
0e TO phi1 0e TO phi2
U0 TO U1 U0 TO U2
1e3 TO p1a 2e3 TO p2a
0e TO q1a 0e TO q2a ;P
-- -----------------------------------------------------------------------------------
-- Compute power in base harmonics ---------------------------------------------------
-- -----------------------------------------------------------------------------------
nsteps COMPLEX ARRAY x{ PRIVATE
-- NOTE: we only want to see absolute values!
: POWEROF ( v{ i{ -- ) ( F: -- |p| |q| )
( i) x{ }r->complex x{ }FFT ( amplitude is nsteps times too large )
x{ 1 } Z@ ZCONJUGATE
( v) x{ }r->complex x{ }FFT
x{ 1 } Z@ Z*
nsteps DUP * S>F 1/F F2* ZSCALE FABS FSWAP FABS FSWAP ;P
-- -----------------------------------------------------------------------------------
-- Compute current wavetables --------------------------------------------------------
-- -----------------------------------------------------------------------------------
: compute_WLUTS ( -- )
omega0 dT F* FLOCAL inc
phi1 nsteps 0 ?DO FDUP FCOS U1 F* src1{ I } DF! inc F+ LOOP FDROP
phi2 nsteps 0 ?DO FDUP FCOS U2 F* src3{ I } DF! inc F+ LOOP FDROP ;P
-- -----------------------------------------------------------------------------------
-- Simulate the circuit for a full mains cycle ---------------------------------------
-- -----------------------------------------------------------------------------------
: COMPUTE ( n -- )
nsteps * LOCALS| index |
nsteps 0 ?DO
index S>F dT F* ti{ index } DF!
src1{ I } DF@ x0{ 8 } DF!
src3{ I } DF@ x0{ 9 } DF!
x0{ =transpose 0 xs{{ index move-row
x0{ 0 } DF@ sig1{ I } DF!
x0{ 2 } DF@ sig3{ I } DF!
A{{ dT =matscale =expm x0{ =mat* x0{ =>
1 +TO index
LOOP ;P
-- -----------------------------------------------------------------------------------
-- Print debugging information -------------------------------------------------------
-- -----------------------------------------------------------------------------------
: .RESULTS? ( -- )
debug? 0= ?EXIT
GCLEAR
sketch-color >S
red TO sketch-color src1{ sig1{ plot-A2
green TO sketch-color src3{ sig3{ plot-A2
S> TO sketch-color ;P
-- -----------------------------------------------------------------------------------
-- quantize --------------------------------------------------------------------------
-- -----------------------------------------------------------------------------------
:INLINE QUANTIZE ( F: r -- r' )
[ reso_out 2^x S>F ] FLITERAL F* FROUND [ reso_out 2^x S>F ] FLITERAL F/ ;
:INLINE ZQUANTIZE ( F: z -- z' )
[ reso_in 2^x S>F ] FLITERAL F* FROUND [ reso_in 2^x S>F ] FLITERAL F/
FSWAP
[ reso_in 2^x S>F ] FLITERAL F* FROUND [ reso_in 2^x S>F ] FLITERAL F/
FSWAP ;
-- -----------------------------------------------------------------------------------
-- The controller --------------------------------------------------------------------
-- -----------------------------------------------------------------------------------
: G. ( F: r -- ) #16 FE.R ;
: CONTROL ( F: p1 q1 p2 q2 -- )
0e 0e FLOCALS| pherr verr q2 p2 q1 p1 |
p1a kk F* P1 1-kk F* F+ TO p1a
q1a kk F* Q1 1-kk F* F+ TO q1a
p2a kk F* P2 1-kk F* F+ TO p2a
q2a kk F* Q2 1-kk F* F+ TO q2a
phi1 p1a m1 F* F- QUANTIZE TO phi1
phi2 p2a m2 F* F- QUANTIZE TO phi2
U0 q1a n1 F* F- QUANTIZE TO U1
U0 q2a n2 F* F- QUANTIZE TO U2
debug? IF U1 U2 F- U0 F/ 100e F* TO verr
phi1 phi2 F- FDEG TO pherr
CR ." P1 " P1 G. ." Q1 " Q1 G. ." P2 " P2 G. ." Q2 " Q2 G.
CR ." phi1 " phi1 G. ." phi2 " phi2 G. ." U1 " U1 G. ." U2 " U2 G.
CR ." voltage error " verr F.N2 ." %, phase error " pherr F.N2 ." degrees"
ENDIF ;P
-- Plotting ---------------------------------------------------------------------------------------
: >RANGE ( F: ... minN maxN n -- min max )
1e99 1e-99 FLOCALS| max min |
0 ?DO FDUP max FMAX TO max
min FMIN TO min
LOOP min max ;P
: -iL1 red TO sketch-color xs{{ [ ncycles nsteps * 1- DUP nsteps 2* - ] LITERAL LITERAL 0 PLOT-COL[] ;
: -iL3 green TO sketch-color xs{{ [ ncycles nsteps * 1- DUP nsteps 2* - ] LITERAL LITERAL 2 PLOT-COL[] ;
: -iL5 yellow TO sketch-color xs{{ [ ncycles nsteps * 1- DUP nsteps 2* - ] LITERAL LITERAL 4 PLOT-COL[] ;
: -IL[] ( beg end -- )
DLOCAL range
xs{{ range 0 1 }range[]
xs{{ range 2 3 }range[]
xs{{ range 4 5 }range[]
6 >RANGE PMULTI PSCALE
red TO sketch-color xs{{ range 0 PLOT-COL[]
green TO sketch-color xs{{ range 2 PLOT-COL[]
yellow TO sketch-color xs{{ range 4 PLOT-COL[]
PSINGLE ;
: -IL ncycles nsteps * 1- DUP nsteps 2* - SWAP -IL[] ;
: -P1 blue TO sketch-color P1{ 0 ncycles 1- PLOT-A1[] ;
: -P2 white TO sketch-color P2{ 0 ncycles 1- PLOT-A1[] ;
: -Q1 magenta TO sketch-color Q1{ 0 ncycles 1- PLOT-A1[] ;
: -Q2 brown TO sketch-color Q2{ 0 ncycles 1- PLOT-A1[] ;
: -PQ[] ( beg end -- )
DLOCAL range
P1{ 0 1 range }range[]
P2{ 0 1 range }range[]
Q1{ 0 1 range }range[]
Q2{ 0 1 range }range[]
8 >RANGE PMULTI PSCALE
red TO sketch-color P1{ range PLOT-A1[]
green TO sketch-color P2{ range PLOT-A1[]
white TO sketch-color Q1{ range PLOT-A1[]
yellow TO sketch-color Q2{ range PLOT-A1[]
PSINGLE ;
: -PQ 0 ncycles 1- -PQ[] ;
: .INPUT ( -- )
PRECISION 3 SET-PRECISION
CR ." =============== PHROOP INPUT ==============="
CR ." L1 = " L1 F.N1 ." H"
CR ." L2 = " L2 F.N1 ." H"
CR ." L3 = " L3 F.N1 ." H"
CR ." L4 = " L4 F.N1 ." H"
CR ." L5 = " L5 F.N1 ." H"
CR ." C1 = " C1 F.N1 ." F"
CR ." C2 = " C2 F.N1 ." F"
CR ." Cx = " Cx F.N1 ." F"
CR ." R1 = " R1 F.N1 ." Ohms"
CR ." R2 = " R2 F.N1 ." Ohms"
CR ." Rl = " Rl F.N1 ." Ohms"
CR ." ============================================"
SET-PRECISION ;
: .OUTPUT ( -- )
PRECISION 3 SET-PRECISION
CR ." =============== PHROOP OUTPUT =============="
CR ." Phi1 = " phi1 F.N1 ." rad"
CR ." Phi2 = " phi2 F.N1 ." rad"
CR ." U1 = " U1 F.N1 ." Volt"
CR ." U2 = " U2 F.N1 ." Volt"
CR ." ============================================"
SET-PRECISION ;
-- -----------------------------------------------------------------------------------
-- Main word -------------------------------------------------------------------------
-- -----------------------------------------------------------------------------------
: PHROOP ( -- )
initialize
ncycles 0 DO
compute_WLUTS
I compute
.results?
src1{ sig1{ powerof ZQUANTIZE F2DUP Q1{ I } DF! P1{ I } DF!
src3{ sig3{ powerof ZQUANTIZE F2DUP Q2{ I } DF! P2{ I } DF!
control
debug? IF EKEY? ?LEAVE ENDIF
LOOP ;
:ABOUT CR ." Run with: PHROOP -- simulate for 18 seconds"
CR ." -iL1 | -iL3 | -iL5 | -P1 | -P2 | -Q1 | -Q2 -- plot signals"
CR ." a b -IL | -PQ -- plot currents | powers from a to b" ;
.ABOUT -phroop CR
DEPRIVE
(* End of Source *)
Bernd Paysan
> People only have five primary senses, however, there are many
> categorizations of feelings within the basic five primary sense
> types.
Five? The "sight, hearing, smell, taste, touch" stuff? What about
positional senses (vestibular system, magnetic sensors in the (male
only?) brain), chemical senses (blood, intestinal content), time senses
(short relative and long-term absolute, set by the sun, also the one
set by the phase of the moon (female only?)), and the "working
temperature" sense all endotherms have (you definitely sense deviation
from the target value). Unfortunately, we are a bit short on the
voltage sense, like sharks and some fishs have, which would be the 10th
sense (our tongue can "taste" electricity, though, but more currents
than voltage).
But I thought the topic here was how many objects the concious mind can
keep around at one time: this depends on the person; if you design for
others, you should stay within the magic 7. You can check easily how
many you can do yourself by looking at an assembly of n objects (not
forming groups, e.g. equidistant on a straight line), and estimate how
many objects that are. Once you can't give a correct guess without
counting, you've exceeded your personal limit.
Bill Spight
> But I thought the topic here was how many objects the concious mind can
> keep around at one time: this depends on the person; if you design for
> others, you should stay within the magic 7.
Actually, it was a related question, that of the linguistic "stack" for
producing nested (embedded) clauses. The maximum depth for that seems to
be three.
The related question of the number of data chunks people can keep in
short term memory is around 7. That's more like "channel capacity" than
"stack".
Best regards,
Bill
Jerry Avins
> Mark A. Washburn wrote:
>
>>People only have five primary senses, however, there are many
>>categorizations of feelings within the basic five primary sense
>>types.
>
>
> Five? The "sight, hearing, smell, taste, touch" stuff? What about
> positional senses (vestibular system, magnetic sensors in the (male
> only?) brain), chemical senses (blood, intestinal content), time senses
> (short relative and long-term absolute, set by the sun, also the one
> set by the phase of the moon (female only?)), and the "working
> temperature" sense all endotherms have (you definitely sense deviation
> from the target value). Unfortunately, we are a bit short on the
> voltage sense, like sharks and some fishs have, which would be the 10th
> sense (our tongue can "taste" electricity, though, but more currents
> than voltage).
You omitted one sense for which a salient organ is known in reptiles and
mammals, including humans. Check out Jacobson's organ. It's quite
interesting. http://chemistry.about.com/cs/medical/a/aa051601a.htm is a
good introduction, and "Jacobson's Organ And the Remarkable Nature of
Smell" By LYALL WATSON is an excellent book. The first chapter is at
http://www.nytimes.com/books/first/w/watson-organ.html.
Jerry
--
... they proceeded on the sound principle that the magnitude of a lie
always contains a certain factor of credibility, ... and that therefor
... they more easily fall victim to a big lie than to a little one ...
A. H.
———————————————————————————————————————————————————————————————————————
Bernd Paysan
> You omitted one sense for which a salient organ is known in reptiles
> and mammals, including humans. Check out Jacobson's organ.
Yes, I know that, but you could argue that this is quite closely related
to smell (sensing chemicals in the air), so even though this is a
separate sensor, it's not exactly a new sense. You also can sort of
"taste" with your fingers, just not well (that's why people like fat
salty finger-food). Or see UV with the skin, but you need to overexpose
it first to be sensitive (and then it comes as pain).
BTW smell: Some decades ago, I've read about an experiment which teaches
that people have a sort of "placebo effect" when the experimentator
tells them he's now spraying a smelly substance into the air. The
students did respond to the substance as it would have propagated, but
it actually was water, which back then was perceived as smell-less
substance. How wrong they were, for sure humans can smell water, it
just isn't tied to emotions like most other smells (i.e. it doesn't
stink).
Bernd Paysan
> Dear Bernd,
>
>> But I thought the topic here was how many objects the concious mind
>> can keep around at one time: this depends on the person; if you
>> design for others, you should stay within the magic 7.
>
> Actually, it was a related question, that of the linguistic "stack"
> for producing nested (embedded) clauses. The maximum depth for that
> seems to be three.
That opens the question if languages which allow non-nested clauses
where others (like English) need to nest, are more expressive. Or at
least easier to understand. You can overdo the nesting any time, just
you reduce your audience. A non-nesting language, or a language that
allows to express things more lineary would allow more complex thoughts
to be propagated than a competitive, nesting language.
Or is it the other way round, and people are trained to stack up nesting
levels as necessary?
m-coughlin
>
> m-coughlin <m-cou...@comcast.net> wrote in message
> news:<413F1D00...@comcast.net>...
Comp.lang.forth discussions keep going off into strange
directions that I don't know how to get back on track.
> > But if you emulate your stacks in software, storing the
> > data in RAM, then you can leap around the stack with ease.
>
> A program can, but a human mind can't. I have heard stories
> about things like 987654 PICK and whether the software layer
> to do it was efficient or not was never the issue. It is
> just a flawed idea.
Yes, if the information of what is on the stack is only kept
in your head, a deep stack will get you into deep yogurt. But I
am interested in what can be done by a programmer who puts that
information somewhere else. I once got a message in a Chinese
fortune cookie that said "Pale ink beats the best [human] memory"
> > This discussion of deep stacks seems to me to be mostly
> > about this difference.
>
> No. Just the opposite.
>
> > Shouldn't you be able to write more and better
> > algorithms if you can use all of the megabytes of RAM
> > available as a giant stack
>
> No. No. No. How many people can visualise megabytes of stack
> items and keep that image in their head while programming?
> Virtually none. It is a bad idea. Megabytes of memory is
> fine, I had several megabytes available even on F21 where
> programs are really tiny. But needing megabyteish stacks is
> very rare. There may be some recursive algorithms that when
> dealing with huge datasets might need a huge return stack.
> But you are not going to index deep into it the way one might
> be tempted to do with 'deep access' to a parameter stack.
Those recursive algorithms deserve serious consideration.
Each address on the return stack could consume three values from
the parameter stack, or a lot more than three values for
programmers who document what they are doing. If a special value
like zero shows up there might even be a need for skipping part
of the data and dropping some of the return stack. A recursive
algorithm that is too slow to be of any use on one type of
processor and coded in one particular language might be the
fastest thing around when coded in Forth and run on a more
carefully designed processor.
> > instead of restricting yourself to the small
> > amount of memory you have on a hardware stack on the CPU chip?
>
> It is not an either-or situation. It is simply a good-bad
> question because you just can't picture or juggle mega items
> in your head.
Don't juggle them in your head. Sit down and plan them out on
paper. Its called higher mathematics.
> > Or will the speed difference between on-processor and
> > off-processor memory always make a large stack impractical?
>
> In the case of F21 stack memory was on-processor while main
> memory was not. This meant that stack access tended to be
> about 100 times faster than to variables or items in extended
> stacks in memory.
Where is the limitation of this 100 times faster advantage?
Can the on board stack be restricted to three values without a
speed penalty or should more area be devoted to the stack?
> With other processors stack memory may be on-processor along
> with main memory. Stack memory is still likely to be faster
> and mostly for the reason that it is smaller than main memory.
> Main memory is for holding things like arrays, stacks are
> for passing parameters.
>
> These are the most basic ideas involved in writing code in
> Forth. I have a hard time understanding how anyone who claims
> to have any real experience with Forth could be so confused
> about such basic ideas. Deep stack access is impractical
> because of the human mind, it is just a bad idea. It is
> very bad idea to bring that idea into Forth. Forth will
> amplify such a bad idea very nicely.
I have a hard time understanding how anyone who is
experienced with Forth can make up their mind about computing
methods with little evidence.
[snip]
> . . . but generally everyone agrees that stack access
> should be kept shallow and that deep stack access should
> be avoided because it is bad.
Among many of my friends involved with computer
programming, there is an agreement that programming in Forth is
bad. Yes, I know that experienced Forth programmers keep their
stacks shallow. Yes, I know that inexperienced Forth programmers
sometimes use deep stacks to write bad code. That is no proof
that deep stacks are always bad and can never be used to any
advantage. It just means that the right situation for using deep
stacks has not been found or maybe somebody does know about it
and is keeping it a secret.
> > Learning to use unconventional ideas like Forth frees my
> > mind from narrow thinking.
>
> Do you have a permit to let that thing wander free?
I think it is just fine that Forth is used like a Hewlett
Packard calculator and lets you do many calculations with a
three or four deep stack. But that is backward thinking in an
age with CPU's that have vastly more resources than they used
to. There might be a computer science proof that deep stacks are
harmful, but it has not been presented.
Jeff Fox
> programming, there is an agreement that programming in Forth is
> bad.
If you accept that as a given it is hard to move forward
with any serious discussions of Forth. But what will most
likely happen anyway is that your other friends involved with
computer programming are likely to think of the terms in
the context in which they know them. When you say stacks
they say, sure, we know about that. We have lots of stuff
in our stack frames on our stacks. That's the way things
work, but we let the compiler keep track of all those
things on the stack. We don't try to do that in our heads!
Meanwhile the entire meaning of how a parameter stack is
used in Forth is completely missed in their understanding
and anyone using the terms with a Forth meaning will just
be talking past them.
> Yes, I know that experienced Forth programmers keep their
> stacks shallow.
The issue here is whether indexing down into a stack sounds
like a good idea. Forth programmers know it is isn't for
Forth programming, C programmers know that they do it all
the time and it is a good idea for their stack frame access.
But they are thinking stack frames on what we call a return
stack in Forth, and we are thinking parameters passed
between Forth routines. Because we are thinking about parameters
passed between routines we really can have stack pictures in our
minds. This is a seemingly insane idea to any C programmers who
try to imagine having to keep a picture of exactly what they
are really doing to a stack.
> Yes, I know that inexperienced Forth programmers
> sometimes use deep stacks to write bad code.
You know lots of seemingly unrelated things.
> That is no proof
> that deep stacks are always bad and can never be used to any
> advantage.
You are stretching again. Always bad? Never be used to any
advantage? The point I made was, it's not bad, it's just bad
in Forth. This goes right by anyone thinking in C. Or they
someone interpret it as saying that C style stack frames with
deep indexed access is just a bad thing. No, it is just not
what we mean by passing parameters between routines when we
have a dedicated parameter stack to do that in Forth. It
seems to be a hard point for some people to get.
> It just means that the right situation for using deep
> stacks has not been found or maybe somebody does know about it
> and is keeping it a secret.
Sometimes I think you are always just trolling. You know perfectly
well that I have already given you examples where say Chuck used
the stack as the buffer for video input in a Novix tutorial. The
stack was the fastest thing and was big enough to buffer quite a
few parameters. Now he says that programmers should try to keep
the parameters on the parameter stack down to two or three or less
as a rule. Yet, he has published examples of tutorial Forth code
using the stack to buffer hundreds of items! What gives?
There is a rule that applies almost all of the time and there are
special cases. You have been told this. You have been given the
examples. YET YOU CLAIM THAT NO ONE HAS FOUND THIS OR IS KEEPING
IT A SECRET. Maybe your news server has lost most of the replies
that you seem to ignore when you come back into a thread after
a month or two claiming that no one has presented evidence or
that examples that you have been given either don't exist or
are being kept secret.
This is what I refer to as your vision problem and how it becomes
our problem. We give you examples. You claim no examples exist
or that someone is keeping them secret.
You seem to wait a month or so until people have forgotten that
you were given all the examples that you asked for and upon
return to an old thread declare that no examples exist. What's
up with that? Do you have a server problem?
> > > Learning to use unconventional ideas like Forth frees my
> > > mind from narrow thinking.
> >
> > Do you have a permit to let that thing wander free?
>
> I think it is just fine that Forth is used like a Hewlett
> Packard calculator and lets you do many calculations with a
> three or four deep stack.
Forth was used in a Hewlett Packard calculator? Which one? I
know they used RPN but I don't think they had a Forth did they?
> But that is backward thinking in an
> age with CPU's that have vastly more resources than they used
> to.
Your thinking is mixed up, messed up and full of erroneous
assumptions. You ignore the answers that people give you and
then make declarations that things that have been shown to you
to be false are somehow true. You mix up ideas like RPN and
Forth and say that backward thinging is taking place. It
looks too jumbled to me to even have a consistent direction.
Your not one of the backwards crowd, you are off in all
directions at once.
> There might be a computer science proof that deep stacks are
> harmful, but it has not been presented.
Let's keep the thread limited to deep stack access in Forth lest
it gets sidetracked in the ways that you complain about.
m-coughlin
>
> m-coughlin <m-cou...@comcast.net> wrote in message
> news:<41656DF3...@comcast.net>...
[snip]
>
> Sometimes I think you are always just trolling. You know
> perfectly well that I have already given you examples where
> say Chuck used the stack as the buffer for video input in a
> Novix tutorial. The stack was the fastest thing and was big
> enough to buffer quite a few parameters. Now he says that
> programmers should try to keep the parameters on the parameter
> stack down to two or three or less as a rule. Yet, he has
> published examples of tutorial Forth code using the stack to
> buffer hundreds of items! What gives?
I wouldn't want to present such examples to an unbiased
audience and certainly not to C bigots. Chuck Moore's code is,
shall we say, subtle. I haven't counted hundreds of published
examples. Which of these would you recommend I present to
computer science students and where can they be found?
> There is a rule that applies almost all of the time and there
> are special cases. You have been told this. You have been
> given the examples. YET YOU CLAIM THAT NO ONE HAS FOUND THIS
> OR IS KEEPING IT A SECRET. Maybe your news server has lost
> most of the replies that you seem to ignore when you come back
> into a thread after a month or two claiming that no one has
> presented evidence or that examples that you have been given
> either don't exist or are being kept secret.
>
> This is what I refer to as your vision problem and how it
> becomes our problem. We give you examples. You claim no
> examples exist or that someone is keeping them secret.
The examples are not terribly convincing. Perhaps there is
better information that I haven't found yet.
> You seem to wait a month or so until people have forgotten that
> you were given all the examples that you asked for and upon
> return to an old thread declare that no examples exist. What's
> up with that? Do you have a server problem?
No server problem. But there are too many other topics in
computing to read about and I can't devote enough time to
debating the methods of programming in Forth. I also need to let
some time elapse to review my draft messages to keep the
discussion at a high intellectual level.
[snip]
> Forth was used in a Hewlett Packard calculator? Which one? I
> know they used RPN but I don't think they had a Forth did they?
>
> > But that is backward thinking in an
> > age with CPU's that have vastly more resources than they used
> > to.
>
> Your thinking is mixed up, messed up and full of erroneous
> assumptions. You ignore the answers that people give you and
> then make declarations that things that have been shown to you
> to be false are somehow true. You mix up ideas like RPN and
> Forth and say that backward thinging is taking place. It
> looks too jumbled to me to even have a consistent direction.
> Your not one of the backwards crowd, you are off in all
> directions at once.
I use the shallow stack in Hewlett Packard calculators the
same way I use the stack when calculating with Forth.
> > There might be a computer science proof that deep stacks are
> > harmful, but it has not been presented.
>
> Let's keep the thread limited to deep stack access in Forth lest
> it gets sidetracked in the ways that you complain about.
I think we can agree that experience has shown Forth
programming only needs to use a shallow stack and drop the
subject. If I find a counter example I'll let you know.
Jeff Fox
> shall we say, subtle. I haven't counted hundreds of published
> examples. Which of these would you recommend I present to
> computer science students and where can they be found?
I wouldn't recomment that you present any of the examples to
computer science students. I agree with Daniel Dennett that
there is little that I hate worse than a bad arguement for
something that I hold dear.
I know that a lot of Forth haters will say the most ridiculous
stuff about Forth, I accept that. I don't like it when people
who claim to like Forth present all the most awful untruths
about Forth exactly like every other Forth hater. If they
can't make good arguments I wish they would not try to make
any. They give people like C programmers that there are no
good arguments to give, because someone who claims to be
giving them the good arguements is really just strengthening
their missunderstandings of Forth by agreeing with them about
things like that programming in Forth is just a bad idea.
What you call presenting arguments in favor of Forth I call
presenting every popular falsehood about Forth while calling
them arguments in favor of Forth. This is why I would not
recommend your presenting information on Forth to the
unfortunates who might take what you present seriously.
> > There is a rule that applies almost all of the time and there
> > are special cases. You have been told this. You have been
> > given the examples. YET YOU CLAIM THAT NO ONE HAS FOUND THIS
> > OR IS KEEPING IT A SECRET. Maybe your news server has lost
> > most of the replies that you seem to ignore when you come back
> > into a thread after a month or two claiming that no one has
> > presented evidence or that examples that you have been given
> > either don't exist or are being kept secret.
> >
> > This is what I refer to as your vision problem and how it
> > becomes our problem. We give you examples. You claim no
> > examples exist or that someone is keeping them secret.
>
> The examples are not terribly convincing. Perhaps there is
> better information that I haven't found yet.
You ask for examples. You get examples. You claim that no one
gave you examples, that no examples exist or that people are
keeping them secret. When called on it you admit that the
examples exist, you were shown them, no one was keeping them
secret, and you were not being honest. Now you try to cover
those untruths with a statement that 'you did not find the
examples convincing.'
This is what I have refered to as your vision problem. People
show you things, you claim no one showed you anything. When
it is pointed out that what you are saying simply isn't
true, that there were examples given to you when you asked,
you say that 'you didn't want to see them' so you just
continued to claim to that they don't exist. You refuse
to see a lot things. As long as you are going to dismiss
all evidence as unconvincing why don't you just admit that
no evidence is all that you will accept. You will refuse
to consider evidence because your mind is already made
up and considering evidence might force you to actually
reconsider your positions. So you usually just lie about
it a later time and claim that no one ever gave you the
evidence that you asked for.
You should admit that you ask for evidence but really
don't want it and won't accept it. You have made up your
mind on such subjects as you comment that you and your
friends just agree that programming in Forth is a bad
thing. Once you start with a position like that you
will have to ignore all evidence in the real world to
maintain that position. You will be forced to take
the most absurd and ridiculous positions like complaining
that Forth is a failure because programmers are not
each being paid billions of dollars for their Forth
programming.
> No server problem. But there are too many other topics in
> computing to read about and I can't devote enough time to
> debating the methods of programming in Forth.
I haven't see you engage in much debate. I would enjoy seeing
or reading a debate between you and someone else on the subject
of methods of programming in Forth. You have said that you
don't like ANS and liked antique Forths. I don't recall you
ever debating methods of programming in Forth.
In fact I get the impression that you are not a Forth programmer
but enjoy making fun of Forth with your C programmer friends.
You might have done some programming with some antique Forth
in ancient times, but I suspect from most of your comments that
you are one of those people with a very odd interest in Forth.
You are not a professional Forth programmer from what I gather.
You are not a professional programmer at all from what I gather.
You work almost entirely with C software and the people that
you work with work with C. I suppose that I call complaining
about Forth to your C programmer friends and complaining about
Forth in c.l.f is what you like to think of as debating
methods of programming in Forth. And that's funny.
How much Forth programming have you done in say the last year?
You seem to have an interest in Forth from a distance, an odd
interest in what Forth programmers who you have no contact with
are doing, or an odd interest in Forth from the ancient past.
I don't get the impression that you have anything to do with
Forth really except this complaining. Is this the case?
> I also need to let
> some time elapse to review my draft messages to keep the
> discussion at a high intellectual level.
That's funny. But you left out the smiley. ;-)
> > Forth was used in a Hewlett Packard calculator? Which one? I
> > know they used RPN but I don't think they had a Forth did they?
> I use the shallow stack in Hewlett Packard calculators the
> same way I use the stack when calculating with Forth.
That doesn't mean that HP calculators had Forth in them. Just because
you might have used one to wipe your ass doesn't mean that it was
designed to be used as toilet paper.
Your arguements that an antique HP calculator is different than
a modern PC is valid, but your attempt to classify the calculator
as Forth is just nuts. If you claim that you used the calculator
the same way that you used Forth I must conclude that you never
used more than about 1% of Forth. That would help explain the
absolutely bizzare ideas that you have about Forth.
> I think we can agree that experience has shown Forth
> programming only needs to use a shallow stack and drop the
> subject. If I find a counter example I'll let you know.
Yes, we agree that "deep" stack access in Forth is a bad
thing. We can drop the discussion of deep stack questions.
But I am still currious about the depth of your actual
involvement in the use of and understanding of Forth. How
many hours in the last year did you spend programming in
Forth?
Best Wishes
andr...@littlepinkcloud.invalid
> Forth was used in a Hewlett Packard calculator? Which one? I
> know they used RPN but I don't think they had a Forth did they?
The had Forth on the HP71B and RPL, a Forth derivative, on the HP28
and all its sucessors.
Andrew.
# RPL: A Mathematical Control Language, by W. C. Wickes, Proc. 1988
Rochester Forth Conference
Hans Bezemer
> Among many of my friends involved with computer
> programming, there is an agreement that programming in Forth is
> bad. Yes, I know that experienced Forth programmers keep their
> stacks shallow. Yes, I know that inexperienced Forth programmers
> sometimes use deep stacks to write bad code. That is no proof
> that deep stacks are always bad and can never be used to any
> advantage. It just means that the right situation for using deep
> stacks has not been found or maybe somebody does know about it
> and is keeping it a secret.
ARRAY. In my tutorials, I maintain that the use of PICK and ROLL
should be discouraged. I have not implemented them in my primitives. I
have a shared return/data stack of 512 items, but I'm sure that most
of my applications would run happily in a tenth of that amount. The
enemy of stacks are recursive algoritms, which consume a lot of stack
space (and sometimes may be too much). Some can be rewritten (like the
ANS-Forth standard illustrates), others will always be threathened by
running out of stack space. Forth is no better than other languages
that way, but not worse either..
> I think it is just fine that Forth is used like a Hewlett
> Packard calculator and lets you do many calculations with a
> three or four deep stack. But that is backward thinking in an
> age with CPU's that have vastly more resources than they used
> to. There might be a computer science proof that deep stacks are
> harmful, but it has not been presented.
There is no such thing as computer "science" like there is a thing
like physics.
Compare "computer science" to "economics". Sure, there is mathematics,
but I doubt whether you'll find proof that deep stacks are bad. An
algoritm with deep stacks can be proven to be correct or not correct,
but not "bad".
That HP calculators and Forth share RPN does not make them comparable.
Forth and C share structured programming, but they are very different.
C _does_ use stack (frames) but hides them from the programmer where
Forth makes them visible. C uses local variables to do manipulations
and there is an ANS-wordset that support local variables, so..
Hans Bezemer
John Doty
frames and a parameter stack are rather different things, only
superficially similar. If stack frames are of assistance in meeting your
application's requirements, it's easy to implement a separate stack for
them.
andr...@littlepinkcloud.invalid
> andr...@littlepinkcloud.invalid wrote:
>> Jeff Fox <f...@ultratechnology.com> wrote:
>>
>>
>>>Forth was used in a Hewlett Packard calculator? Which one? I
>>>know they used RPN but I don't think they had a Forth did they?
>>
>>
>> The had Forth on the HP71B and RPL, a Forth derivative, on the HP28
>> and all its sucessors.
>>
>> Rochester Forth Conference
> RPL stands for "Reverse Polish LISP": it is a LISP, without
> parentheses (it features a GC that not only collects objects but also
> code).
That paper in question shows just how closely RPL descended from
Forth. It can, I suppose, be described as a hybrid of Forth and Lisp.
> Early HP calculators (before HP 28) can be considered as Forth
> machines, though.
I can't see why: the language used to program them was nowhere near as
close to Forth as System RPL is.
Andrew.
Sébastien Furic
> Sébastien Furic <sebasti...@tni.fr> wrote:
>
>>andr...@littlepinkcloud.invalid wrote:
>>
>>>Jeff Fox <f...@ultratechnology.com> wrote:
>>>
>>>
>>>
>>>>Forth was used in a Hewlett Packard calculator? Which one? I
>>>>know they used RPN but I don't think they had a Forth did they?
>>>
>>>
>>>The had Forth on the HP71B and RPL, a Forth derivative, on the HP28
>>>and all its sucessors.
>>>
>>># RPL: A Mathematical Control Language, by W. C. Wickes, Proc. 1988
>>>Rochester Forth Conference
>
>
>> RPL stands for "Reverse Polish LISP": it is a LISP, without
>>parentheses (it features a GC that not only collects objects but also
>>code).
>
>
> That paper in question shows just how closely RPL descended from
> Forth. It can, I suppose, be described as a hybrid of Forth and Lisp.
The only "Forthish" things that remain in RPL are the explicit
parameter stack manipulation (altough many users prefer using local
variables) and reverse polish notation. So, yes, it could be seen as
some kind of Forth but the "programing discipline" is 100% LISP: users
can safely push arbitrary objects on the stack without worrying about
memory allocation/deallocation issues (thanks the GC), functions can be
nested, etc. So from the user point of view, it is mostly a LISP (a
"complex" LISP program can be translated more direcly into RPL than a
"complex" Forth program (by "complex", I mean "real world")).
>
>>Early HP calculators (before HP 28) can be considered as Forth
>>machines, though.
>
>
> I can't see why: the language used to program them was nowhere near as
> close to Forth as System RPL is.
I didn't speak about System RPL (which is invisible from "casual
users"), only about User RPL... Appologies for my lack of precision. Now
I understand your point.
Cheers,
Sébastien.
andr...@littlepinkcloud.invalid
> andr...@littlepinkcloud.invalid wrote:
>> Sébastien Furic <sebasti...@tni.fr> wrote:
>>
>>>andr...@littlepinkcloud.invalid wrote:
>>>
>>>>Jeff Fox <f...@ultratechnology.com> wrote:
>>>>
>>>>
>>>>
>>>>>Forth was used in a Hewlett Packard calculator? Which one? I
>>>>>know they used RPN but I don't think they had a Forth did they?
>>>>
>>>>
>>>>The had Forth on the HP71B and RPL, a Forth derivative, on the HP28
>>>>and all its sucessors.
>>>>
>>>># RPL: A Mathematical Control Language, by W. C. Wickes, Proc. 1988
>>>>Rochester Forth Conference
>>
>>
>>> RPL stands for "Reverse Polish LISP": it is a LISP, without
>>>parentheses (it features a GC that not only collects objects but also
>>>code).
>>
>>
>> That paper in question shows just how closely RPL descended from
>> Forth. It can, I suppose, be described as a hybrid of Forth and Lisp.
> The only "Forthish" things that remain in RPL are the explicit
> parameter stack manipulation (altough many users prefer using local
> variables) and reverse polish notation.
Well, I can certainly think of a few others, in particular the way
that the language is actually implemented -- and the actual designers
of the language have fully acknowledged the source.
But just for the sake of argument let's look at an example from
"Programming in System RPL":
::
OVER
>R (Push list elements in return stack)
ticR (Try to get first element)
NOTcaseDROP (If list is empty, drop the object)
PushVStack&Clear (Save current stack)
BINT0 GetElemBotVStack (Get first list elemement)
BEGIN
BINT1
GetElemBotVStack
xEVAL (Get object and evaluate)
RSWAP
ticR (Get next element from list)
WHILE (Repeat while there are elements)
RSWAP
REPEAT
DEPTH
{}N (Collect results)
PopVStackAbove (Get saved stack)
4UNROLL3DROP (Drop arguments & first object)
;
> So, yes, it could be seen as some kind of Forth but the "programing
> discipline" is 100% LISP: users can safely push arbitrary objects on
> the stack without worrying about memory allocation/deallocation
> issues (thanks the GC), functions can be nested, etc. So from the
> user point of view, it is mostly a LISP (a "complex" LISP program
> can be translated more direcly into RPL than a "complex" Forth
> program (by "complex", I mean "real world")).
>>>Early HP calculators (before HP 28) can be considered as Forth
>>>machines, though.
>>
>> I can't see why: the language used to program them was nowhere near as
>> close to Forth as System RPL is.
> I didn't speak about System RPL (which is invisible from "casual
> users"), only about User RPL... Appologies for my lack of
> precision.
And my apologies for the same fault.
> Now I understand your point.
I thought the question was about the language used by HP.
Besides, the difference between System RPL and User RPL is that the
language is sanitized in a way that hides _some_ of the Forthishness
of the underlying implementation and prevents the user from crashing
the system.
Andrew.