I care.
The issues here are three:
1. Is Recursive programming genuinely capable of being regarded as "more structured" than iterative programming, as Tomasz has written earlier today in a post above, and contrary to what many, many computer scientists have noted, during the past several decades?
2. Is recursive programming as transparent as iterative programming for the case where one is working on a GROUP project, for example, FRESH?
3. Is there a potential Doctoral thesis embedded in this controversy? Some mathematicians have no interest in academia. Some will be content to gain employment without procuring a Ph.D. Others who may be interested in an academic career, will "care", cher comrade.

I realize that this question is a private one, though it is not contained within a private message, therefore, permit me please, f0dder, though it is impolite to do so, to offer my reply to your question:
I haven't got a clue.
I would add, parenthetically, and rhetorically, i.e. not requiring any response if you find the following irritating rather than instructive:
How is your question:
a. important to the topic of the thread?
b. relevant to the question of transparency in writing a large program with several folks all struggling to achieve a common goal--FRESH?
c. pertinant to the issue (dismissed as irrelevant by comrade) raised by Tomasz, who indicated that recursion was employed in the core of FASM, not because of n quantity of nodes in a balanced binary tree, but because writing recursively yielded a "more ... structured code", when compared with an iterative version? Though I have challenged Tomasz to modify a snippet of FASM, setting the newly modified, iterative version, adjacent to the existing recursive code, so that we may all observe the manner in which the existing code yields superior readability, compared with the newly authored iterative version, f0dder, you and comrade are both VERY accomplished assembly language programmers, and both of you are quite capable of taking a tiny extract from the FASM code, and demonstrating to the rest of us, peasants, just how much "more structured" the existing code is, when compared with the newly minted iterative version. I would find that reply far more instructive, personally, than the answer to your riddle, a riddle which, I confess, I am unable to relate to the question raised by Tomasz, re: how recursion creates code which is "more nicely structured". There surely are not 2^32 opcodes to parse in creating a data structure to generate the machine code for the assembler....

log2(2^32) = 32 but that's beside the point. I mean, even for something as "unnoticeable" as this, why push the return address each time? It's not like it's a lot easier either

WOW! This has developed into a very thought-provoking debate. I've learned a lot already, and it would be really good if somebody would take up the challenge. Tomasz? or f0dder? or comrade? Just choose any piece of recursive FASM code you like...

Programming is my hobby, not my profession, and mostly I have taught myself. The only programming class I ever attended was a night-school hobby class about the "new" 6800 microprocessor back in 1979, 29 years ago now. (that's not a typo - 6800, not 68000!) But that class captured my imagination and I've been programming on and off ever since. The following year in 1980 I bought my first computer - a Z80-based machine with 16K of main RAM and 2K of video RAM... yes, kilobytes! That machine used cassette tapes for mass storage, and I wrote a kind of a Tape Operating System for it in asm. Not really enough RAM for a viable memory operating system back then...

I will admit I've never really thought about recursion v. iteration much before this thread - I guess I always thought that recursion was a nice "abstract" idea, but generally bad for practical reasons which have been discussed here. But maybe there are some good reasons to use it after all? I'm ready to be convinced, and Tom's Challenge could do it!

Abuashraf, I wonder if you're still following this thread? It was your "putc" routine that started all this... It would be good to know what you think...

I'm reading this thread,and I learnt alot from it...

Me 2... What a great debate from the worlds greatest...

Macros, recursive and other fine asm programming ideas is what bitRATE specialized in long before coming to fasm. Dealing with THE SVIN, f0dder and many other TODAY'S experts... catching on and exceeding in modern day asm programming for all and any OS in view at that moment. Sharing, breaking down facts to the bare bone core is what he learn how to do under these great friends and educators...

Never, ever, over look his thoughts, no mater what ...

Here is a piece of the world bitRAKE came from and help create ...

http://www.asmcommunity.net/board/index.php?topic=10554.0

Now let the real code war began...

sure, using recursions for factorials seems dumb, and using a (naive) kind of recusion for fibonacci numbers would seem even more dumb, since you would need approximately 2^n stack words when you wanted to calculate the n-th fibonacci number, which is just unfeasible.

But have you seen languages like Haskell?
http://en.wikipedia.org/wiki/Haskell_(programming_language)


true


Ever tried to implement a quicksort without using recursion?
It's a pain in the arse, because you got 2 possibilities to rebuild the recursive call tree:
1.) remodel the call stack outside of the CPU-stack and make the calls iteratively
2.) save current CPU-stack, and rebuild with it the call stack, and also make the calls iteratively


nope, most game graphics routines have a fairly simple code structure. You mostly have basic linear algebra, iterative loops and maybe some hardware optimisations, which all have a quiet simple code structure.

Of course there are some exceptions like recursive tesselation or recursive reflexions and iterated line/segment generations, but these are quiet uncommon, very special and often can be made fully recursion free.

Only the changing data need be stored on the stack - which is usually in the cache - verses some need to be calculated piece of address space.

The whole idea that recursion is prone to stack overflow or implies openendedness is absurd and founded in incorrect implementations / understanding. If the maximum file path is 256 characters then how deep can a file be? Less than 126 directories, and how extreme is the upper bound here! How much optimization should be invested in marginal cases when the recursive solution favors the comon mode of execution and allows for marginal cases at reduced performance.

Recursion is a form of execution compression. Often it is data driven, and it is the data which assures termination and bounds stack depth. Recursion is infinite descent, but a contradiction makes it finite. Like Darwin's "descent with modification" - survival of the fittest is modern egoism and a contradiction which will make us finite!

It isn't enough to optimize an algorithm in isolation -- we also need to look at use cases and how it works within program as a whole.

I am programming in 3D and usually I want to make "cool" stuff and linear algebra is most often not enough


Let me say this again: classical recursion is bad -- i.e where you CALL a function to perform the recursion, rather than JUMP to it. It's completely unnecessary to push the address, even if you only push maximum of 2, it's still UNNECESSARY.

"Significance" is completely SUBJECTIVE. I'm not talking about that. I'm only saying it is UNNECESSARY. and I don't know anything more objective than that