Re: Joseki libraries (was: Re: computer-go: About Viking)

[magnus.persson@xxxxxxxxxx]

On 14 Jan 01, at 17:41, David Fotland wrote:

> 
> I think of Joseki as distilled useful knowledge that hundreds of pros
> have collected over several centuries.  Even if I had a program of pro
> strength, I don't think I could expect that program to find joseki
> moves consistently, since I don't think that pro-strength players
> could find such moves from first principles.  It's hard enough to make
> a program of amateur Dan strength.  Denying it access to centuries of
> accumulated knowledge seems foolish :)

Of course! According to popular beleif a Viking was a brute villain 
that did not behave properly and smashed higher civilization to 
pieces just for the fun of it...

... but most of them was really just very skilled sailors and traders.
 
But is it not a potential problem with joseki that the program cannot 
follow up properly? Might it not often be better for the program to 
plod along its own sluggish simpleminded moves? Do you know 
what the joseki library does for your program in strength?

> Of course your program should be prepared for any move played 
against
> it, so it should have lots of general opening knowledge as well.  A
> joseki library should not be used blindly, or instead of general
> opening knowledge.
> 
> It seems like if you are a purist, and don't want to add explicit
> joseki knowledge to your program, you should also refuse to add 
any
> pattern knowledge for move generation :)  After all, Joseki moves 
are
> just one more set of patterns.

You are correct. I am a purist. And the purist generates moves like 
as follows :-)

Moves are generated (with patterns) for *any* point that could be a 
*possible good move* (dame filler or better) . If I see a point that is 
not generated and which could be a move to consider - then a 
pattern is added. In a complex middle game situation my program 
generates over 100 moves (from a pattern database of about 400 
patterns).

The the idea is that evaluation only decides which move is the best.

My problem is that there is not time to evaluate more than perhaps 
20 of them. And as a purist I refuse to add priorities to the patterns. 
:-) ...

In my current implementation I have experimented with reusing the 
evaluation values of the last move selection as priorities. I also skip 
reevaluation of moves that only affected groups that has not been 
"touched" since the move was evaluated.

There are two *major* flaws with this approach. When the fullboard 
evaluaton of a move gets to slow. The program will look at perhaps 
less than 10 moves at a time and then it will never have time to 
evaluate all new moves that has not been evaluated even once in 
the history of the game. it can then happen that it starts to play 
randomly because it lack tha abilty to evaluate moves in a proper 
order. 

The second flaw is that skipping reevaluation probably is not very 
safe in the current implementation (the true value of the move has 
changed without the program thinking so). It is not a bad idea but it 
does not work perfectly in my program and I guess that it very hard 
to implement in any program if it has not been properly designed to 
allow for this from the very start.

best purest wishes
Magnus