Re recursive calls an absolute No No !
Ken Frost
Thanks, Ken
Edward Loh
I would not say that at all. Recursive call is, IMHO (and others), a
very useful programming technique if your programming language supports it.
Clarion certainly supports recursive calls.
Just be careful when using recursive calls. Make sure that all "local"
variables (temporary data that is needed for each invocation of the
procedure) are local/private (AUTO). And don't forget to have a way to
terminate the "recursiveness." One last thing to make sure is to have
enough stack space for recursive routines. They tends to eat up stack space
quickly especially if lots of local variables are used.
Regards,
Edward
"Ken Frost" <oldfros...@talk21.com> wrote in message
news:Xns936E9E1D4E665o...@209.16.210.54...
Ken Frost
Ken
"Edward Loh" <Edwa...@msn.com> wrote in
news:3eb1...@news.softvelocity.com:
Mark Goldberg
before CW 1.0). Recursion works fine.
You can think of recursion as a form of a loop, and of course
infinite loops are bad.
--
www.Tradesmens.com
Mark Goldberg
"Ken Frost" <oldfros...@talk21.com> wrote in message
news:Xns936E9E1D4E665o...@209.16.210.54...
Ian Holdsworth
"local"
> variables (temporary data that is needed for each invocation of the
> procedure) are local/private (AUTO). And don't forget to have a way to
> terminate the "recursiveness." One last thing to make sure is to have
> enough stack space for recursive routines. They tends to eat up stack
space
> quickly especially if lots of local variables are used.
How do you increase the stack space?
Do you mean START(MYPROC,Humongous amount)?
Randy Goodhew
Mark Goldberg wrote:
snip>
> You can think of recursion as a form of a loop, and of course
> infinite loops are bad.
PMFJI, Recursion is very different than iteration (loops).
1. Recursion - procedures that call themselves.
They are "nested" executions.
Local dynamic data is pushed onto the stack which each call,
then popped off the stack when each procedure returns.
2. Iteration - procedures that are called multiple times in a loop
structure.
They are called one at a time, successively. Where, each procedure
terminates between calls.
Clarion is a reentrant language and capable of true recursion,
e.g. recursive QuickSort.
My favorite definition:
"Recursion: see recursion."
--
Randy Goodhew
---[ eQ ]---
Edward Loh
Actually I've had very, very little need to increase the stack space in
the Windows environment. Within Clarion, sometimes Start()ing with a
different number in the second parameter solves the problem. In general, I
believe, the stack size is specifies by the operating system. Some of our
resident OS gurus may have a better answer.
Regards,
Edward
"Ian Holdsworth" <ab...@microsoft.com> wrote in message
news:3eb1...@news.softvelocity.com...
Mark Goldberg
I was trying to make the point that:
if you believe that recursion is bad,
then other programming constructs are bad too.
And I just found my source from '94 (when I was programming on a
486-25Hhz)
See how StepOn calls StepOn
StepOn procedure(x,y)
adj byte
code
if x < 1 or x > width or y < 1 or y > width then return.
if buttons[x,y] <> UNKNOWN then return.
adj = deter_adj(x,y)
if adj = 0
buttons[x,y] = ZERO
SafeRemain -= 1
SafeFound += 1
showp(x,y)
if GameInProgress
StepOn(x-1,y-1)
StepOn(x-1,y )
StepOn(x-1,y+1)
StepOn(x ,y-1)
StepOn(x ,y+1)
StepOn(x+1,y-1)
StepOn(x+1,y )
StepOn(x+1,y+1)
.
else
buttons[x,y] = adj
SafeFound += 1
SafeRemain -= 1
showp(x,y)
.
if ~SafeRemain
YouWon()
.
--
www.Tradesmens.com
Mark Goldberg
"Randy Goodhew" <rgoo...@fuse.net> wrote in message
news:3EB160C2...@fuse.net...
Randy Goodhew
You are creating successive recursions that could impale
the stack in a worst case scenario.
Are you trying to test eight rules based upon your two
parameters or all combinations and/or permutations of these
rules called in succession?
Most examples of recursion wouldn't have this redundancy.
Just asking...
Mark Goldberg
out recursion when recursion was first added to clarion (the [july
23rd] DAB sneak preview version of CDDW from Devcon. (remember this
code is 9 years old)
This is my implementation Programs->Accessories->Games->MineSweeper.
My recursive function handles stepping on a grid location (x,y) It
needs to test the 8 adjacent cells in the 2D grid.
In the game, when you step on a cell, it evaluated for the number of
adjacent mines. If that cell has zero adjacent mines, then each of
those adjacent mines are evaluated too. Some of those may also have
zero adjacement mines. And so on.
Interestingly I used to play a dos version of this game as a
diversion while writing a paper on Von Neuman celluar autonoma.
That and another called FIRE which was also cellular in nature.
IMO, recursion is a form of looping where the stack / variable
scoping is used to store information.
Graph or Tree traversal are common problems that recursion can solve
elegantly.
--
www.Tradesmens.com
Mark Goldberg
"Randy Goodhew" <rgoo...@fuse.net> wrote in message
news:3EB17A86...@fuse.net...
Russell B. Eggen
Try this example. Code a class that has as a property a reference to
itself. The class is responsible for walking down a directory tree. The
example I had was given to me to explain recursion and it helped a lot.
Unfortunately, I no longer have this class, but have been meaning to re-code
it. This thread reminded me of this.
Recursion logic used to give me headaches. Now only temporal physics do
that <bg>.
--
Russ Eggen
www.radfusion.com
"Mark Goldberg" <MarkNG...@MonolithCC.com> wrote in message
news:3eb1...@news.softvelocity.com...
Randy Rogers
> Graph or Tree traversal are common problems that recursion can solve
elegantly.
Regards
Randy
"Mark Goldberg" <MarkNG...@MonolithCC.com> wrote in message
news:3eb1...@news.softvelocity.com...
QuantumX admin
> that <bg>.
How about the quantum recursiveness of temporal physics ? <VBG>
Tony Bowes
Ralph Gathmann
instances of itself is good for recursion, arranged graphs can be easily
wandered through. I once tried to write a nested menu system for a
website with iteration (just not thinking enough) - a nightmare. The
recursive code is just easier to understand and MUCH more compact. I
believe there is a programming language where everything must be
recursive... just forgot which one.
--
Regards
R. Gathmann
Jason Berkan
<raklo...@rakloedder.de> wrote:
>I
>believe there is a programming language where everything must be
>recursive... just forgot which one.
LISP, or any other functional programming language.
Jason
Randy Goodhew
--
Jason Berkan
wrote:
>Jason Berkan wrote:
>>
>> LISP, or any other functional programming language.
>
And for a list of 19 others:
http://www.cs.nott.ac.uk/~gmh//faq.html
Jason
Philip Prohm
Sorry, this has no exit condition
As for the original question, some problems are best defined recursively and
hence are well served by a recursive solution. For example, a list:
list = item + tail
tail = zero or more items
A recursive algorithm is compact and easily understood, therefore robust.
There is no golden rule that says which problem should be solved recursively
and which should be solved iteratively; both approaches are powerful and one
should be comfortable with both and use the approach that is appropriate for
the problem at hand.
Philip
Randy Goodhew
Knowing the difference between recursion and iteration is very useful.
Many problems can be solved by either method,
e.g. QuickSort algorithm, parsers, factorials.
Recursion:
----------
Factorial PROCEDURE(LONG n)
Result LONG,AUTO
CODE
IF n = 1
Result = 1 ! exit condition
ELSE
Result = n * Factorial(n - 1) ! recursion
END !if
RETURN(Result)
Iteration:
----------
Factorial PROCEDURE(LONG n)
J LONG,AUTO
Result LONG,AUTO
CODE
Result = 1
LOOP J = n TO 1 BY -1
Result *= J
END !if
RETURN(Result)
Granted, neither of the above algorithms are very useful because of
data type limitations, but which is better suited for the intended
purpose?
Its a matter of taste...
--