In our SlugGo DB effort we have the DB return all moves known to
continue from the board state, and each move is also associated
with its winning percentage.
Cheers,
David
On 14, Oct 2006, at 5:31 PM, Don Dailey wrote:
There is another technique that may be more effective that the one I
What you are suggesting is quite similar to what human players do.
The problem is that Don is trying to bias for speed with a hash-table
like evaluation to quickly identify the board. I think that if there
were
a fast dependable algorithm for the identification of irrelevant
stones
prior to
Are the elo ratings integer or floats?
I am just wondering if partial (less than one) ratings build up or
are truncated.
Cheers,
David
___
computer-go mailing list
computer-go@computer-go.org
I have been *so* tempted to either ignore this thread or rename it ...
On 30, Nov 2006, at 10:36 AM, Wodzu wrote:
i think speed is one of most important things beacuse it affects
strength of the program ;) (if the time for move is restricted)
anyway, chosing a proper (fastest) algorithm has
On 30, Nov 2006, at 3:46 PM, Eduardo Sabbatella wrote:
David Doshay wrote:
Also, my data shows that if I doubled the time
allowed for playing,
thus using the time gained from faster execution
for doing deeper
lookahead, the results did not improve, but actually
got worse.
Sorry
On 30, Nov 2006, at 4:47 PM, Unknown wrote:
On Thu, 2006-11-30 at 14:44 -0800, David Doshay wrote:
Also, my data shows that if I doubled the time allowed for playing,
thus using the time gained from faster execution for doing deeper
lookahead, the results did not improve, but actually got
On 1, Dec 2006, at 6:15 AM, Wodzu wrote:
- Original Message - From: David Doshay [EMAIL PROTECTED]
Also, my data shows that if I doubled the time allowed for
playing, thus
using the time gained from faster execution for doing deeper
lookahead,
the results did not improve
The cooling system went down in SlugGo's machine room, and
my racks had to be powered down. So, SlugGo continues to be
on the wrong end of some bad luck and cannot play.
I hope that this gives another GNU-based player, or GNU Go
itself, a chance. I also hope that SlugGo will be able to join
the
and this gave funny things like reverse monkey jump.
David Doshay reported this too with early SlugGo (which also takes
into
account opponent good moves)
XXXO
..XO
..X.
.a.. Instead of blocking the monkey jump, O plays in a :)
I m pretty sure no human
This is an echo of my experience with SlugGo, and SlugGo has no MC
component. This is just part of trying to program Go, whatever the
algorithm.
Cheers,
David
On 5, Dec 2006, at 1:32 PM, Richard Lorentz wrote:
confusing to me is that we've tried some simple improvements to the
random
On 7, Dec 2006, at 2:09 PM, Peter Drake wrote:
Are you one of those who advocates ignoring the ko rule during MC
searches?
SlugGo is not monte carlo, but we launch parallel lookahead
sequences, so its not really different than your threads. We ignore
the ko info in the lookaheads and
Hi,
We are using the new KGS for the first time and are bumping
incrementally into the changes in the parameter file. Could someone
please post one for us?
Cheers,
David
On 14, Dec 2006, at 4:49 AM, Nick Wedd wrote:
The 2006 Slow KGS computer Go tournament will be next week,
starting
=9
rules.time=10:00
reconnect=t
-
Old server is
server.host=goserver.igoweb.org
And you should use new kgsGtp-3.3.11.tar.gz
http://www.gokgs.com/download.xhtml
Regards,
Hiroshi Yamashita
- Original Message -
From: David Doshay
=goserver.igoweb.org
And you should use new kgsGtp-3.3.11.tar.gz
http://www.gokgs.com/download.xhtml
Regards,
Hiroshi Yamashita
- Original Message -
From: David Doshay [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Sunday, December 17, 2006 2:22 AM
Subject: Re: [computer
There seem to be other modes having to do with estimated kyu level
and game pairing. I guess we need to ignore those for the tournament?
Cheers,
David
On 18, Dec 2006, at 1:00 AM, William M. Shubert wrote:
Oops, sorry for not notifying people here about the the change. I
assumed that people
It seems that so far the moves generated by SlugGo are not worth the
time they take, and in fact look worse than moves I might expect with
shorter time settings. I will be able to check later by replaying
this game (with faster lookahead) but forcing SlugGo to continue
following this game.
On 2, Jan 2007, at 11:42 PM, Chrilly wrote:
The Cotsen Open has a cash prize for the best computer program,
which I felt somewhat guilty accepting after loosing all games due
to the bug, but SlugGo was the only program entered this year, and
the cash did help to offset the cost of renting the
On 3, Jan 2007, at 1:32 PM, Sylvain Gelly wrote:
Again sorry for this incredibly long game, I was expecting that
programs resign before the end. The politness by passing is enabled
only against human.
I do not think that any apology is needed. The length of the game was
due only to a
I agree with your point that Japanese rules give an additional
advantage to the stronger player. I just see the advantage as a
natural extension of the advantage in the real world of being
more efficient in all things, including ending things. I also see
that advantage as dropping more rapidly
On 3, Jan 2007, at 2:53 PM, Christoph Birk wrote:
On Wed, 3 Jan 2007, David Doshay wrote:
Chinese, note that SlugGo started passing, indicating that it saw no
purpose in any more moves, at move 239. Here, the boundaries are
clear, the dead stones are clear to a human, and the winner is plenty
On 3, Jan 2007, at 2:53 PM, Christoph Birk wrote:
I don't understand. Using Japanese counting W still wins by 2.5 pts
after move 525.
I was rushed in my previous reply but have more time now.
My sgf reader (GoBan on a Mac) says the situation at the
end of the game is:
Black has 71 points
On 4, Jan 2007, at 5:57 AM, Petri Pitkanen wrote:
Also It is good that unsound invasions are punished. This is supposed
to be game of skill. If someone make silly invasion that does not
require answer, the more skilled player i.e player that correctly
passes should be awarded a point for his
the extra skill required as mentioned
below is applied to computer programs, and rewarded accordingly.
Cheers,
David
On 4, Jan 2007, at 12:53 PM, David Doshay wrote:
On 4, Jan 2007, at 5:57 AM, Petri Pitkanen wrote:
Also It is good that unsound invasions are punished. This is supposed
OK, now I see your perspective ... the invader has the right to
ask the defender to prove their skill, which I must say seems
very much like a gamble to me, but should not be punished
if their attempt is refuted. As such, I claim only that in this
case we have to assume that it will be the norm
On 4, Jan 2007, at 1:37 PM, Don Dailey wrote:
I'm certainly not interested in winning
points that way and would take no delight in it.
I do not take delight in picking up the points, but in my
feeling that this shows true understanding of the reality
of what is on the board. Whenever it
Thanks Chris! that's all from me this time ...
;^)
Cheers,
David
On 4, Jan 2007, at 1:46 PM, Chris Fant wrote:
Kinda like how the discussion is on this mundane stuff instead of the
interesting stuff?
On 1/4/07, Don Dailey [EMAIL PROTECTED] wrote:
On Thu, 2007-01-04 at 13:16 -0800, David
at 12:53 -0800, David Doshay wrote:
On 4, Jan 2007, at 5:57 AM, Petri Pitkanen wrote:
Also It is good that unsound invasions are punished. This is
supposed
to be game of skill. If someone make silly invasion that does not
require answer, the more skilled player i.e player that correctly
passes
And so we enter the second phase ...
On 5, Jan 2007, at 8:50 AM, Mark Boon wrote:
I think you are mistaken for the real reason of the 'second phase',
where he who passes has to pay a point. This 'second phase' only
comes into effect after both sides have passed. It's to solve
disputes in
I would suggest the minor correction to say that any non-GNU
based program would have this hope. SlugGo already does this,
but I doubt it has this meaning.
Cheers,
David
On 10, Jan 2007, at 4:38 PM, steve uurtamo wrote:
as an example, if any program could give gnugo 9 stones
under these
We generally use level 10 or 12. We have found that very rarely on
level 15 GG will run off into the weeds, never (longer than 24 hours)
to make a move. This has also been reported by others at level 18. We
have never seen this happen at level 10 or 12.
Cheers,
David
On 10, Jan 2007, at
On 16, Jan 2007, at 5:45 PM, Don Dailey wrote:
For instance if there existed 2 dimensional beings, we could not show
them 3 dimensional objects,
The answers to this are in Flatland: A romance of many dimensions a
nice short book by E.A. Abbott.
just reflections of them
slices
and any
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
At the Cotsen Open 1.5 years ago SlugGo beat an 8k, and lost on time
to his 8k brother, but the board position was a win by more than 100
points for SlugGo. But I agree that 10k is about right; SlugGo also
lost to a few 12k players.
I also agree that picking up 4 stones seems within reach,
At the 3rd International Conference on Baduk there was a paper
presented on fMRI images of the brains of expert and non-expert
players analyzing Go problems. The conclusion of the research
is that experts use far less of their brains than non-experts. The
volume of the brain used by experts is
conditions by expert players, especially when they
need to dig deep into their resources.
- Original Message
From: David Doshay [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Wednesday, January 24, 2007 10:02:18 AM
Subject: Re: [computer-go] Can a computer beat a human
I would highly recommend that you do your testing against
a different Go engine. Self-play is a weak indicator.
Cheers,
David
On 26, Jan 2007, at 5:39 PM, Don Dailey wrote:
Here are some early results on the scalability study.
Basically, level 2 beats level 1 83.6 percent of the time.
On 29, Jan 2007, at 9:17 PM, Matt Gokey wrote:
I wrote:
In computer-go where there are so many wildly different techniques
being used, some scalable to some degree or another and some
not, it
doesn't make sense to make generalizations. Whether a specific
program's scalability
On 2, Feb 2007, at 9:08 AM, [EMAIL PROTECTED] wrote:
I agree with what you say here and I'll try to make my point
better. First, my limited experience working with Monte-Carlo
simulations involved photons traveling through scattering media.
The sequences of moves described in the Mogo
UCT.
Cheers,
David
On 4, Feb 2007, at 5:13 AM, Łukasz Lew wrote:
It's time to add some features now.
I consider 3 things:
- liberties tracing
- UCT tree search
- pattern tracing
Which feature You would like to see implemented?
___
This sounds backwards.
If multi-stone suicides ARE allowed then it opens up board areas
that can then be replayed. This could lead to infinitely long games.
Cheers,
David
On 8, Feb 2007, at 7:45 AM, Chris Fant wrote:
When I added code to also prohibit multi-stone suicides in the MC
any existing simulation player). But a weaker player than
GnuGo can make an even better simulation player.
David Doshay experiments with SlugGo showed that
searching very deep/wide does not improve a lot the strength of
the engine,
which is bound by the underlying weaknesses of GNU Go.
Yes
We had this same problem and wasted a huge amount of time and
energy on trying to determine the right canonical key. I felt both
proud and stupid when I realized: it really does not make any
difference which is the canonical key, so we just declare the first
one that we find to be the canonical.
On 8, Feb 2007, at 6:42 PM, Don Dailey wrote:
On Thu, 2007-02-08 at 15:36 -0800, David Doshay wrote:
We had this same problem and wasted a huge amount of time and
energy on trying to determine the right canonical key. I felt both
proud and stupid when I realized: it really does not make any
On 9, Feb 2007, at 4:40 AM, Sylvain Gelly wrote:
Alain's point, that knowledge can both help narrow the search to
good
moves and at the same time steer you away from the best move is
absolutely true in SlugGo's case.
I completely agree with that.
However can we agree that we want a better
On 20, Feb 2007, at 2:27 PM, Chris Fant wrote:
Actually, I think what I did is equivalent to a torus. I just never
thought of it that way.
Yes, it is.
Your picture looks very much like the MC simulations of phase
transitions
in magnetic systems I did while in graduate school. Since that
The way we did this in the MC simulations of magnets was to
renormalize
the lattice using block spins. A block spin is the net result of
adding up
all of the elements in (for instance) a 3x3 block. It works for this
lattice too,
just using B and W, and the result just being B or W. Just call
Thanks for doing this so quickly!
But it was not what I was trying to ask for. The renormalization I was
suggesting would make each successive lattice smaller by a factor of
3 in each direction at each step.
Cheers,
David
On 20, Feb 2007, at 8:29 PM, Chris Fant wrote:
Is there any chance
That is correct. Down to small is enough.
But if done all the way to just one pixel it will show the winner.
Cheers,
David
On 20, Feb 2007, at 8:53 PM, Chris Fant wrote:
That is what I initially thought, but when I reread renormalize it
repeatedly, I figured you must not mean that because
Sorry, my mind jumped to the physics, and I should have said
in the limit of an infinite board.
Cheers,
David
On 21, Feb 2007, at 2:43 AM, Jacques Basaldúa wrote:
David Doshay wrote (on behalf of the 3x3 block of pixels applied
repeatedly):
But if done all the way to just one pixel
Hi Chris,
Again, thanks for the work. But again, I need to ask for a small
change to see what I am looking for.
Can you please replace each 3x3 block of pixels with a single
pixel? My mind can't do the transformation visually. I really do
want each lattice to be smaller than the previous, but
A gross simplification, but most news articles are ...
http://news.yahoo.com/s/nm/20070221/tc_nm/science_go_dc_2
Cheers,
David
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
On 21, Feb 2007, at 4:41 PM, Chris Fant wrote:
Can you please replace each 3x3 block of pixels with a single
pixel? My mind can't do the transformation visually. I really do
want each lattice to be smaller than the previous, but at the
same pixel scale.
What I am looking for is how much the
I have seen such a board for sale online. I would have to search to
find it again.
Cheers,
David
On 21, Feb 2007, at 9:29 PM, Nick Apperson wrote:
I considered making a version of go that plays with tetrahedral
geometry. It is a 3D arrangment where all nodes have 4 neighbors
and the
I will think about that, but I know that the renormalization trick is
very sensitive. I find it hard to believe that any other test could be
any more sensitive. And I know the basis for the renormalization.
One question for both of you:
Are these the result of one random playout or are they
Check out:
www.intel.com/go/teraflops
Cheers,
David
On 22, Feb 2007, at 6:10 PM, William Harold Newman wrote:
Some serious people are arguing
http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-183.html
that, among other things, the sweet spot for performance is down
around
On 23, Feb 2007, at 1:44 AM, Sylvain Gelly wrote:
The difference is small, and only the renormalizations that would show
any real differences.
http://www.lri.fr/~gelly/res_0.pbm
http://www.lri.fr/~gelly/res_1.pbm
http://www.lri.fr/~gelly/res_2.pbm
http://www.lri.fr/~gelly/res_3.pbm
:02 AM, alain Baeckeroot wrote:
Le mercredi 28 février 2007 16:49, Oliver Lewis a écrit :
On 2/23/07, David Doshay [EMAIL PROTECTED] wrote:
On 22, Feb 2007, at 9:03 PM, alain Baeckeroot wrote:
... I made very slow progress to formalize this ...
But the whole stuff is rather coherent in my
One more thought:
It would be interesting to see the degree to which following a
proximity heuristic leads to the renormalizations looking cold.
Cheers,
David
On 28, Feb 2007, at 11:07 AM, David Doshay wrote:
I do agree with Alain that beginners mix too little and random
players too much
This seems to have gotten stuck in various email delays, so I am
resending.
Sorry in advance if you get 2, but I did not see it get through.
Cheers,
David
Begin forwarded message:
From: David Doshay [EMAIL PROTECTED]
Date: 27, February 2007 6:29:01 PM PST
To: computer-go computer-go
We are also not understanding what we are seeing with SlugGo in the
Computer Room. It is playing games (we don't know where) and we
cannot seem to get a game with it.
Cheers,
David
On 2, Mar 2007, at 11:11 AM, Nick Wedd wrote:
I don't suppose this matters, but it seems odd.
A day or
On 3, Mar 2007, at 2:50 AM, Stuart A. Yeates wrote:
Personally I'd love to see functionality improvements, including:
* moving from file to generic URI references
* interruption of thinking engines
I can see the point of sending a message that *requests* the
interruption of a thinking
On 6, Mar 2007, at 8:11 AM, Joshua Nye wrote:
Has anyone tried writing code for Go what would work in parallel?
SlugGo does parallel lookahead of various possible moves.
Would something like NVIDIA CUDA be useful?
Hard to tell. There seems to be an underlying assumption that the
data is
I agree that this list is correct.
Cheers,
David
On 10, Mar 2007, at 10:39 AM, Jason House wrote:
Nick Wedd wrote:
Congratulations to MoGo for winning both divisions, with a total
of 12 wins and no losses, despite the fast time limits and large
boards! I must confess I did not expect
One of the people who worked on SlugGo a long time ago is a big C# fan.
He used Mono to get some of his C# stuff working in our OS X
environment.
Cheers,
David
On 15, Mar 2007, at 12:00 AM, Brian Slesinsky wrote:
On 3/14/07, Darren Cook [EMAIL PROTECTED] wrote:
P.S. Is anyone using C#
We have a scheduled power outage this weekend.
If you still need a bot on Monday we will put up a SlugGo.
Cheers,
David
On 20, Mar 2007, at 2:46 PM, Don Dailey wrote:
I need volunteers for testing.
___
computer-go mailing list
My vote is that if you want to trim 9x9 down to 5 minutes then I
would like to keep 19x19 longer, more like 30 minutes than 15.
Another thought would be to alternate longer and shorter periods
in your scheduling algorithm.
Cheers,
David
On 27, Mar 2007, at 2:41 PM, Don Dailey wrote:
We
Works for PPC.
Cheers,
David
On 2, Apr 2007, at 7:18 PM, Don Dailey wrote:
Presumably the darwin client runs on powerPC as well as x86
but I have not tested this client. I hope someone will
try it for me and let me know if it works.
___
It also makes sense to me that the ready player should be
the anchor ... or either anchor if there are 2.
Cheers,
David
On 4, Apr 2007, at 2:18 AM, Heikki Levanto wrote:
On Mon, Apr 02, 2007 at 02:34:47PM -0400, Don Dailey wrote:
On Mon, 2007-04-02 at 14:26 -0400, Chris Fant wrote:
Does
I will not be at the Congress, but I can play SlugGo in a tournament
that allows remote connection.
I can bring a cluster for SlugGo to Portland next year, and look
forward to doing so.
Cheers,
David
On 12, Apr 2007, at 3:33 PM, Peter Drake wrote:
The next US Go Congress will be held
I also am a member and did not get the attachments this time
Cheers,
David
On 1, May 2007, at 5:56 PM, Myriam Abramson wrote:
Hello,
I thought I might get some answers on this list.
I haven't been able to get attachments from the new format of the AGA
newsletter even though I am a
On 17, May 2007, at 8:17 AM, Brian Slesinsky wrote:
A weakness of this approach is that sometimes the best move depends on
how you plan to follow it up; a program that plays the theoretically
best move but doesn't know how to follow it up is weaker than a
program that plays safer moves.
I
I thought the first MC Go program was Gobble, 1993, by a physics guy
named Bruegmann. The technique was quite different than today. It was
done as a simulated annealing.
Cheers,
David
On 23, May 2007, at 10:29 PM, Darren Cook wrote:
I just received the June issue of Scientific American and
Yes, unpruning sounds like undoing something previously done.
With our trees we can prune and unprune, but that is not what
is being discussed. It is the branching growth of the tree, not
cutting some lines of play off and then deciding to bring them
back.
Because we are adding nodes for the
If you want to go this way, I would use progressive branching.
Cheers,
David
On 24, May 2007, at 10:56 AM, Richard Brown wrote:
Allow me to suggest a third alternative, one which I believe to be
best,
progressive grafting.
___
computer-go
We also have just become comfortable enough with libego
to be thinking about how we intended to add the go domain
knowledge for heavier playouts.
Cheers,
David
On 17, Jun 2007, at 3:15 PM, George Dahl wrote:
Posting that code would be really helpful! I too was thinking about
modifying
On 28, Jun 2007, at 8:44 PM, Jason House wrote:
Darren Cook wrote:
Can MPI be as quick as threads on a 2- or 4-core single
machine?
no, but I think you are worried about something that is such a a
small percentage of compute time that I doubt that it is significant
for a Go program. I
In the interview:
computer olympiade 2007 interview 3 (Edward de Grijs)
he says that one program is running on a cluster of 4 4-core machines
that
are located remotely.
Did they really allow access to remote computers?
Cheers,
David
On 30, Jun 2007, at 5:09 PM, Rémi Coulom
We have encountered this consistently in our non-MC/UCT program.
Things that fix an obvious problem lead to unintended consequences
that sometimes take weeks to tease apart. So far we have been able to
understand how this comes about in each situation, but still have
little ability to
On 8, Jul 2007, at 2:51 AM, chrilly wrote:
If it would be really a big challenge, there would be some money.
According to Herodotus The Histories right after king Xerxes of
Persia lost 20,000 men at Thermopylae fighting 300 Spartans and a
collection of less than 100 others, a few Arcadian
Chrilly,
It is hard to disagree with what Jim writes, but I will in a small way.
When I recently flew to Asia, the screen on the seatback in front of
me offered Go as one of its games. At its highest level it played far
worse than the average program on CGOS or in a KGS computer
There is prize money. I think it was about $3000 US last year for
first place.
No remote computing, so if like me you use a cluster, you must bring it.
Cheers,
David
On 9, Jul 2007, at 11:33 AM, chrilly wrote:
travel to Ogaki City, Japan for this year's Gifu Challenge?
Is there a price
Yes, without variations SGF is not hard. Unfortunately, doing it right
when you want to look at lots of variations at each move is quite
tricky. We need to do this to inspect what SlugGo is considering on
each of the many CPUs we are using, and every now and again we
need to revisit this code.
I think it is silly to assume that a particular player is always
listed first, and likewise silly to save a few bytes by only tagging
one.
Cheers,
David
On 17, Jul 2007, at 6:37 AM, Ben Shoemaker wrote:
- Original Message
From: Don Dailey [EMAIL PROTECTED]
cgos-gameinfo
apparently you are not missing anything.
Cheers,
David
On 19, Jul 2007, at 12:50 PM, Nick Apperson wrote:
This is an exercise in proving that computers have more memory and
processing power than before I feel. To solve a game, very little
programming skill is necessary. The strategy
other than this was a very big problem, so it likely did require a
fair amount of programming skill.
Cheers,
David
On 19, Jul 2007, at 12:53 PM, David Doshay wrote:
apparently you are not missing anything.
Cheers,
David
___
computer-go
When we deal with patterns and their rotations/reflections, we have a
canonical version that contains everything we care about, and all of
the R/R patterns have pointers to the canonical. If these are being
generated by some automated algorithm, we generate all of the R/R
as soon as we see the
Willing to accept the intuitive proof for the moment, what I see is
that
the key differences are that
1) there is no komi (black giving points to white for playing first)
2) there is a 2 point penalty for each living group.
Otherwise it does look like this is similar to any other Go rules
to govern. They promise to
be kind masters; but they mean to be masters. -- Daniel Webster
- Original Message
From: David Doshay [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Thursday, July 26, 2007 8:02:17 PM
Subject: Re: [computer-go] Differences..
Willing
something about choosing not to add another stone,
which would cover the decision not to fill one of your own last eyes.
Cheers,
David
On 26, Jul 2007, at 9:12 PM, David Doshay wrote:
The 2 points per living group comes from the fact that in order
to avoid loosing, one plays into one's own territory
OK, I see now, with more 1 point eyes for W, W will play into B's 2
areas reducing them to one eye each, and when B can make the
capturing moves W can play into its own 1 point eyes, but black can't
play into either its own or W's.
So, I agree this rule set has very different endgame
Well, it has been a pleasure and instructive for all of us!
Good luck with whatever comes next.
Cheers,
David
On 9, Sep 2007, at 12:20 PM, Sylvain Gelly wrote:
I would also take this occasion to say goodbye to you all, and thank
you for all the discussions. I now finished (and almost
This is speaking as a participant over the past 2 years who has
brought my program, SlugGo.
Programs are treated much like any other participant in their rank,
except that AGA rules do not count games against computers, so
before the parings are selected, people have been allowed to
On 13, Sep 2007, at 12:49 PM, Nick Wedd wrote:
I would also like to list the results from past years, as far as
computer participation goes. But I can't find any Cotsen results
listed on the web. Do you happen to know what program won in the
last two years?
SlugGo won the award for
And for those who missed this detail, if you (or your program) play
all 5 of the games over 2 days, then your registration fee is refunded.
Cheers,
David
On 13, Sep 2007, at 3:41 PM, Ray Tayek wrote:
At 09:17 AM 9/13/2007, you wrote:
In message
[EMAIL PROTECTED], Ray
Tayek [EMAIL
up by month.
- Don
On Thu, 2007-09-13 at 21:18 -0700, David Doshay wrote:
Hi,
We used to download monthly sql data from cgos, but I understand that
now everything is just in sgf format. Could you please let me know
how to download as many months of old data as is available?
Cheers,
David
On 17, Sep 2007, at 3:27 PM, Sylvain Gelly wrote:
Hopefully a Mac version will come.
Count us as one more research group that would greatly welcome that!
We have both G5 and Intel machines now, and will undoubtedly have
more Intel boxes in the future, so it would be best for us, if you
We tried a set of 3x3 patterns that were culled from a set of cgos
games involving the best programs. We did not have much success in
using them as predictors of eventual winner. That is not to say that
they can serve no purpose, but when we had such low success in win
prediction we felt
, David Doshay wrote:
SlugGo won the award for Best Computer Program
both of the last 2 years
David, thanks for telling us about the Cotsen Open.
Where can I find more about SlugGo's games at the Cotsen Open?
How many games were played? What were the scores? What were the
ratings of
the opponents
will ask David Doshay about this.
- - Don
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
the server if there is enough interest.
I'm wondering if a 13x13 server would be more popular.
David Doshay is going to host a site to archive games and I will
put all
the 19x19 games that have been played on the 19x19 server there for
future reference.
- - Don
1 - 100 of 222 matches
Mail list logo
