> take a look at some of the corner josekis, some of them has *many*
> variations (http://en.wikipedia.org/wiki/Taisha_joseki) and go for
> *many* moves (50+?). most humans can't choose the best variation that
> takes advantage of the stones in the adjacent corners ...
A couple of related comments
It is true that MC-programs has a bias towards overconcentration. But...
1) A improvements to the simulations of MC-program as implemented by MoGo and
Valkyria does diminish the problem. In fact most of the strength of these
programs from doing that. I think it is next to possible to explicitly p
2007/1/22, Darren Cook <[EMAIL PROTECTED]>:
A couple of related comments. First, in the 2-day games the pros spend
almost all their thinking time in the opening, i.e. considering
different joseki and how they work together. By the time they get into
the endgame they are playing almost all moves
> Yes, we heard that argument for years in computer chess and it never
> happened.
>
> Do you have some kind of basis for believe that?
i wouldn't argue that future algorithms can't be time-doubled beyond
the existing skill level of people, just that the current evidence is weak
that we alread
> Note that professionals do not play perfect endgame, ...
Enough, apparently, that it separates a world champion from a
run-of-the-mill 9-dan.
> Also, post-mortem analysis of pro games published in go magazines
> routinely finds some game-result changing improvements in the endgame.
Yes, though
Been following this thread pretty closely and thought I would jump in
with a thought and try to find some common ground. I think there is
truth to be found in both sides of this argument.
Of course people improve with time and so do computers with certain
algorithms. The question is about th
Direct link:
http://www.mimuw.edu.pl/~lew/download.php?file_no=8
Łukasz
On 1/22/07, Łukasz Lew <[EMAIL PROTECTED]> wrote:
Hi,
Few interesting things has happened so I decided to announce new version:
- bug-fix: komi was too big (1 point) so program as white tended to
loose by 0.5 point
-
- Oorspronkelijk bericht -
Van: Matt Gokey <[EMAIL PROTECTED]>
Datum: maandag, januari 22, 2007 6:27 pm
Onderwerp: Re: [computer-go] an idea... computer go program's rank vs
time
> Been following this thread pretty closely and thought I would jump
> in
> with a thought and try to find
Hi Matt,
What you wrote is well thought out. I give some comments.
On Mon, 2007-01-22 at 11:27 -0600, Matt Gokey wrote:
> Been following this thread pretty closely and thought I would jump in
> with a thought and try to find some common ground. I think there is
> truth to be found in both s
On 21-jan-07, at 19:27, Don Dailey wrote:
not considering biological factors
which would cut into this a bit.
There was a time when there were no time-limits in Go, which was
abused by many players by turning a game into a stamina contest. I
believe this practice was abandoned when someon
[EMAIL PROTECTED] wrote:
What if we look at it mathematically by looking at the branching
factor?
Go’s branching factor is generally considered to be about an order
of
magnitude greater than chess – perhaps a bit less, right? That
means
that after each ply go becomes another additional orde
Hi,
Few interesting things has happened so I decided to announce new version:
- bug-fix: komi was too big (1 point) so program as white tended to
loose by 0.5 point
- improve portability (if just "make" is not enough for You, please tell me)
- simple_playout::run is a simplest playout loop
He is saying this (I think):
to read m moves deep with a branching factor of b you need to look at p
positions, where p is given by the following formula:
p = b^m (actually slightly different, but this formula is close enough)
which is:
log(p) = m log(b)
m = log(p) / log(b)
We assume that a
Don Dailey wrote:
Thanks Don, overall you may have missed my point. I am not saying that
human thinking time does not help in go like in chess, but rather that
the relationship (the curve) between thinking time and strength may not
be the same between chess and go as I thought you had been as
Hello Lukasz,
On 1/22/07, Łukasz Lew <[EMAIL PROTECTED]> wrote:
> Few interesting things has happened so I decided to announce new version:
I have a few observations:
* in order to make libgoboard compile under cygwin I had to rename
"const float infinity", it wasn't used and there is a clash
Some results of Computer Go (and other computer games) events have long
been available on the old ICGA web site at
http://www.cs.unimaas.nl/icga/ . There is now a new ICGA web site at
http://www.grappa.univ-lille3.fr/icga/ with fuller information on these
events, including many game records th
Nick Apperson wrote:
He is saying this (I think):
to read m moves deep with a branching factor of b you need to look at p
positions, where p is given by the following formula:
p = b^m (actually slightly different, but this formula is close enough)
which is:
log(p) = m log(b)
m = log(p) /
On 1/22/07, Vlad Dumitrescu <[EMAIL PROTECTED]> wrote:
Hello Lukasz,
On 1/22/07, Łukasz Lew <[EMAIL PROTECTED]> wrote:
> > Few interesting things has happened so I decided to announce new version:
I have a few observations:
* in order to make libgoboard compile under cygwin I had to rename
"co
Randomization of seed may not be a good idea. For some experiments it
is better to know the starting seed and keep it the same, for others,
like play against humans, randomization is probably preferable.
I would suggest having a runtime flag that can be set either way.
Cheers,
David
On 22
At 09:27 AM 1/22/2007, you wrote:
...
Don believes there is probably no difference and
states a rule: doubling thinking time = linear improvement in play.
i agree with this over some small range of powers of two.
..., as breaking the game into regions and doing
local reading and global analy
20 matches
Mail list logo
