[Bug-gnubg] Questions On Pruning Net

[james bond]

Oystein Wrote:

Second: In the move selection within each ply (FindBestMoveInEval) the
number of moves taken to ScoreMoves() (or acef[pc]()) is ten if the size of
the movlist is ten or more. This makes me wonder... it's more likely to
miss the best move if the movelist is long than if the movelist is short.
Could it be an idea to increase the value of nPruneMoves based on the
length of the movelist? I can imagine the right move misses the ten
candidates where there's really many candidates which typical goes for
positions where low doubles are rolled. Just a suggestion out of the air:

if (ml.cMoves => 100)
   nPruneMoves = 20;

Would that slow the evaluation down too much? And will it gain anything?

.......................................................................................................
Was there some testing done to show 10 moves being the optimum choice?

Unless the prune net is weak then even 10 may be too many if for example 
there are only 2 sensible choices.
Couldn't you use the move filters (both equity diff and max moves) on this 
process?
That way you eliminate even further pointless moves and also improve the 
chances of catching the best move if the move list is long with close 
equities?
I guess Joseph would have to run some move filter selections through his 
vast database and compare accuracy gain and time saved.

_________________________________________________________________
It's fast, it's easy and it's free. Get MSN Messenger today! 
http://www.msn.co.uk/messenger