[fpc-pascal] More Filter Madness

[Alberto Narduzzi]

> Well, I would advice only to use it if you *know* the maximum nesting
> depth. Otherwise it can crash easily.

I was not focusing on the problems that could arise using recursion, my 
point simply was that in this case, use of recursion was a no-need.

Of course when using recursion you _MUST_ keep an eye on the stack, but 
then, a good parameter design for the recursive function could help a 
lot. Pointers are a must; while structures/records should be avoided in 
primis, as they are stack-hungry ;-)


> A good example of stack overflow crashes is a (Pascal) software happened
> in a huge railway signal box in germany (near Hamburg) in 1995
> (http://catless.ncl.ac.uk/Risks/17.02.html#subj3). The software worked
> ok on testing but on go live it crashed with stack overflow because
> suddenly the data amount (and therefore the nesting depth) was
> significantly larger than in the tests. It is much harder to judge the
> stack memory use than the heap use and often the stack is more limited
> than the heap so you run into such issues easier.

I don't know anything in detail about this crash (shit happens, I might 
say) all I can say out of my knowledge is that maybe in that specific 
situation some possible scenarios have been underestimated.
I would ask myself why should you need recursion in that case too... but 
the approaches are different, and subjective, too.
I would have gone through a tree-node solution instead; but that's me, I 
know.
As I say, recursion is primarily for cases where/when you don't/can't 
have any finite states to start with. A railway net, by definition, 
although the possibilities of the shifts may result in a big number of 
trees, _is_ finite. IMHO. Hence, the use of recursion, again, is just a 
nice thing for your software to have, not necessarily the most adequate 
implementation of the human algorithm otherwise behind it.

I found, one day, that the easiest thing to do when you have no idea 
about how to have a computer replacing a human, is just to have as close 
as possible a representation of the human work-flow; then have a 
computer just being able to perform and cross-check it just faster.
BTW, we all know that humans don't have a stack big enough to deal with 
recursion at reasonable speeds... ;-)

Cheers, A.