On Fri, May 15, 2009 at 11:29 AM, Raul Miller <[email protected]> wrote:
> Well... you had said "I am curious to know how can one implement algorithms > that needs recursion in J." > > I have been attempting to illustrate that, for the most point, algorithms > do > not need recursion in J. Or, as you have put it "recursion is usually > pretty > down the list of choices unless there is no other choices." > > (Except, I also feel there are always other choices.) > > Put differently: numbers themselves have recursive characteristics > and definitions [for example] so, in many cases, you can use arithmetic > to implement algorithms which "need recursion". This might feel like > "cheating" if what you really wanted was something that "looks recursive", > but recursion is a far broader topic than mere recursive invocation, and I > feel that some deep insights can be obtained if you do not divorce the > mechanism from the mathematics. > > Do my responses make sense now? > > I believe I used the wrong term then. When I said 'recursion', I implicitly assume the 'programming' sense, not necessary the arithmetic/math sense. I believe fib sequence as Devon said was a bad choice because it is a problem that doesn't need to be solved by the f n = f n -1 + f n -2 definition. Off my head, I cannot think of a readily available example though may be some form of tree walking which has nothing to do with numbers may fall in this category. I did use recursion in T-SQL of SQL Server for this kind of thing(self referencing table like manager -> employee) but that usually don't have a very deep level so stack space was not a concern. Which is also why I said, TCO sounds like a big issue but usually is not in actual usage. As almost all languages I have come across so far has other options or the problem domain would not hit the stack limitation. ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
