Hi George,

>Consider searching a b-tree. To me, a recursive search isn't only the best way, it's the only way. Could a non-recursive search be implemented? Probably, but I wouldn't want to maintain it.

uhhh, I don't see that. In what way was our example to search into a sorted array different from searching in a B-tree?

LPARAMETERS oRoot, cSearch
LOCAL lFound, lEnd

oNode = oRoot
DO WHILE !lFound AND !lend
    DO CASE 

       CASE !ISNULL(oNode.Left) AND oNode.Value > cSearch
            oNode = oNode.Left

       CASE !ISNULL(oNode.Right) AND oNode.Value < cSearch
            oNode = oNode.Right

       CASE oNode.Value == cSearch
            lFound = .T.

       OTHERWISE
            lEnd = .T.
ENDCASE
RETURN IIF(lFound, oNode, .NULL.)

(Example written from the top of my head, so not tested)

And of course, though it can be written recursively, I don't think it nessarely needs to be written recursively.

However, if you need to walk through the whole b-tree and do something match with it (like for axample: Give me from a series of numbers all number combinations that add up to 100, or give me all different word-number combination that can be formed out of a single phonenumber (calvins challenge)) then you've got a very difficult job in solving the problem without recursion as you have to store all possible number-combinations in process into arrays or cursors, which is really clumsy. With the recursive mechanism, the local variable values lower in the call stack are preserved, so when you return to that callstack you can use them again for further processing.

This for me makes the difference.

Walter,