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

Re: [computer-go] Speed and ladder bracker



I was just playing with Many Faces. Many faces seems to recognize ladder
brakers. It does not defend a cut as long as it can capture the
cutting-stone by a ladder/stair. But once one places at the other end of the
board the ladder-breaker, the cut is defended.
I made this test because J.Ryder mentioned the situation in his thesis from
1971 as a serious problem (There is obviously some progress since 1971 :-))
What I have not noticed so far is that Many Faces places itself the
ladder-breaker on the other side to be able to play the cut if the opponent
does not react. Is this because it assumes that opponent is clever enough or
because Many Faces does not "see" that it can set up this threat?
The question is closely related to speed, because this far ranging
interactions require in my understanding some global look-ahead (or a very
clever evaluation).

Best Regards
Chrilly Donninger






-----Ursprüngliche Nachricht-----
Von: David Fotland <fotland@xxxxxxxxxxxxxxxxx>
An: 'computer-go' <computer-go@xxxxxxxxxxxxxxxxx>
Datum: Sonntag, 8. August 2004 19:58
Betreff: RE: [computer-go] Score estimating


Speed is really important to go programs, since every strong program does a
great deal of local search.  One of the strongest programs,
Handtalk/Goemate, is
written almost entirely in assembler.  Many Faces of Go's core search is
highly
tuned C code.

The problem with speed vs increased strength in go programs is that strong
programs
depend on a great deal of encoded knowledge.  More computer speed doesn't
help if the
knowledge isn't there.

A simple example.  Consider an extension along the side of the board in the
opening from a group
of one color towards a group of the other color.  The optimal extension
depends on the
strength of the groups, the height of the wall,  and the number of lines
between the groups.
There are a few simple rules that appear in many introductory go books.
With this knowledge coded,
a program will make good extensions in the opening.  The optimal extensions
can't be discovered
by search, since they affect the game in ways that won't become apparent for
many moves.

David Fotland

> -----Original Message-----
> From: computer-go-bounces@xxxxxxxxxxxxxxxxx
> [mailto:computer-go-bounces@xxxxxxxxxxxxxxxxx] On Behalf Of chrilly
> Sent: Sunday, August 08, 2004 1:55 AM
> To: computer-go
> Subject: Re: [computer-go] Score estimating
>
>
> >
> >By the way: I am working in java, if anyone wants to know.
> >
> I realized that several Go projects are written in Java. I am
> an hacker from the computer-stone-age and have written the
> time critical parts of my chessprograms in Assembler. Is Java
> not considerable slower than C/C++? Or is this not true
> anymore? Or does speed not matter in a Go-Programm. Is ease
> of programming more important? (Although I see in this
> respect no big difference between C(++) and Java).
>
> My question has nothing to do with score-estimation, but I
> wanted to ask this already on other contributions who
> mentioned Java. Actually the real background of this question
> is that I have difficulties to understand the Go-programming
> paradigm. Speed is everything in chess and it is therefore
> difficult to imagine, that it should not be in Go.
>
> There were some plans to write together with Peter Woitke
> (GoAhead) a new Go-program. One of Peters basic requirements
> was: If time and/or processing power increases, the strength
> of the programm increases. Especially if time goes to
> infinity, the playing strength does the same. I had problems
> to understand this requirement at all because in
> computer-chess it is obvious. But Go programs seem to have a
> problem to use "infinite" time or processing power. One
> consequence of this paradigm is: Although there are much more
> moves than in chess, the time setting for a computer-Go game
> is much shorter. If there appear programs who could use time
> wisely one would have to discuss this settings.
>
> Best Regards
> Chrilly Donninger
>
>
>
>
> _______________________________________________
> 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/


_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://www.computer-go.org/mailman/listinfo/computer-go/