🚀 go-pugleaf

In article <xAWw8HAhApk5EwqQ@merlyn.demon.co.uk>,
Dr John Stockton  <jrs@merlyn.demon.co.uk> wrote:
>
>Where a method is defined in a recursive manner, it is better to program
>it recursively, and then to seek improvement if necessary; if the
>iterative result does not agree with the recursive, one can be sure that
>something is wrong.

I disagree. It is better to use brains before one starts coding. Such
methods might leave very poorly performing code that maybe survives
the testing but in actual use cause problems.

There are few considerations on whether to use recursion: 1) does the
recursion cut the problem in half and 2) does the recursive steps store
meaningful info that would have to be stored otherwise. If the answer
is no to9 both then it is best to avoid recursion.

>Fibonacci is a bad example, in fact, since to the mildly experienced the
>iterative and recursive approaches are both obvious; probably it should
>only be used in teaching if both solutions are involved.
>
>Neither of the two functions, as written, is good for producing the
>results of your "for" loops, or for filling an array, since in each case
>(although to a different extent) the same thing is calculated
>repeatedly.

But that meaningless on any data that might be calculated with
longints. 

If one wants to fill an array, then recursion might be a good choice:

var fibarr:array[1..46] of longint;

Function Fibd(n:integer):longint;
Begin
  if fibarr[n]=0 then
    if n<3 then fibarr[n]:=1
           else Fibarr[n]:=fibd(n-1)+fibd(n-2);
  fibd:=fibarr[n];
End;

(assumes the array has been initialized to zeros and no value greater
than 46 is used as parameter.

Osmo