Hi Nadya,


>If I'm not mistaken, I heard that from my teacher of C++ course. There was one exercise to code recoursive procedure into non-recoursive. It was about 5 years ago...

If you can get some examples it would be nice. I´d like to investigate those algorithms.
Meanwhile I challenge anyone to rewrite my example in a way that is faster and non recursive.

Walter,


>>
>>>I believe, I heard an 'acsiom' (? spell), that every recursive algorithm has a non-recursive equavelent. Non-recursive is supposed to be faster...
>>
>>Do you have any references ? If I look at the assembly language, you may be right in some (not all) cases because technically with calling a procedure recursively there might be some overhead in pushing and poping things from the stack that might not be neccesary. So technically there should be a way to program this more efficiently.
>>
>>However, the assembly language is different from 3rd and 4th generation languages and esspecially from (pcode) intepretated languages where the overhead of calling functions recursively on the average might be less than the overhead of mechanisms to eliminate the recursivism.
>>
>>In the example i´ve written in this thread I´ve recognized that the performance of the algorithm was largely depended upon the speed of interpretating the VFP programlines. In these circumstances it pays to minimize the number of programlines. IMO, it is done more efficiently with a recursive mechanism as there is no overhead in providing a mechanism to store and retrieve variable from deeper stack levels while I used the internal mechanism of hiding variables and point of execution of a recursive mechnism to the max.
>>
>>So yes: your point is valid when having total flexiblity like in assembly language. I´m not su
>>re about native compiling languanges like Delphi or C/C++. I guess it might vary from language to language and how calling a procedure is handled internally. I don´t think this rule applies to intepretated language like VFP and .NET.
>>
>>Walter,
>>
>>
>>>>Gregory,
>>>>
>>>>>I haven't compared the two. (have you ?)
>>>>>
>>>>>It is a modification of a piece of code I use, which transforms
>>>>>

>>>>>for i1 = .. to ..
>>>>>  for i2 = .. to ..
>>>>>    for ... = .. to ..
>>>>>     ...
>>>>>      for iN = ... to ...
>>>>>

>>>>>where # of i is not known at the start and is related to the # of items to combine, into a general loop using i[..]
>>>>
>>>>I think they´re not comparable because the way you describe above your program is static if you change the number of levels you´ve got to change the program. Though it is manageble as we can compile on the fly it is not a prefferable way.
>>>>
>>>>Further I did not find any working example this way that did the same thing except for george example. The recursive one was about 10 times as fast.
>>>>
>>>>>I use recursion when I can. It's just that the # of levels is not known at the start and vfp has a sort-of low limit whereas in C I would have used recursion
>>>>
>>>>For the problems described in the two threads the number of levels will not reach the maximum of 128 levels and thus will not be a problem at all.