Re^3: quickness is not so obvious

Laurent_R:

Yeah, I know. I used the recursive method on purpose just 'cause it was easy and I was demonstrating recursion to a beginner. (If I recall correctly, I used the fibonacci series because it was even uglier than the traditional factorial example of recursion.) If I was actually interested in the fibonacci numbers (I don't recall actually ever needing them for anything), I'd've just created them in a loop, something like:

my @vals = (1, 1);

 . . .

sub fibo {
    my $num = (shift)-1;
    while ($#vals < $num) {
        push @vals, $vals[-1] + $vals[-2];
    }
    return $vals[$num];
}
[download]

...roboticus

When your only tool is a hammer, all problems look like your thumb.

Comment on Re^3: quickness is not so obvious Download Code

Replies are listed 'Best First'.
Re^4: quickness is not so obvious by Laurent_R (Canon) on Jan 24, 2015 at 22:32 UTC
Yeah, when I went to college/university to start to take IT courses, I was already a self-trained autodidact developer, programming in Basic, Fortran, Pascal, C and a couple of blends of assembly, though really not very advanced in any of these languages. I had written mostly spaghetti code, and I had only started to learn what was called then structured programming at least in Pascal and C (although the ideas of structures programming had been around already for many years). I knew how to write a factorial or a fibonacci function in an imperative loop form, but, because of that, I had probably more problems than my mates to grasp recursion, because it seemed so much more complicated than doing a simple loop. I worked through the recursion assignments, but was not convinced that it could be useful for anything. It is only later, when working on various types of linked-lists, trees and other similar data structures, that I started to really understand how recursion could make code much simpler and that I really adopted this way of thinking. In brief, I found that the fact and fibo classical examples of recursion did not work very well in pedagogical terms, at least not for me (and at least with traditional procedural languages). Still today, I would most probably write a fact function as a loop, and I do not see any reason to write a fibo function for anything else than an academic example, but if I needed that, I would also probably do it as a simple loop. Calculating the greatest common divisor of two numbers is the only classical academic example that I know where recursion starts to make really sense (simpler solution) and which could be moderately useful in real life problems. But when it comes to following a linked_list, traversing a directory tree on a hard disk or parsing a tree of possible actions in an operational research problem or in a game analysis, then recursion often shines, because it can really lead to much simpler code. Back to the original subject, the Memoize module is beautiful and incredibly efficient (and also mind enlightening), thank you MJD for it, and there many cases where it can be useful. But there are a number of other cases where I am using the idea of caching data in problems where that module could not help. The Schwartzian transform technique is just an example of such data caching in a different context. Je suis Charlie.	[reply]

Replies are listed 'Best First'.

Re^4: quickness is not so obvious
by Laurent_R (Canon) on Jan 24, 2015 at 22:32 UTC

I knew how to write a factorial or a fibonacci function in an imperative loop form, but, because of that, I had probably more problems than my mates to grasp recursion, because it seemed so much more complicated than doing a simple loop. I worked through the recursion assignments, but was not convinced that it could be useful for anything.

It is only later, when working on various types of linked-lists, trees and other similar data structures, that I started to really understand how recursion could make code much simpler and that I really adopted this way of thinking.

In brief, I found that the fact and fibo classical examples of recursion did not work very well in pedagogical terms, at least not for me (and at least with traditional procedural languages). Still today, I would most probably write a fact function as a loop, and I do not see any reason to write a fibo function for anything else than an academic example, but if I needed that, I would also probably do it as a simple loop.

Calculating the greatest common divisor of two numbers is the only classical academic example that I know where recursion starts to make really sense (simpler solution) and which could be moderately useful in real life problems. But when it comes to following a linked_list, traversing a directory tree on a hard disk or parsing a tree of possible actions in an operational research problem or in a game analysis, then recursion often shines, because it can really lead to much simpler code.

Back to the original subject, the Memoize module is beautiful and incredibly efficient (and also mind enlightening), thank you MJD for it, and there many cases where it can be useful. But there are a number of other cases where I am using the idea of caching data in problems where that module could not help. The Schwartzian transform technique is just an example of such data caching in a different context.

Je suis Charlie.

[reply]