Move ordering at the root

[jmcd]

I have read posts on here in the past where people had talked about how it can be effective to order moves differently at the root based on their past scores or node counts. I recently tried this out myself after making a separate AlphaBetaRoot function and it has only weakened my engine with both the node and past score methods. Is this actually something worth doing?

[pepechuy]

Hi.

There are way too many interactions among the different components of chess engine: evaluation, search, move ordering, hash tables, etcetera.
You have already made a lot of decisions regarding search, evaluation... so this particular change in root move ordering might be useless for you at this stage.
For other engines, it can be an improvement.
And even for a future version of your own engine (after some significant changes in other aspects), it could well be an improvement.
It is an idea you might retry later. The important thing is that there is a sound logic behind them:
(1) Ordering by move count. A suboptimal move (at certain depth) with a big node count is "difficult to refute", so it might actually be good... the best move with a deeper search.
(2) Ordering by past scores. Well, I must admit I do not understand the logic behind this. But if it works for some people, there is little loss in trying it every now and then.

Greetings.

[jmcd]

Are there any examples of engines that use separate functions for alphabeta and alphabetaroot? I'd like to see if I am missing something in my implementation

[diep]

I have read posts on here in the past where people had talked about how it can be effective to order moves differently at the root based on their past scores or node counts. I recently tried this out myself after making a separate AlphaBetaRoot function and it has only weakened my engine with both the node and past score methods. Is this actually something worth doing?

Yes i probably was one of first on planet to do this but we'll never know whether someone in the 1980s or start 90s already was doing it. Most likely someone did as it is total trivial to do

You can do it really simple in the root. Initially you order in normal manner. The each iteration when a move fails high you put it closer to the first move and when it makes it to a PV, it's the first move. So basically Diep searches first moves that were old mainlines followed by the fail highs. At least that was the intention

If you look back at old codes you always find problems there caused by implementation bugs

This entire concept is not new. Much known about in the 1990s

Would need to lookup whether moves in the root can be reduced

[diep]

Are there any examples of engines that use separate functions for alphabeta and alphabetaroot? I'd like to see if I am missing something in my implementation

You can use some 'if then else' statements there. Saving out even those if's - wouldn't be surprised if some assemblercoders in the past did do so.

More sense it makes to have different functions for when searching the PV versus the rest being a nullwindow.

In Diep i'm not doing all that. I use 'if then else'