bug-gnubg
[Top][All Lists]
Advanced

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

Re: [Bug-gnubg] Question about higher plies


From: Jim Segrave
Subject: Re: [Bug-gnubg] Question about higher plies
Date: Mon, 26 Jul 2004 22:51:21 +0200
User-agent: Mutt/1.4.1i

On Mon 26 Jul 2004 (16:07 +0200), ?ystein Johansen wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Joachim Matussek wrote:
> 
> | Hello,
> |
> | I was musing a little bit and following question arose.
> |
> | E.g. you are calculating a 2-ply. At 0-ply it is a contact position,
> | but depending on the move chosen it may become a race at 2-ply.
> | Do you switch neural nets within this evaluation?
> 
> I'll try to explain:
> 
> The 2-ply evaluation is the aritmetic mean value of a 0-ply the position
> after the assumed best move after all 1296 dice combination. If you
> imadgine this as a tree with 1296 leaves, it is therefor the average of
> the evaluation of all these 1296 leaves. Each of the 1296 positions are
> evaluated with its proper neural net.
> 
> However, of course it's only 441 different position evaluated, since
> there is only 21 distinct dice rolls.
> 
> Now comes some questions from me as well:
> The evaluation function is coded with recursion. I therefore assume
> EvaluatePosition must be calling ClassifyPosition for each time it's
> called. Can we improve the speed of the evaluation if the position type
> was given as a argument to the evaluation function and determined before
> the call? Of course, implementing this means we must have a function
> before calling EvaluatePosition which finds whenever a position class
> change is possible of not. (I have not thought about the function yet,
> I'm just thinking while I typing)
> 
> pseudo code:
> 
> if(position class can possibly change over n-ply):
> ~    Evaluate the position as usual.
> else:
> ~    Evaluate position with a function that take position class as arg.
> 
> Will this improve the evaluation, assuming we can find a function to
> determining if the position class can change? Maybe not! The
> ClassifyPosition function isn't the most time consuming function, is it?

I think the classification is probably cheap in CPU time compared to
the evaluation. What might be profitable is trying to save some of the
information from the classification for setting up the inputs to the
neural net. since I'd guess there's a lot of similar work being done.


-- 
Jim Segrave           address@hidden





reply via email to

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