Apologize, I missed that, brilliant, def, one more vote from me! a couple of more questions that I wonder if u could share some insight on.

1: the condition that 'need' will be 0 eventually. what is the best way to rationalize it? so far, my take on this is that:

-- if we have a full balanced BT of n levels, then we must have sum(1+2+2^(n-1))=2^n-1 numeric nodes and 2^n '#' nodes => so ONE more '#' than numeric node for now

-- from there, whenever we prune ONE numeric node to form any other new tree, we will remove two associated '#' nodes and replace the numeric node with a '#', hence effectively reduce the '#' nodes by ONE, also. => so will always be ONE more '#' than numeric node

2: the above condition, however, is not where the real magic is while 'if (need == 0)' in the loop is, right? what is the best way rationalize this? so far, my take on this is something a bit rudimentary and inprecise:

-- PreOrder requires that before each '#' is reached, ALL of its parent nodes has been already reached, hence at any moment, the 'need' will be positive until the when reaching last "#', where it will become 0?

-- Haveing said that, I actually think it can be more precisely said that 'need' changes following this sequence ([init=1] -> [remains>=1] -> [@last node '#', dropto=0]) instead of what we have currently: ([init=1] -> [remains>0] -> [@last node '#', dropto=0])?

3: from the above, how would u go about using similar logic to implement In-Order and Post-Order verification? Espeically Post-Order, I think there is a great potential, as it is almost the opposite of Pre-Order, i.e. any parent node will be reached only after ALL its children nodes are reached.

-- so for Post-Order, if we still initialize 'need = 1', and apply the same rule of addition and subtraction, then I think it can be said that (though I couldn't wrap my head around to formalize):

---- 'need' changes following this sequence ([init=1] -> [dropto=-1] -> [remains<=0] ->[@last node '#', becomes=0])