[Bug-gnubg] Re: Questions On Pruning Net

[Joseph Heled]

Please read previous posts on this. I posed some extensive testing stats on 
that. Yes, the prune net by itself is very weak. Deciding the right cutoff 
between error rate and speed is a judgment call. If you have a linux machine and 
cycles to burn, I can show you how to make this extensive testing you talk about 
using the benchmarks ....

-Joseph

james bond wrote:
> 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