bug-gnubg
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gnubg] Questions on pruning net


From: Øystein O Johansen
Subject: Re: [Bug-gnubg] Questions on pruning net
Date: Thu, 25 Nov 2004 11:07:26 +0100

Just some ideas of the pruning nets.

First: I have a suspicion that the cubeful pruning net evaluations makes
the selection of the ten candidates worse than cubeless pruning net
evaluations. I have no statistical material to back this suspicion, but I'm
just thinking of this: If all moves for the pruning nets comes out as
double drop, there's no difference of the ten candidates move going to the
main net. But what happens when this ten candidates go to the main nn and
the main nn considers the resulting position as double/take or
Nodouble/take?

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 to much? And will it gain anything?

-Øystein


-------------------------------------------------------------------
The information contained in this message may be CONFIDENTIAL and is
intended for the addressee only. Any unauthorised use, dissemination of the
information or copying of this message is prohibited. If you are not the
addressee, please notify the sender immediately by return e-mail and delete
this message.
Thank you.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]