caps->noncaps vs. goodcaps->noncaps->badcaps

[frankp]

Had not noticed in Bob's post that he did losing captures before non-captures. Someone else in the thread elaborated on the potential effect of LMR depending on how it is implemented. Like you I am pretty restrictive and only consider it on losing and non-capture moves after the first n-moves when I believe there is no threat or reason to look further.

Having scanned the responses I got the impression you might be ordering captures using (some type of) MVV/LVA rather than SEE. If this is the case I wonder how well ordered your captures are compared to those quoting opposite results to yours. Plus the obvious point that tactical positions are not the best may to test the efficiency of non-tactical move ordering :-)

[jswaff]

Had not noticed in Bob's post that he did losing captures before non-captures. Someone else in the thread elaborated on the potential effect of LMR depending on how it is implemented. Like you I am pretty restrictive and only consider it on losing and non-capture moves after the first n-moves when I believe there is no threat or reason to look further.

Having scanned the responses I got the impression you might be ordering captures using (some type of) MVV/LVA rather than SEE. If this is the case I wonder how well ordered your captures are compared to those quoting opposite results to yours. Plus the obvious point that tactical positions are not the best may to test the efficiency of non-tactical move ordering

I order interior node captures using Value(Victim)-Value(Attacker) (I was incorrectly labeling that "MVV/LVA"). For quiescence nodes I initially order captures the same way, but if the value is < 0 I do a full SEE score, because I don't do losing captures in the qsearch. The idea is to give the capture "one more chance" to prove it's "worthy" to be searched.

It's all up in the air now... lots of testing to do!

Oh - I did find one long standing bug in Prophet last night, which had to impact strength somewhat. In my "ExcludeIllegals" function, I do a straight scan through the move list looking for illegal moves. If one is found, it is swapped with the last move and the length of the list is shortened. However, I was only swapping the "move" component of the Move, not the "score" component! (I score moves as they are generated.) How much that little bug is worth is yet to be determined.

Thanks again for your replies.

--
James

--
James

[Peter Fendrich]

I have tried another scheme that outperforms number 1 by a small margin.

I save every SEE-value in a table (of all capture types). I reuse these values further down in the tree. That means that I don't have to compute the SEE value all the time. It also means that the table sometimes is terrible wrong due to changed conditions but it works for me.

/Peter