Three algorithms for tree-based ai's

First algorithm, for implementation with iterative deepening.

For each node, 
if any of its children change
    If the change causes the nodes ripple value to change
        Update this node, and ripple this up to this nodes parent
    end if
end if
next

So, as you extend a line, you see if it has any impact. If it does have an impact (for eg. one of the nodes, changes its parents value) then you ripple that up to its parent, and so on (if this is a very significant node, for eg. a checkmate, then this would ripple all the way back up to the root). Why is this helpfull? It lowers the number of computations dramatically (instead of updating everything, regardless of wether it needs to or not, you just update the things that need to be.) This also stops you from having to do ab again and again and again, just returning through the same stretch of tree a few times. (if you go through the same bit of tree a few times, imagine the time wasted for things like crafty which look that far ahead that it would go through thousands of nodes again and again). Algorithm 2- Choosing significant moves before others. In AB, if you pick the best moves first, you end up winning huge savings, so thats what you do. Basicaly you go and you determine if a move is significant (this would probably be done incrementally, and would also be used in the eval function), for eg. if you have a bishop moving out, which attacks the queen, but it is completely undefended, then that move is not significant (not very). This would probably be good for the first few ply, so that the best subtrees are searched first. (if your searching to 14 ply, you end up loosing a lot of time if you pick the wrong subtree). Perhaps ordering by the change in its evaluation function from its parent (for eg. If something major happens, you could probably tell quickly, probably because it is very very big.) Maybe both? (queen moves are done in order of eval function, then rook moves, then knight moves, then bishop moves, then pawn moves, then king moves? or maybe a penalty is placed, so that a king move, which is very good will be checked before a queen move that is very bad.) Either way, this will still return the correct answer, but most of the time it will cause a speedup (there must be sometimes where it mis-calculates and stuffs up). Algorithm 3- Random descent. Basically, you go and you send many scout probes, which make random moves, and record the evaluation at that level. (if you were to make a million evaluations, in a ply which has 2 million possible moves, then you've seen approximatly half of this level, more of the previous ply, ect. from this, in stable positions, you should be able to get a fairly desent picture of how the moves are fanning out). This is not optimal! But it should give a good idea of which move is the best one, and the probe data could be reused in a later ab search (in a transposition table, and in AB values). Any opinions on these? Good? Bad? any improvements? any comments? From, Nice coder