dy. If I had a working implementation to play with, I might try it
myself, but I don't, and I don't have the time to set one up and try.
- Heikki
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
___
compute
Wouldn't it be more effective to choose one player randomly, and make the
other a "mirror image" of it? That way, every game would give some
information of the relevance of one setting. At least in the very
beginning...
--
Heikki Levanto "In Murp
, and far too little time... If anyone wants to
play with it, I'd love to hear of any results.
- Heikki
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
ld be slower than necesary, but maybe that would even out
with many enough done in parallel.
-H
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer
n also use board-sized bitmaps. Merging is a trivial OR operation.
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
s of a coin who plays to the crucial point first. Most likely it does
not happen on the first move. But if that is the game-deciding point, it
makes sense to give credit to who ever got to play it.
-H
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
__
makes no sense
But has anyone seen any good 0x0 patterns ;-)
-H
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
eriments, which I will have to
do before discussing them here.
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
and how much handicap to
give, and how to analyze the results. The handicap-giving program can play
under a different name, so that for CGOS it looks like a totally separate
entry, with its own rating.
-H
--
Heikki Levanto "In Murphy We Turst" heikki
s,
> such as perhaps sluggo.
Fine!
-H
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
f will play test
> games with your bot while you debug it.
Good idea! I have used cgos to debug my half-finished bots before, and felt a
bit bad about wasting the time of more serious bots.
-H
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
only serious)
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
n't get me to sucha
list...
At this point I don't care for performance, multi-threading, or even time
controls. All I want is a simple implementation of MC that is easy to read
and to tweak, so I can see if my idea works at all.
- Heikki
--
Heikki Levanto "In Murphy We Turst&
ed to know if a string has zero, one, two, or
many liberties, so the counting can be aborted early.
-H
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
On Tue, Feb 03, 2009 at 03:51:14PM -0200, Mark Boon wrote:
> On Feb 3, 2009, at 2:34 PM, Heikki Levanto wrote:
>
> >All in all, I think this is a messy and unreliable solution to a
> >problem I
> >have not seen happening.
> >
> >For what it is worth I vo
dly doesn't even have a functional program at the moment
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
moyo, where the
optimal reduction move does not get considered. That sounds tricky, and the
advantage from such is slight, he can be a tiny bit more confident of keeping
his moyo...
- Heikki
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
__
inner, with a local answer to every move the
opponent makes. Never taking sente to play elsewhere. Sounds like a receipe
for a disaster to me. But then again, I am only a kyu-level player, so I may
be wrong...
-H
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
__
layouts would make such a position look pretty
bad, and direct the program away from it - which would most often be good
playing style anyway.
- H
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
___
computer-go maili
ven decisively that 3 doesn't work, it lost 2 out of
> the 3 games I played :-)
So sorry, but as far as I can see, three games don't prove very much. Could
you please run at least 10 games more, before jumping into conclusions.
-H
--
Heikki Levanto "In Murphy
mean that you veto any move *not* on the 3rd, 4th, or 5th line,
unless there is a stone within the limit distance.
Or, to phrase it in other words:
- Any move on 3-4-5 line is OK
- Any move close than 2 or 3 points from any stone is OK
- All other moves are not OK
-H
--
Heikki Levanto &
r on larger boards.
-H
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
ople who didn't expect it, and not too bad even against those who
knew it... Not something I would dare to play in a serious tournament, but
then again, I don't play serious tournaments these days.
-H
--
Heikki Levanto "In Murphy We Turst"
gt; stone already on the board." If memory serves, David Fotland mentioned this
> at the Portland Congress. Some players favor opening moves on the fifth
> line, however.
And the occasional funny guy playing the center point...
-H
--
Heikki Levanto "In Murphy We Tu
timizing the
memory stuff made a noticeable difference.
I would also like to see hard evidence. But not badly enough to put in the
necessary work to get some ;-)
- H
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
_
ement behind the scenes, so
optimizing such can be harder... But when writing in C or C++, it does make
sense.
-H
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
___
computer-go mailing list
computer-go@computer-
but this one would still be a
good candidate. If the result was a loss, the average would drop, and so
would the error, so this move would become much less likely to be expanded.
I am sure someone who understands statistics will soon jump in and c
t costs time, reducing
the number of playouts the program can make.
Hope that explains something of the mystery
Regards
Heikki
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
___
computer-go mailing list
computer-go@comp
ng to do at work now, I would write C on my
spare time, but as things are now, I get that need satisfied all right.
-H
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
e
war here, not again...
Once again thanks for releasing your code.
-H
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
ing, less about group theory, and not being in the academia, I am not
publishing papers. I am just a programmer who likes to dabble with
programming Go, when other interests don't claim all of my spare time.
- Heikki
--
Heikki Levanto "In Murphy We Turs
Should I worry about this not being good enough?
- Heikki
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
can not win, and will resign on
the spot. I think it will be a long time before programs can do that with
confidence...
-H
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
___
computer-go mailing list
computer-go@computer
it is
possible. And if your search tree is large enough, once-in-a-thousand
situations occur all the time...
-H
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
___
computer-go mailing list
computer-go@computer-go.org
h
ent, programs can easier get to
it and display the link to the user.
- Heikki
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
With some decent large number of playouts...
-H
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
ould it make sense to have a similar page for pure MC programs (without
uct), so that we beginning developers could check that portion of our code
against known results?
-H
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
_
that the program is estimating
wrong, and actually has a small lead. Playing tight will preserve that, with
a chance of improving it a bit, whereas playing "desperate" moves will throw
it all away.
Of course, if a program knows it is going to loose, it might as well
resign.
-H
--
Heik
le and give no extra security
for anyone.
Sorry, I am in a bad mood today.
-H
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/l
rantee that all do?
I have so little time for go programming that I would not like to waste my
time on unnecessary 'security'!
- Heikki
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
___
computer-go mailing
programs (no tree
search of any kind). And/or to get a few 'in-between' data points near the
corner. Or to make the MC simulations weaker/stronger, and see how that
affects the performance of the UCT programs... If I had all the machine
power, and nothing better to do...
-H
--
Heikki
g fancy chips unless
you know where you need the extra speed.
Still, it sounds like quite a programming job! Wish I had the time and energy
for that!
- H
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
___
computer-go ma
On Wed, Jan 30, 2008 at 04:35:18PM -0500, Don Dailey wrote:
> Heikki Levanto wrote:
>
> > On Wed, Jan 30, 2008 at 03:23:35PM -0500, Don Dailey wrote:
> >
> >> Having said that, I am interested in this. Is there something that
> >> totally prevents the pr
UCT tree, even if not allowing them in the
playouts. Even then, the UCT tree has to extend to the point where this kind
of situation can occur, before the program can see it.
- Heikki
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
___
e playing! And
with that comes a number of specific needs you have to support.
- Heikki
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
having a better evaluation function helps an UCT program, but more on lower
levels of play, where its effects are greater. That there can be changes in
the scalability of UCT programs. We (may) have identified one. Will there be
another lurking somewhere?
- Heikki
--
Heikki Levanto "In M
uggested.
Good idea!
- Heikki
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
e! The strongest program can only play weaker opponents,
and weakest one can only play stronger ones. The programs near the top are
still likely to meet weaker opponents (and vice versa). Still, that is one
possible explanation for the change I see in the curves.
-H
--
Heikki Levanto "In Mu
comments
to that. Even with the risk that more data may invalidate my observation...
- Heikki
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
few days, when the new Mogos join the study and
start producing results.
- Heikki
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/
using the same code in the UCT-part
> because when I watch the program play I can see mistakes in pruning which
> otherwise only would be unseen in the playouts.
That is a valid point. Not to the theoretical discussion, but in practical
everyday life!
-H
--
Heikki Levanto "In M
Usually 3-3, 3-4, or 4-4.
-H
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
n in the MC playout, since the UCT algorithm can see that they
will not lead anywhere, and not give them so much attention.
I don't (yet?) have an UCT program, so I can not test this. Some day when I
have one, I will try to see how much it will help or hurt to try all legal
moves in the UCT
of go programming. Progress is slow, but it does happen!)
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
I guess it is early for me to speculate on that, as my engine isn't even
playing legal moves yet... Premature optimizing, and all that.
- Heikki
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
___
computer-go mail
t eye would be a
correct move (provided that it is a "real" eye and not a "false" one).
Can anyone come with concrete examples?
- Heikki
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
___
computer-go
Heikki
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
one that is in atari, and then sacrifice two stones. Some
nakade shapes also require sacrificing more than one stone...
- Heikki
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
___
computer-go mailing list
computer
take the time to optimize on that level - which is good
enough. But in theory...
- Heikki
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
___
computer-go mailing list
computer-go@computer-go.org
http://www.comp
roup first,
rather the contrary. But it shows that MC evaluations can give results so
badly off that there is not always much point in distinguishing between your
80% and 85% confidence.
Regards
Heikki
--
Heikki Levanto "In Murphy We
I am lucky and one of them turns out
to be useful.
- Heikki
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
230V system. It
seemed complex...
-Heikki
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
t
routine programming. I humbly suggest that none of us (including you :-) is
guilty of "wrong thinking".
Regards
Heikki
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
___
computer-go mailing list
computer-g
to the main memory to fetch a biece of data, it can cost more than a thousand
instructions! Luckily this is a rare occurrence, the caches are pretty
effective. But something to think about, I suppose, at least with large UCT
trees and transposition tables...
-Heikki
--
Heikki Levanto "In
compiling each one separately.
-H
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
going to be much slower than what
ever is done to find the commands...
- Heikki
who does not plan to do much more in the language war...
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
___
computer-go mailing list
On Tue, Nov 13, 2007 at 11:35:43AM -0500, Jason House wrote:
>
> On Nov 13, 2007 11:23 AM, Heikki Levanto <[EMAIL PROTECTED]> wrote:
> > There are pathological cases where this has to loop many times, flood
> > filling the one liberty to a long chain of stones, but
t just the neighbours of the
last played stone. This sounds wasteful, but I am not sure if it would not be
slower to isolate the neighbouring strings first, and then test only those.
One more experiment where I didn't get very far...
-H
--
Heikki Levanto "In Murphy
d you
like to use a language like that? I am *so* tired of the way it happily
declares a new variable when you mistype one, or finds mistyped function
names only at run time, if you happen to call that function... As a
C-programmer, I want my compiler to catch silly mistakes f
ge discussions.
There are only relatively small differences between most modern languages,
btu their libraries tend be vary more. Also, learning the language basics
should not take long for any experienced programmer, but to learn the
"proper" way to use the libraries, that can take much
legal points in advance (or at least empty ones), and pick
from that list. This list can be maintained incrementally during the MC
simulation.
Still, I like your style, and may yet decide to take advantage of your
library instead of LibEGO at least in some of my experiments.
- Heikki
--
H
On Mon, Nov 12, 2007 at 04:58:49PM +0100, Petr Baudis wrote:
> http://rover.dkm.cz/w/zzgo.git
I seem not to be able to find anything there. Is that link correct?
- Heikki
--
Heikki Levanto "In Murphy We Turst" heikki (at)
any or as few machines as you
happen to have at hand, and the fast ones don't need to wait for the slower
ones. But I think MC is so fast that this will not pay off. I seem to recall
that the quality of play does not improve much over 5000 play-outs, anyway.
-H
--
Heikki Levanto "
to see how well I can play with 1k simulations, or even less. If
I like your coding style (and license), I may even switch over to your code,
as I prefer C to C++).
- Heikki
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
I understand that it would take
a bit of programming work to implement, so I am not making any demands...
Regards
Heikki
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
___
computer-go mailing list
computer-go@compu
ce, and
could even include the whole source on that page, so that people can see it
all...
I still think using the gtp 'name' command for this is not optimal, as it is
also used in GUIs to set the program name.
Hope I clarified things more than I confused...
-H
--
for that program.
Or maybe we could simply define an extension to gtp - optional of course -
for the same kind of purpose, because the 'name' command is already used by
GUIs for a displayable name. 'program_comment' perhaps?
-H
--
Heikki Levanto
ome parameters matter.
I have decided to put up such a page for my next experiments, if I ever get
far enough to have something playing on cgos, and would certainly pass the
link to that to cgos, if there was a good place to do so.
Regards
Heikki
--
Heikki Levanto "In Murphy We Turst&quo
is requirement.
-H
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
bout to start playing with a go program again, I have some more
ideas to improve simple MC things. UCT etc will have to wait until I can see
what happens with those...
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
__
yers. And computer programs are not
quite that perfect either...
- H
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
by so small a number that it can never
overrule the raw number of victories or losses did the trick much better.
Something under 1/boardsize*simulations, so that even if all simulations end
in one part owning the whole board, the sum is not affected as much as a
single win or loss...
-H
--
Heikki
l not try to collect small points here and there, but just play
where ever - often leading to death and destruction among its own groups.
-H
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
___
computer-go mailing l
kes it easy to experiment
with the thing. Google on 'Lew libEGO' and you should find him.
- Heikki
P.S. If any of the above is not right, I am sure the better informed people
will rush in to correct me. I welcome that!
--
Heikki Levanto "In Murphy We Turst"
standards to be simple,
and constant. Especially when they are somewhat well established already...
-H
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
nefits, obvious to everyone
(which I have not yet seen), I would stuill urge people to consider those
benefits carefully, and to weigh them against the problems that arise from
having two incompatible standards.
Just my personal opinion, of course.
- Heikki
--
Heikki Levanto "In Murp
est time
hardware and time to run such an agency, and what do they get out of it?
If it has happened once, it might happen again. What would help the idea
along the way?
-H
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
__
d show their
results! The rest of us believe such a function is (almost?) impossible to
write.
-H
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
___
computer-go mailing list
computer-go@computer-go.org
http://www
e
seems overly optimistic, but on the other hand, it does not consider the
latest techniques that have shown some real promise, indicating that it may
be underestimating the future programs... Maybe there are other inventions
coming up in the near future that make the optimism more justified?
-H
't that translate to something like understanding sente?
And to the problems of local sente vs. global sente?
-H
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
___
computer-go mailing list
computer-go@computer-go.org
t; every possible way) to all else?
Well, I considered writing it in ETA [1], but my work situation is such that
soon I am expected to know python, so I might as well use computer go as an
excuse to learn it.
- Heikki
[1] http://www.miketaylor.org.uk/tech/eta/doc/index.html
--
Heikki Levanto
pting language).
If not, I may consider doing something like that myself. No point in
duplicating such work, if it is already done, and easily available, though.
Regards
Heikki
P.S. Not trying to start any sort of language war here...
--
Heikki Levanto "In Murphy We Turst" heikk
On Mon, Aug 27, 2007 at 04:22:08PM -0400, Don Dailey wrote:
>
> On Mon, 2007-08-27 at 21:35 +0200, Heikki Levanto wrote:
> > Some mail servers are starting to use greylisting, which
> > intentionally delays mails that have sender-recipient pairs they
> > have not seen befo
place of work).
Email was never intended to be a real-time protocol, so one has to
accept the occasional delay...
- Heikki
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
___
computer-go mailing list
computer-go@comp
puts stderr back to /dev/stderr, no matter how
much cgos3.tcl tries to redirect it. Of course you can also capture it
in a file, and perhaps run a tail -f on it...
-Heikki
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
___
On Fri, Jun 29, 2007 at 03:50:04PM -0400, Don Dailey wrote:
> evalgo has been updated once again. Someone noticed a minor bug in the
> time reporting which has been fixed.
>
> http://www.greencheeks.homelinux.org:8015
I see a new zip file, but still an old tar.gz.
-H
--
He
e opponents
will find you silly not passing earlier, but so be it.
-H
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
On Mon, Jun 25, 2007 at 04:33:47PM -0400, Don Dailey wrote:
> Here is how you might set up gnugo:
Thanks! that certainly looks enough to get me going.
- Heikki
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
__
. Maybe you could add a one-line example to the README, on how
to add a program (say GNU Go) as a player.
Regards
Heikki
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
___
computer-go mailing list
computer-go@computer
es its thinking. The
best it can do, is to adjust those again for the next move, if this one
turned out to take more or less time.
-Heikki
--
Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk
___
computer-go mailing list
co
1 - 100 of 174 matches
Mail list logo
