Re: grassfire algorithm in java

From: Rowland (banksr0_at_hotmail.com)
Date: 09/29/04 

Date: Wed, 29 Sep 2004 09:39:43 +0000 (UTC)

"Paul Lutus" <nospam@nosite.zzz> wrote in message
news:10ljfmhjpji9ce@corp.supernews.com...
<snip>
> How many recursions did it take to overflow the stack? Your method doesn't
> say, recursion counting does. In the design phase, a programmer will need
> to know this.

It would be trivial to extend his program to count recursions, e.g:

class Stack {
    public static int recursionCount = 0;
<snip>
    static void recurse() {
        recursionCount++;
        recurse();
    }
}

> What was going on with the recursion at, say, level 20, a question that
may
> be asked in order to evaluate the algorithm's progress. Your method
doesn't
> say.

But this is an argument for using it to debug - not in production. I agree
that it *could* be a useful debugging technique, but that is all. In the
field you have NO idea how much stack space exists, erego you do not know
what limits to set. Your program could run on anything from a Nokia mobile
phone with very little stack space to a computer with 100 Terabytes of
stack - you have NO idea. On the Nokia, the program will run out of stack
before your limit is reached, and throw an exception, which you will not
have handled. On the computer with the massive stack, the program might be
required to work on large datasets, requiring a huge number of recursive
calls that exceed the limit you defined in your program. I do not want to
have to change a constant in my program every time it runs on a new
computer, or with a new data set.

> All your method does is allow a system error to stop the algorithm. A
> programmer might then want to know why that is true, in fact, that appears
> to be the topic of this thread.

For debugging it MAY be a useful technique - but you are talking about using
this in the real world.

> To find out, he would need to analyze the
> behavior of the algorithm. To do that, he needs to have more information.

It would be trivial to extend Mr. Schillings program to output this sort of
information. Or one could run it through a debugger... There are many better
debugging methods available. Your way is one possible way (and not one I
would personally use).

> On a short list of vital items of data is the recursion count, both to
> indicate how deep the recursion had run, and also (by stopping at a
> predetermined point while there is still stack space to allow method
calls)
> to analyze and preserve the specific state of the algorithm at any
> arbitrary recursion level one may care to examine.

One could do this with Mr. Schillings program if they so desired, fairly
easily.

> Not counting recursions, instead allowing the stack to overflow, is
limiting
> for these and other reasons. This is why deliberately allowing the stack
to
> overflow, as an algorithm control device, is avoided in all but
> pathological code.

But there is nothing in your program to prevent the stack overflowing - you
ASSUME that your limits are below the stack size, but you cannot guarantee
it. It is not an algorithm control device

>>> and it is also a very
>>> bad coding idea, compared to analyzing how many recursions are required
>>> to meet the program's goals and setting that limit.

How can you possibly know how many recursions are required to meet the
program goals? The data set of most non-trivial program *will* vary.

<snip>
> In any case, you are apparently not against snipping,
> since you snipped my relevant Google result without comment.

For my own amusement I performed your Google search. The results are not the
output of 953 programmers who are arguing for recursion limits. They do
include people reporting this as a specific error message (often from
python), a Google for '"recursion limit exceeded" error' (without single
quotes) returns 616 results! The point is that a program should not output
'recursion limit exceeded' UNTIL it has used all the stack it can - if a
program can't complete because of hardware constraints, that's not the
programs fault.

<snip>

In conclusion, what you are proposing is a debugging technique AT BEST. I
would not like to use this solution in the real world if other options are
available. In Java, much better options are available.

Relevant Pages

  • Re: Any use for recursion?
    ... In modern languages there is no overhead. ... popped back off the stack, the program counter being changed again. ... Recursion is ubiquitous in modern software. ...
    (comp.programming)
  • Re: Memory management strategy
    ... >>trading memory for speed ... The use of registers instead of the stack doesn't need inlining. ... >longer instructions to access smaller data than they were optimized for. ... square) but it didn't need recursion or some kind of stack. ...
    (comp.lang.c)
  • Re: A question about sort stable
    ... snip ... ... without using auxiliary data. ... No recursion. ... The stack, or a reasonable facsimile, is needed. ...
    (comp.lang.c)
  • Re: Is this tai-recursion?
    ... There is no difference between tail-recursion and iteration. ... That's why tail-recursion is so simple, ... fetch next instruction from instruction pointer ... instructions will manipulate the processor stack. ...
    (comp.lang.scheme)
  • Re: grassfire algorithm in java
    ... All you have is the stack overflow error message, ... >> rather long, uninformative stack trace, and no other options. ... along with the recursion count. ... void showResult{ ...
    (comp.lang.java.programmer)
Loading