Re: [computer-go] SlugGo approach: GNU vs.Goliath

[Vincent Diepeveen <diep@xxxxxxxxx>]

You guys are making jokes i hope about using floating point in evaluation.

Nothing as slow and non deterministic like floating point. Additional
certain compilers will use all kind of tricks with floating point giving
massive roundoff errors.

Vincent


At 16:12 4-1-2005 -0800, David G Doshay wrote:
>
>On 30, Dec 2004, at 6:27 AM, Mark Boon wrote:
>> I did my experiment for the
>> wrong reason as I had misinterpreted one of your posts. So rather by 
>> chance
>> I found out a few interesting things. Serendipity!?!
>
>Rather than serendipity, to me It looks more like curiosity coupled 
>with the
>work ethic required to find out.
>
>> I think I understand your SlugGo approach a lot better now than I did
>> earlier.
>> ... I can see how
>> this reduces the effect of the horizon a great deal, but I can't see 
>> yet why
>> combining the evaluation of the future board with the current board 
>> helps.
>> To me this is counter-intuitive, so I'll have to think a bit more about
>> that. Any rationale from your side why you chose to do it this way?
>
>Isn't that what a lookahead algorithm always does? return back to the 
>start
>of a sequence some information about how it turns out?
>
>> I suppose your territory/influence based evaluation doesn't account for
>> dead-groups, so you don't 'see' the threats at the end of the sequence?
>
>All we see is a single floating point number from each evaluation. The
>functions are very slightly modified GNU Go evaluation functions, and I
>have not put any time into seeing how they calculate what they do.
>
>> And
>> do you intend to keep this evaluation approach when you add branching?
>
>Yes, we are doing thing incrementally ... one change at a time is 
>preferable.
>
>> The other bit is that you generate moves for both sides. I did see 
>> this in
>> one of your posts, but didn't see the full point of it. Now I 
>> understand
>> why, you need it because you include evaluation of the current move. 
>> Since
>> for defensive moves it evaluates to no or small gain ,
>
>GNU Go values are not so simple.
>
>>  for those you need to
>> complement them with the gain for the opponents move.
>
>I do not think your view accurately captures why I do it or what we get 
>from
>generating an array of possible moves from the perspective of both 
>sides.
>
>I decided to do it because I could see an algorithm for implementing 
>the Go
>proverb: Your best move may be your opponent's best move.
>
>I think it works because it expands the search space in a way that 
>emphasizes
>urgency. We get to moves that evaluate as good for both earlier than 
>moves
>that evaluate only as best for us. Of course that is slightly unfair 
>because GNU
>Go does try to include lots of information about urgency in their move 
>values. I
>use the additional perspective to slightly modify the weighting. But 
>there surely
>are lots of times that the THEM perspective finds a big threat against 
>us that is
>not near the top of GNU Go's list. I think it is simply that it is good 
>to know
>where your best moves are, and where their best moves are, and to 
>evaluate
>sequences based upon both perspective ... with particular emphasis on 
>moves
>that are good for both. This really is simple stuff covered in every Go 
>book.
>
>> I decided not to generate the THEIRS list because I think making 
>> decisions
>> based on the opponents precise move doesn't work well. It would only 
>> work
>> well if I can decide which opponents moves are related to moves in the 
>> US
>> list, and boost those. I think this is what you do?
>
>We are moving in that direction. The original SlugGo code was written by
>students in response to requests from me and additional guidance from
>Charlie McDowell, a professor of Computer Science who was the advisor
>of the students. What ended up in the implementation is not exactly 
>what I
>wanted. The implementation as it is today results in things like the 
>"reverse
>monkey jump," where SlugGo defends against an invading monkey jump
>by moving onto the exact same place that the opponent would have jumped
>to ... obviously not optimal. There are other things that happen 
>similarly, but
>this one is easiest to see.
>
>Now that I have finished the rewrite of the code and we are satisfied 
>that
>it gives the same answers and values as before, getting this part as I 
>wanted
>it is my next task.
>
>> Do you also actually play out the oponents move as canidates? Or are 
>> they
>> only examined one ply deep?
>
>The first lists of possible moves, one each from US and THEM, is culled 
>to
>a shorter single list of candidate moves. All moves in this candidate 
>list get
>inspected to the same lookahead depth. We do keep track of which list 
>each
>candidate move came from, and US moves on or near THEM moves get a
>boost.
>
>> As to your speculations: you may be right about most of them. Recently 
>> I
>> learned that GNU Go doesn't do global lookahead at all, it's all based 
>> on
>> static evaluations. I must say this surprised me. It plays very well 
>> for a
>> program that doesn't do lookahead. So I can see that it would benefit
>> greatly from almost any form of lookahead added to it.
>
>GNU Go does do lookahead, and plenty of it. But its lookahead sequences
>are based upon a number of more local considerations. I just added the
>whole board length scale to the mix.
>
>> Goliath probably has
>> a simple evaluation compared to GNU Go, but compensates it by already 
>> doing
>> lookahead itself. This confirms something I've been saying all along,
>> improvements in computer Go should largely be sought in improving the
>> evaluation instead of increasing the number of moves it reads.
>
>I think both have value, but that evaluation is the harder problem. 
>Proper
>evaluation is required for reasonably accurate pruning of the lookahead
>tree.
>
>
>Cheers,
>David
>
>
>_______________________________________________
>computer-go mailing list
>computer-go@xxxxxxxxxxxxxxxxx
>http://www.computer-go.org/mailman/listinfo/computer-go/
>
>
_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://www.computer-go.org/mailman/listinfo/computer-go/