Does that mean you do the following: if your PV from previous iteration is e4 e5 Nf3 Nc6, for instance, and you arrive at a node where White's first move was not e4 but Black can also move e5 now, then you search e5 first, even though you are not "in the PV"? And similarly, if White and Black played something different from e4 e5 and now White can play Nf3, you search Nf3 first, even if Black has - for instance - a pawn on g4?Fguy64 wrote:Are you talking about me? Do I really use the PV from the previous search for move ordering at a PV node? The way I see it, at any node, if there is a PV move from the previous iteration, it gets searched first, after which a normal moveGen with normal MVV/LVA move ordering is done at that node. In other words, I'm not saving the PV node moveGen from a previous iteration, although the thought has crossed my mind, it seems that requires a HashTable no?Daniel Shawul wrote:
...
He uses the PV from previous search for move ordering at PV nodes.
I guess that is also what TSCP does and I belive it works fine, otherwise
its only benefit would be a better time management as you said.
Junior has a low branching factor and probably does some good root move ordering before
it begins non-ID search. For a TSCP like engine, BF is somwhere close to 6
so it takes almost 6x as long to complete one more iteration. That is with plain alpha-beta.
I guess that move ordering on _PV nodes _will have more effect with the addition of PVS.
regards.
If that is the case then I propose that you think about it again. You are turning the PV moves into something like killer moves, so I am not sure, but it is possible that this leads to worse move ordering than not doing it this way.
Sven