Noise move picker on ProbCut

[ratosh]

Noise move picker on ProbCut

[AndyGrant]

I've explored this in the past. If I recall the results correctly, while passing a threshold is a speedup, it causes worse move ordering for the prob cut picker. IE, when eval > rBeta, we will allow moves with negative SEE() scores -- but not they are placed at the same order as what is conventionally called a good SEE move.

I will happily try again, and see what happens.

Naturally, it SHOULD be initNoiseMovePicker(&movePicker, thread, rBeta - eval);

[AndyGrant]

http://chess.grantnet.us/viewTest/1547/

This was the original test, and it looks like I never followed up on the probcut part of the idea. I did however, add the noisyMovePicker version for the qsearch

[ratosh]

Yeah, using max would cut some moves with SEE between rBeta - eval and 0 that would be played with the current move picker. It Indeed changes the move order.

[ratosh]

Do you think is worth to limit the number of movements? Maybe use something like probCutMoves < LateMovePruningCounts[improving][1]?

[AndyGrant]

This has been tried -- I believe Stockfish was the first to do it in the open source world. They will try no more than 3/4 moves for a position.

Original idea http://chess.grantnet.us/viewTest/2069/ is going well so far, so perhaps I will again try the limiting.

[AndyGrant]

http://chess.grantnet.us/viewTest/379/
http://chess.grantnet.us/viewTest/380/
http://chess.grantnet.us/viewTest/381/

[ratosh]

Nice, almost passing the STC!