Re: [computer-go] Elo and handicap matching
If some bot can be setup to play on kgs for enough time to get a solid rank and then put on cgos to get an elo rating with the same configuration we could find a formula to convert elo to kgs ranks. For sure, this is not perfect but I think is good enought. Tom On Tue, Dec 04, 2007 at 05:30:15PM -0500, Don Dailey wrote: The only issue is that I don't know if GnuGo is representative of 19x19 to 9x9 go strength. I am interested in knowing how a human 19x19 scales down to 9x9 play. It's well known that programs scale up poorly. However, this data should still be quite useful. - Don -- Thomas LavergneEntia non sunt multiplicanda praeter necessitatem. (Guillaume d'Ockham) [EMAIL PROTECTED]http://oniros.org ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Elo and handicap matching
I suggest to make the bots play on kgs but on 9x9 versus human, so we could known approximatively the level of theses bots against human. We can also know the relative strenght of these bots against other bots on cgos in the same conditions (i.e. board size, timing, rules...) so we could estimate the level of all the bots against human. I don't want to mix 19x19 and 9x9. This is far from perfect because human ranks was not fixed on 9x9 but on 19x19, but I think for humans ranks on both size are corelated. As preivously said by me and others humans ranks on 9x9 are not fully corelated on 9x9 and 19x19, I known some people whom I can give 4 or 5 stones on 19x19 but beat me on 9x9 on even games because they practised a lot more than me at this size, but on kgs theses ranks are roughly corelated. Tom On Thu, Dec 06, 2007 at 02:05:39PM -0500, Don Dailey wrote: Lavergne Thomas wrote: If some bot can be setup to play on kgs for enough time to get a solid rank and then put on cgos to get an elo rating with the same configuration we could find a formula to convert elo to kgs ranks. For sure, this is not perfect but I think is good enought. Here are the issues. You want to know how good a 19x19 HUMAN 1 dan player would do on CGOS playing 9x9.This is because there is no real ranking system for 9x9 and yet you would like to be able to say that program xyz plays 2 dan strength, even though the ranking system wasn't really designed for 9x9 Go. We just need a point of reference so that we can say in general terms that a program like Mogo on CGOS is playing 2 dan strength (or whatever it really is.) But most of us feel that you cannot do this with GO programs - you need humans. For instance you could take GnuGo, get a 19x19 rating and then play on 9x9 CGOS and use it as a reference point.However GnuGo was not designed to play 9x9 go. My own program Lazarus is terrible at 19x19 but pretty good at 9x9. It could probably give a low kyu player a really good game on 9x9 but it would be easily beat at 19x19 - so it's not a good way to standardize.I believe GnuGo is more balanced in this way - but it's probably a bad idea in general to figure it this way. Your idea is fine for 19x19 CGOS. - Don Tom On Tue, Dec 04, 2007 at 05:30:15PM -0500, Don Dailey wrote: The only issue is that I don't know if GnuGo is representative of 19x19 to 9x9 go strength. I am interested in knowing how a human 19x19 scales down to 9x9 play. It's well known that programs scale up poorly. However, this data should still be quite useful. - Don ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ -- Thomas LavergneEntia non sunt multiplicanda praeter necessitatem. (Guillaume d'Ockham) [EMAIL PROTECTED]http://oniros.org ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Speed of generating random playouts
It come from me ;-) This was a sequel of the first brute force I have used. I must start it with a number, and it search from this one the first number bigger that doesn't violate the violate the tests, add it to the list and repeat this until it have enough numbers. This implementation was very slow and starting with a higher number than 1 improve a bit performance. The next version used a bitfield to track all numbers that will violate the law according to the previously generated numbers and just scan it to find the next, add it to the set and update the bitfield. But this type of brute force search will not found (and doesn't have) the optimal sequence, because it never go back. Tom On Thu, Nov 15, 2007 at 03:44:56PM -0500, Chris Fant wrote: On Nov 15, 2007 3:20 PM, Eric Boesch [EMAIL PROTECTED] wrote: On 11/14/07, Chris Fant [EMAIL PROTECTED] wrote: Based on more recent emails, this may not be useful anymore, but I have a list of 361 32-bit numbers that satisfy these properties in case anyone is interested. I'd be interested in your implementation tricks. Where did the number 17 come from? 17 didn't come from me. Here's how I made my list: Start with 500 random numbers. Throw out the ones that violate the tests. Hope that you are left with enough (361). This actually worked all the way down to 15-bit numbers. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ -- Thomas Lavergne Le vrai rêveur est celui qui rêve de l'impossible. (Elsa Triolet) [EMAIL PROTECTED] http://reveurs.org ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Speed of generating random playouts
On Tue, Nov 13, 2007 at 04:11:24PM -0500, Imran Hendley wrote:
I definitely understand the idea now, and it looks very good. However
this implementation could break:
Say we have pseudoliberties at intersections: 99,100,101. We sum those
up to get 300, divide by the number of pseudoliberties - 3, get back
100, check to see if 100 is a liberty, and since it is we conclude
that we have one liberty at intersection 100 that we counted three
times, and hence our string is in atari.
So we cant use numbers 1..81
Let elaborate a little more on this. We want one number for each cells :
nums = {n1, n2, n3, ..., n81}
And we want the following properties :
for any a, b in nums :
(a + b) / 2 is in nums -- a == b
for any a, b, c in nums :
(a + b + c) / 3 is in nums -- a == b == c
for any a, b, c, d in nums :
(a + b + c + d) / 4 is in nums -- a == b == c == d
If we have this we are sure to don't have problems like you pointed.
Using brute force search, I've produced the following sequence of
numbers :
[17, 18, 21, 30, 49, 86, 134, 274, 590, 1061, 1348, 2301, 3005, 4805,
7609, 11157, 17802, 19393, 29046, 31538, 41442, 49154, 74823, 97358,
134625, 148826, 217801, 234930, 294657, 402550, 452686, 610274,
726514, 885190, 1040877, 1070361, 1337862, 1611001, 1829345, 1962193,
2308061, 3007701, 3133837, 4007989, 4727218, 4883797, 5546029, 7454733,
8548661, 9547305, 11552366, 13177582, 13697142, 14689461, 15538838,
15733662, 21054617, 22691377, 24433197, 27274934, 31994414, 35217106,
37507258, 41114134, 45045090, 47089386, 57357330, 62400606, 68297193,
75036946, 83039110, 96477718, 110160994, 119390498, 122575210,
148912497, 156351446, 168096257, 176942297, 194310098, 211199842]
This sequence is not the best you can found, but it was quick to
generate...
But now we have another problem... We have the sum of the number of the
pseudo libertyes of a chain, and we can compute (sum / nb_plibs) but
next we have to check if the resulting number is in the list.
In some cases the number (sum / nb_plibs) will not be an integer so it
is trivialy not in nums, but for all the other cases this will require
log(81) operation using a binnary search.
Actually, when I need to check for atari on a group with 2,3,4 pseudo
liberties, I search a liberty of this group and check how mch plibs it
add to this group. I don't known if this will improve the speed but it
add a lot of complexity and atari-checking doesn't represent so much of
the calculations done by my engine to be valuable.
And the second problems is that this solution doesn't scale well. On
19x19 you need 361 numbers in your list, so even if you find a list like
this, I doubt that you can sum up the value of all the pseudo liberties
of a big group without overflowing an unsigned and you have to switch
to bigger int like int 64.
So I think John was suggesting something different in his first mail,
but I still search what it can be...
Does anyone have an idea ?
Tom
PS: I'm very sorry for my poor english
--
Thomas Lavergne Le vrai rêveur est celui qui rêve
de l'impossible. (Elsa Triolet)
[EMAIL PROTECTED] http://reveurs.org
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] 19x19 CGOS
If needed I can also offer an account on a server with space, webserver and an account for you to manage the CGOS server, but I don't have the time to manage it myself. Contact me if needed. Tom On Sat, Oct 13, 2007 at 02:31:54PM -0400, Don Dailey wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I don't think this requires a great deal of bandwidth. Right now cgos 9x9 is getting by with 1 GIG of disk space and it's not enough - so even 2-5 Gig would be adequate.I have run the server from my home cable modem connection and no problem whatsoever. It doesn't matter where the web server is as long as the CGOS server can write the data directly to a disk somewhere. I suppose it could even write via a networked file system - perhaps something like FUSE mounted via ssh (ssh filesystem) However, I might have a solution now. I'm talking right now to David Doshay about using one his university machines for this. Can I get back to you on this in case it doesn't work out? - - Don -- Thomas Lavergne Le vrai rêveur est celui qui rêve de l'impossible. (Elsa Triolet) [EMAIL PROTECTED] http://reveurs.org ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
