[Bug-gnubg] My Ideas for move filters

[Michaeldepreli]

I'm yet to be convinced by any arguments that 1 ply is weaker than 0 ply.
I think Gary is the only one who has run some tests and that 1 ply came out slightly stronger. I'm quietly confident that the problem lies in the fact that the predefined move filters for the most popular choice, World Class are set too low.
More so the search tolerance than the move limit.
Only promoting 8 moves to 1 ply is way too low for a strong and reliable setting.
This is why Skip 1 ply pruning probably showed the improvements.

What we are trying to achieve is a set of filters and play/evaluation/rollout  settings
(I think 8 is good), that will suit all needs.
Those needs being.

Level of accuracy needed
Time taken for evaluations/rollouts
Users different CPU speeds.
Here are my suggestions:

Firstly my filter ideas:

HUGE:          0.44/20--0.22/10--0.11/6--0.06/3
LARGE:      0.32/16--0.16/8--0.08/4--0.04/2
NORMAL:     0.16/8--0.08/4--0.04/2--0.03/2
NARROW: 0.12/8--0.06/4--0.03/2--0.02/2
TINY:             0.08/8--0.04/4--0.02/2--0.01/2

Here are my ideas for predefined settings:

(NEW) Grandmaster : 3 PLY NORMAL 
(NEW) Supremo: 2 PLY LARGE 
World Class: 2 PLY NORMAL 
Expert: 1-Ply HUGE
Advanced:  0 Ply 
Intermediate: 0 Ply 0.15 Noise
Casual: 0 Ply  0.50 Noise
Beginner: 0 Ply 0.7 Noise

Notice in the moves limit I have only mentioned a single number instead of  always accept x moves and add extra.
I think you should have the option to set always accept to 0  as there isn't much point evaluating a minimum number of moves if the top play at the previous ply is way ahead of the second choice.
I tested GNU at Grandmaster Level on my 1.4GHz machine and it's an perfectly acceptable even though I had to set the "always accept" to 1 instead of 0.
So for example in an opening 31 GNU wastes time evaluating ONLY 8/5 6/5  at 3 ply.

I hope I haven't overlooked anything and look forward to comments and or ideas.

Thanks and Happy New Year Everyone!