Re: [computer-go] Library of Effective GO routines v 0.106
On 2/21/07, Brian Slesinsky <[EMAIL PROTECTED]> wrote: [resending; apologies if you get this twice.] Hi, Hi Brian, This is my first post to the list, so I'll introduce myself: I'm a software developer and just getting started with playing Go. I read the article in the Economist and thought that the work on Monte-Carlo based Go programs sounds promising. I'm not interested in writing my own Go program but would like to experiment with improving existing programs. Have fun ;) I built and started libego on an iMac with a 2GHz Intel Core Duo. The initial benchmark reports these results: Performance: 10 playouts 1.84255 seconds 54.2727 kpps Black wins = 43983 White wins = 56017 P(black win) = 0.43983 Are these numbers to be expected? They are correct, except rather low performance. It should be rather about 80 kpps (kilo playouts per second) There are few possible reasons for this: - You are using a laptop with power management - You changed Makefile or some source files to make it compile on Mac? Best Regards, Łukasz Lew - Brian ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Big board. Torus ?
Le mercredi 21 février 2007 02:10, Antonin Lucas a écrit : > No need for those difficulties, you can play along this board : > > http://www.youdzone.com/go.html I think this is not a torus, even if each vertice has 4 neighbours. I can easily mentally transform this into a cylinder, with an rectangular lattice and additional connection on the borders to have 4 neighbours. But there is still a weird border topology, all direction are not equivalent. Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] UCT vs MC
Hello Dmitry, Your code says that the value is backed up by sum and negation (line 26, >> value := -value). But I don't see any negative values in your sample tree, >> or values greater than one. How do you actually back up values to the >> root? >Sorry, it is value := 1-value. Thank you for pointing out the mistake. I am confused about value. What is it actually storing? I thought node[i].value stores the number of wins (for Black) for node i. Then why some of the values in Figure 1 not integer? If line 26 is now value := 1-value, then should some of the other lines also change? For example should line 7 be updateValue(node, 1-node[i].value), and line 16 be else v[i]:= (1-node.childNode [i].value)/node.childNode[i].nb+sqrt(...)? You're right there were some confusion :-). In fact it is very simple. The "-" is here because it is negamax and not minimax, so that you can always take the max of the value (but the value is negated every 2 levels). The value stored then corresponds to the value of "the player to play" in the node. It seems that node[i].value indeed keeps the number of wins for the player to play in node i. the "1-" does not exist. In Figure 1, it is an example of UCT in general case, where the reward is not always in [0,1]. And the values displayed in the nodes are the averages. So that explains the non integers and the values not in [0,1]. Can you also update all the changes in your report? Thank you. I'll try to find sometime to do that. Can't tell it will be soon though. Regards, Sylvain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Big board. Torus ?
On 2/21/07, alain Baeckeroot <[EMAIL PROTECTED]> wrote: Le mercredi 21 février 2007 02:10, Antonin Lucas a écrit: > No need for those difficulties, you can play along this board : > > http://www.youdzone.com/go.html I think this is not a torus, even if each vertice has 4 neighbours. I can easily mentally transform this into a cylinder, with an rectangular lattice and additional connection on the borders to have 4 neighbours. I agree If this were a torus, there would be links between the inner ring and the outer ring of vertexes. cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Big board
Weston Markham wrote: However, I was puzzled at the time because I had expected my inability to visualize the interactions across the edge of the board. That is true with a physical board, but a computer program can automatically copy rows and columns as necessary to support infinite scrolling in either direction. Some minor background reference could indicate where repetitions start. I think it would be fun to play on that. BTW Ladders would not finish at the edges, but they would finish at their own starting point (assuming the basic board is a square) if no ladderbreakers are found. Jacques. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Big board
David Doshay wrote (on behalf of the 3x3 block of pixels applied repeatedly): > But if done all the way to just one pixel it will show the winner. Shouldn't that require some kind of error propagation? In dithering techniques, you count the error produced, because it is not the same to count a 8 bl : 1wh as black than to count 5 bl : 4 wh as black. In the first case the error is 1/9 while in the second it is 4/9. These errors are propagated forward to the "uncounted" pixels. This way the global error is forced to be 0 (except for the last pixels processed). Otherwise, the global error should have a standard deviation proportional to sqrt(boardsize^2) = boardsize. Jacques. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re[2]: [computer-go] UCT vs MC
Thank you for your answer. However, I am even more confused now. I understand that "-" is for negamax, but I don't understand why it became "1-". I am trying to implement your algorithm and I just want to know what lines 7, 16 and 26 should be? -Original Message- From: "Sylvain Gelly" <[EMAIL PROTECTED]> To: "Dmitry Kamenetsky" <[EMAIL PROTECTED]> Date: Wed, 21 Feb 2007 11:03:08 +0100 Subject: Re: [computer-go] UCT vs MC > > Hello Dmitry, > > > >> Your code says that the value is backed up by sum and negation (line 26, > > >> value := -value). But I don't see any negative values in your sample > > tree, > > >> or values greater than one. How do you actually back up values to the > > >> root? > > >Sorry, it is value := 1-value. Thank you for pointing out the mistake. > > > > I am confused about value. What is it actually storing? I thought > > node[i].value stores the number of wins (for Black) for node i. Then why > > some of the values in Figure 1 not integer? > > > > If line 26 is now value := 1-value, then should some of the other lines > > also change? For example should line 7 be updateValue(node, > > 1-node[i].value), and line 16 be else v[i]:= (1-node.childNode > > [i].value)/node.childNode[i].nb+sqrt(...)? > > > You're right there were some confusion :-). > In fact it is very simple. The "-" is here because it is negamax and not > minimax, so that you can always take the max of the value (but the value is > negated every 2 levels). The value stored then corresponds to the value of > "the player to play" in the node. > It seems that node[i].value indeed keeps the number of wins for the player > to play in node i. the "1-" does not exist. > In Figure 1, it is an example of UCT in general case, where the reward is > not always in [0,1]. And the values displayed in the nodes are the averages. > So that explains the non integers and the values not in [0,1]. > > > > > Can you also update all the changes in your report? Thank you. > > > I'll try to find sometime to do that. Can't tell it will be soon though. > > Regards, > Sylvain > > ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Library of Effective GO routines v 0.106
If Black is the first player then why is he winning so little? If you are not using komi then Black should win more often then White. If you are using komi then the percentages should be more or less even, i.e. 50%-50%. Am I missing something? ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: Re[2]: [computer-go] UCT vs MC
Thank you for your answer. However, I am even more confused now. I understand that "-" is for negamax, but I don't understand why it became "1-". I am trying to implement your algorithm and I just want to know what lines 7, 16 and 26 should be? It became a "1-" because I said a mistake while answering. The "1" would have been here only to keep values always between 0 and 1 (instead of [0,1] if black or [-1,0] if white), IF "value" was the average win and not the total win. So my fault, sorry :-/. Is that make things clearer? Sylvain -Original Message- From: "Sylvain Gelly" <[EMAIL PROTECTED]> To: "Dmitry Kamenetsky" <[EMAIL PROTECTED]> Date: Wed, 21 Feb 2007 11:03:08 +0100 Subject: Re: [computer-go] UCT vs MC > > Hello Dmitry, > > > >> Your code says that the value is backed up by sum and negation (line 26, > > >> value := -value). But I don't see any negative values in your sample > > tree, > > >> or values greater than one. How do you actually back up values to the > > >> root? > > >Sorry, it is value := 1-value. Thank you for pointing out the mistake. > > > > I am confused about value. What is it actually storing? I thought > > node[i].value stores the number of wins (for Black) for node i. Then why > > some of the values in Figure 1 not integer? > > > > If line 26 is now value := 1-value, then should some of the other lines > > also change? For example should line 7 be updateValue(node, > > 1-node[i].value), and line 16 be else v[i]:= (1-node.childNode > > [i].value)/node.childNode[i].nb+sqrt(...)? > > > You're right there were some confusion :-). > In fact it is very simple. The "-" is here because it is negamax and not > minimax, so that you can always take the max of the value (but the value is > negated every 2 levels). The value stored then corresponds to the value of > "the player to play" in the node. > It seems that node[i].value indeed keeps the number of wins for the player > to play in node i. the "1-" does not exist. > In Figure 1, it is an example of UCT in general case, where the reward is > not always in [0,1]. And the values displayed in the nodes are the averages. > So that explains the non integers and the values not in [0,1]. > > > > > Can you also update all the changes in your report? Thank you. > > > I'll try to find sometime to do that. Can't tell it will be soon though. > > Regards, > Sylvain > > ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Library of Effective GO routines v 0.106
On Wed, Feb 21, 2007 at 05:01:56PM +0300, Dmitry Kamenetsky wrote: > > If Black is the first player then why is he winning so little? If you > are not using komi then Black should win more often then White. If you > are using komi then the percentages should be more or less even, i.e. > 50%-50%. Am I missing something? The program uses a komi of 7.5. That may not be the correct value, especially for so weak program that can not take full advantage of having the first move... You can always adjust the komi (I think it is in the automagic file) - 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/
Re: [computer-go] Big board
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 it will show the winner. Shouldn't that require some kind of error propagation? In dithering techniques, you count the error produced, because it is not the same to count a 8 bl : 1wh as black than to count 5 bl : 4 wh as black. In the first case the error is 1/9 while in the second it is 4/9. These errors are propagated forward to the "uncounted" pixels. This way the global error is forced to be 0 (except for the last pixels processed). Otherwise, the global error should have a standard deviation proportional to sqrt(boardsize^2) = boardsize. Jacques. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Big board
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 at the same pixel scale. What I am looking for is how much the renormalized lattice looks like a piece of the original lattice. How the changes progress can give me a guess at how far the system is from the equivalent of the transition temp. Cheers, David On 20, Feb 2007, at 9:36 PM, Chris Fant wrote: 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. http://fantius.com/0.bmp http://fantius.com/1.bmp http://fantius.com/2.bmp http://fantius.com/3.bmp http://fantius.com/4.bmp http://fantius.com/5.bmp http://fantius.com/6.bmp I overwrote the old images b/c there was a bug in the code anyway. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Library of Effective GO routines v 0.106
It is because it is a random play during playouts. I.e. komi about 1 is accurate. Łukasz On 2/21/07, Heikki Levanto <[EMAIL PROTECTED]> wrote: On Wed, Feb 21, 2007 at 05:01:56PM +0300, Dmitry Kamenetsky wrote: > > If Black is the first player then why is he winning so little? If you > are not using komi then Black should win more often then White. If you > are using komi then the percentages should be more or less even, i.e. > 50%-50%. Am I missing something? The program uses a komi of 7.5. That may not be the correct value, especially for so weak program that can not take full advantage of having the first move... You can always adjust the komi (I think it is in the automagic file) - 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/
Re: [computer-go] Library of Effective GO routines v 0.106
The only real change is to link against the Boost libraries I installed using DarwinPorts. Here are the diffs: -CFLAGS += -Wall #-static #-Wno-long-long -Wextra -Wno-variadic-macros +CFLAGS += -Wall -I/opt/local/include -L/opt/local/lib It's a desktop and I don't see any options for power management. Maybe it's just a difference in processors? It's a two core chip but perhaps not as fast at single-threaded apps. Adding multithreading might help. - Brian On 2/21/07, Łukasz Lew <[EMAIL PROTECTED]> wrote: On 2/21/07, Brian Slesinsky <[EMAIL PROTECTED]> wrote: > [resending; apologies if you get this twice.] > > Hi, Hi Brian, > > This is my first post to the list, so I'll introduce myself: I'm a > software developer and just getting started with playing Go. I read > the article in the Economist and thought that the work on Monte-Carlo > based Go programs sounds promising. I'm not interested in writing my > own Go program but would like to experiment with improving existing > programs. Have fun ;) > > I built and started libego on an iMac with a 2GHz Intel Core Duo. The > initial benchmark reports these results: > > Performance: > 10 playouts > 1.84255 seconds > 54.2727 kpps > Black wins = 43983 > White wins = 56017 > P(black win) = 0.43983 > > Are these numbers to be expected? They are correct, except rather low performance. It should be rather about 80 kpps (kilo playouts per second) There are few possible reasons for this: - You are using a laptop with power management - You changed Makefile or some source files to make it compile on Mac? Best Regards, Łukasz Lew > > - Brian > ___ > computer-go mailing list > computer-go@computer-go.org > http://www.computer-go.org/mailman/listinfo/computer-go/ > ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: Re[2]: [computer-go] UCT vs MC
On Wed, 2007-02-21 at 16:56 +0300, Dmitry Kamenetsky wrote: > Thank you for your answer. However, I am even more confused now. I > understand that "-" is for negamax, but I don't understand why it > became "1-". I am trying to implement your algorithm and I just want > to know what lines 7, 16 and 26 should be? I'm not sure this is what you are looking for, but in negamax, scores can be negative or positive. The scores are always adjusted so that you can view positive numbers as "good" and negative as "bad" from the point of view you are referencing. So to get the score from the "other" point of view you simple negate it. But in UCT, we don't deal with negative numbers. A score is between 0 and 1, so 0.001 is almost losing and 0.999 is almost winning for example. To change 0.99 to the other players point of view in this system, where scores must be between 0 and 1, you must negate it and add 1. So 0.99 becomes: 1 - 0.99 = 0.01 I hope that is what you are asking about and that this explains it. - Don ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Big board
That board needs to have the inside edge be connected to its outside edge, in order to represent a torus. Weston On 2/20/07, Antonin Lucas <[EMAIL PROTECTED]> wrote: No need for those difficulties, you can play along this board : http://www.youdzone.com/go.html On 2/21/07, Weston Markham <[EMAIL PROTECTED]> wrote: > Somewhere online, I played a game on a torus, against someone's Java > applet that has this option. I seem to recall playing a normal game > at either 9x9 or 13x13, and then a game on the same-sized torus. I > recall the first game as being somewhat challenging to me, (a > beginner) and the second game to be somewhat hard to visualize, but > quite easy to beat the computer opponent. Of course, it is possible > that my experience in the first game helped me significantly in the > second one, so it doesn't mean much. However, I was puzzled at the > time because I had expected my inability to visualize the interactions > across the edge of the board to be a huge handicap, relative to a > program that presumably has no such difficulty. > > Weston ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Big board
(oops. Other people have already pointed this out, in an appropriately re-named thread.) On 2/21/07, Weston Markham <[EMAIL PROTECTED]> wrote: That board needs to have the inside edge be connected to its outside edge, in order to represent a torus. Weston ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] UCT article
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/
Re: [computer-go] UCT article
This is much better than the article in zdnet.com. They shortened the quote to be, "We are not far from reaching the level of a professional Go player". At least Yahoo didn't butcher the quote and give an entirely incorrect impression. http://news.zdnet.com/2100-3513_22-6161042.html --- David Doshay <[EMAIL PROTECTED]> wrote: > 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/ > Now that's room service! Choose from over 150,000 hotels in 45,000 destinations on Yahoo! Travel to find your fit. http://farechase.yahoo.com/promo-generic-14795097 ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] UCT article
my favorite line: "In Go all marbles are identical..." s. - Original Message From: David Doshay <[EMAIL PROTECTED]> To: computer-go ; Chris Garlock <[EMAIL PROTECTED]>; Charlie Mc Dowell <[EMAIL PROTECTED]> Sent: Wednesday, February 21, 2007 3:45:19 PM Subject: [computer-go] UCT article 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/ No need to miss a message. Get email on-the-go with Yahoo! Mail for Mobile. Get started. http://mobile.yahoo.com/mail ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] UCT article
my favorite line: "In Go all marbles are identical..." My English prevent me to understand the subtlety here. Is there any relation to "the type of stone" meaning of marble? Sylvain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] UCT article
Marbles are always spherical. Playing Go with marbles is comical. On 2/21/07, Sylvain Gelly <[EMAIL PROTECTED]> wrote: > my favorite line: > > "In Go all marbles are identical..." > My English prevent me to understand the subtlety here. Is there any relation to "the type of stone" meaning of marble? Sylvain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] UCT article
It's funny to English-speakers because when we think of marbles, we're thinking of something like this http://www.atoygarden.com/images/products/Marbles300.jpg Some games are played with marbles, but since in English the go pieces are called "stones" the concept of playing Go with marbles evokes images of white and black marbles rolling around the board. The reporter just got confused. On 2/21/07, Sylvain Gelly <[EMAIL PROTECTED]> wrote: my favorite line: > > "In Go all marbles are identical..." > My English prevent me to understand the subtlety here. Is there any relation to "the type of stone" meaning of marble? Sylvain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] UCT article
Sylvain Gelly wrote: my favorite line: "In Go all marbles are identical..." My English prevent me to understand the subtlety here. Is there any relation to "the type of stone" meaning of marble? No, not really. Here the meaning of "marbles" is that of children's toys, small spherical objects propelled at one another by means of the thumb. Children -- usually just the boys -- attempt to hit each other's marbles, or to knock them out of a circle drawn in the dirt. Sometimes the kids "play for keeps" and acquire the marbles they hit. Metaphorically, someone engage in large-stakes gambling is sometimes said to be "playing for all the marbles". And "to lose one's marbles" is a humorous way of saying "to go insane". Actually, America's founding fathers, including Benjamin Franklin, Thomas Jefferson, and George Washington, were avid marbles-players, even as "grown-ups" (adults). [I have conjectured that this was because billiards tables were difficult to obtain in eighteenth-century America.] -- Rich p.s. the "find out more" link at the bottom of your page http://www.inria.fr/futurs/ressources-1/computer-culture/mogo-champion-program-for-go-games is pointing to the wrong place, isn't it? ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] UCT article
There is also the expression, "He isn't playing with all his marbles!" I don't think the author did this by accident, instead I think he liked the sound of it. It's common for writers to take liberties like this to jazz up an article. - Don On Wed, 2007-02-21 at 14:01 -0800, Thomas Johnson wrote: > It's funny to English-speakers because when we think of marbles, we're > thinking of something like this > http://www.atoygarden.com/images/products/Marbles300.jpg > > Some games are played with marbles, but since in English the go pieces > are called "stones" the concept of playing Go with marbles evokes > images of white and black marbles rolling around the board. The > reporter just got confused. > > On 2/21/07, Sylvain Gelly <[EMAIL PROTECTED]> wrote: > > my favorite line: > > "In Go all marbles are identical..." > > My English prevent me to understand the subtlety here. > Is there any relation to "the type of stone" meaning of > marble? > > Sylvain > > ___ > computer-go mailing list > computer-go@computer-go.org > http://www.computer-go.org/mailman/listinfo/computer-go/ > > ___ > computer-go mailing list > computer-go@computer-go.org > http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] UCT article
Thank you all for your precise answers! Sylvain p.s. the "find out more" link at the bottom of your page http://www.inria.fr/futurs/ressources-1/computer-culture/mogo-champion-program-for-go-games is pointing to the wrong place, isn't it? What do you mean? You mean you can't access the page, or the content is not informative, non relevant, not interesting? ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re[4]: [computer-go] UCT vs MC
Thank you Don and Sylvain. I now understand this issue completely. One more question. Line 23 states: for i:=node.size()-2 to 0 do. The leaf node should be stored in node[node.size()-1], so why do we start at node.size()-2? Is it not necessary to update the value of the leaf node? -Original Message- From: Don Dailey <[EMAIL PROTECTED]> To: Dmitry Kamenetsky <[EMAIL PROTECTED]>, computer-go Date: Wed, 21 Feb 2007 12:54:43 -0500 Subject: Re: Re[2]: [computer-go] UCT vs MC > > On Wed, 2007-02-21 at 16:56 +0300, Dmitry Kamenetsky wrote: > > Thank you for your answer. However, I am even more confused now. I > > understand that "-" is for negamax, but I don't understand why it > > became "1-". I am trying to implement your algorithm and I just want > > to know what lines 7, 16 and 26 should be? > > I'm not sure this is what you are looking for, but in negamax, scores > can be negative or positive. The scores are always adjusted so that > you can view positive numbers as "good" and negative as "bad" from the > point of view you are referencing. So to get the score from the > "other" > point of view you simple negate it. > > But in UCT, we don't deal with negative numbers. A score is between > 0 and 1, so 0.001 is almost losing and 0.999 is almost winning for > example. > > To change 0.99 to the other players point of view in this system, where > scores must be between 0 and 1, you must negate it and add 1. So 0.99 > becomes: 1 - 0.99 = 0.01 > > I hope that is what you are asking about and that this explains it. > > - Don > > ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] GtpStatiscics
It seems that GtpStatistics (java tool that comes in the GoGui package) is not sending a quit command to my gtp player. This results in me having to manually kill the gtp player process after each run. Anyone else had this problem. My new engine is in C# (yes, it's slow). ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] GtpStatiscics
On Wednesday 21 February 2007, Chris Fant wrote: > It seems that GtpStatistics (java tool that comes in the GoGui > package) is not sending a quit command to my gtp player. This results > in me having to manually kill the gtp player process after each run. please report GoGui bugs to the GoGui bug tracker, not to the computer-go mailing list. GtpStatistics should send a quit, but doesn't. However, it is also a good idea, if a Go engine just quits, if it gets an end-of-stream condition on its input stream. Do you not receive an end-of-stream with your C# engine? - Markus ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Big board
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 renormalized lattice looks like a piece of the original lattice. How the changes progress can give me a guess at how far the system is from the equivalent of the transition temp. The images are up: http://fantius.com/0.bmp http://fantius.com/1.bmp http://fantius.com/2.bmp http://fantius.com/3.bmp http://fantius.com/4.bmp The renormalized lattice does not look like the original lattice. The features get smaller with each renormalization. I think you can expect this result based on the chart of numbers I gave yesterday. Since the average chain size does not grow as board size grows, we are not at the right temperature. Correct? ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Big board
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 renormalized lattice looks like a piece of the original lattice. How the changes progress can give me a guess at how far the system is from the equivalent of the transition temp. The images are up: http://fantius.com/0.bmp http://fantius.com/1.bmp http://fantius.com/2.bmp http://fantius.com/3.bmp http://fantius.com/4.bmp The renormalized lattice does not look like the original lattice. The features get smaller with each renormalization. I think you can expect this result based on the chart of numbers I gave yesterday. Since the average chain size does not grow as board size grows, we are not at the right temperature. Correct? It is pretty clear to me that, if the analogy to MC simulations in magnets is of any value, the temperature of the Go game you show is hotter than optimal. If the temperature were at the transition temperature, then each of the renormalized lattices would look just like a piece that size cut from the original. Because the details all get smaller, the original lattice is on the random, or hotter, side of the transition. Thank you very much for this work. I am mulling this over ... how to cool the Go simulation slightly from the pure MC that you did. It would be great to see a similar very large board simulation from MoGo. I am wondering if the combination of UCT and patterns (and obviously the better play) shows better scaling across the renormalizations. FUN! Cheers, David ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Big board
It is pretty clear to me that, if the analogy to MC simulations in magnets is of any value, the temperature of the Go game you show is hotter than optimal. If the temperature were at the transition temperature, then each of the renormalized lattices would look just like a piece that size cut from the original. Because the details all get smaller, the original lattice is on the random, or hotter, side of the transition. Thank you very much for this work. I am mulling this over ... how to cool the Go simulation slightly from the pure MC that you did. It would be great to see a similar very large board simulation from MoGo. I am wondering if the combination of UCT and patterns (and obviously the better play) shows better scaling across the renormalizations. You're welcome. It was interesting. Yes, clearly MoGo is doing good stuff inside their playouts. I, too, would like to see if the result of a large-board MoGo playout looks any different from mine. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Big board. Torus ?
Stuart A. Yeates wrote: On 2/21/07, alain Baeckeroot <[EMAIL PROTECTED]> wrote: Le mercredi 21 février 2007 02:10, Antonin Lucas a écrit: No need for those difficulties, you can play along this board : http://www.youdzone.com/go.html I think this is not a torus, even if each vertice has 4 neighbours. I can easily mentally transform this into a cylinder, with an rectangular lattice and additional connection on the borders to have 4 neighbours. I agree If this were a torus, there would be links between the inner ring and the outer ring of vertexes. Whether it is a torus or not is irrelevant. The only thing that matters from a go game play perspective is the graph topology. If all points have 4 neighbors the actual physical shape or layout doesn't matter. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Big board. Torus ?
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 angles between each are 109 degrees. Its connection properties though are very different because of the way it it layed out. Hence, I am going to have to disagree. But if what you mean is that all that matters is the graph representation of the go board, I will agree with you there. - Nick On 2/21/07, Matt Gokey <[EMAIL PROTECTED]> wrote: Stuart A. Yeates wrote: > On 2/21/07, alain Baeckeroot <[EMAIL PROTECTED]> wrote: >> Le mercredi 21 février 2007 02:10, Antonin Lucas a écrit: >>> No need for those difficulties, you can play along this board : >>> >>> http://www.youdzone.com/go.html >> >> I think this is not a torus, even if each vertice has 4 neighbours. >> I can easily mentally transform this into a cylinder, with an >> rectangular lattice and additional connection on the borders to >> have 4 neighbours. > > I agree > > If this were a torus, there would be links between the inner ring and > the outer ring of vertexes. Whether it is a torus or not is irrelevant. The only thing that matters from a go game play perspective is the graph topology. If all points have 4 neighbors the actual physical shape or layout doesn't matter. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Big board. Torus ?
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 angles between each are 109 degrees. Its connection properties though are very different because of the way it it layed out. Hence, I am going to have to disagree. But if what you mean is that all that matters is the graph representation of the go board, I will agree with you there. - Nick ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re[2]: [computer-go] Library of Effective GO routines v 0.106
ah I see. I ran some tests and here is what I got: Komi=7.5 P(Black wins)=41.4% Komi=6.5 P(Black wins)=44.5% Komi=5.5 P(Black wins)=44.1% Komi=4.5 P(Black wins)=46.7% Komi=3.5 P(Black wins)=47.0% Komi=2.5 P(Black wins)=49.7% Komi=2.0 P(Black wins)=49.7% Komi=1.5 P(Black wins)=49.6% Komi=1.0 P(Black wins)=49.6% Komi=0.5 P(Black wins)=52.4% Black wins on average by 2 points (without komi). So for these random games a komi of 2.5 seems reasonable. Can someone also run the same experiments? -Original Message- From: Heikki Levanto <[EMAIL PROTECTED]> To: Dmitry Kamenetsky <[EMAIL PROTECTED]> Date: Wed, 21 Feb 2007 15:13:13 +0100 Subject: Re: [computer-go] Library of Effective GO routines v 0.106 > > On Wed, Feb 21, 2007 at 05:01:56PM +0300, Dmitry Kamenetsky wrote: > > > > If Black is the first player then why is he winning so little? If you > > are not using komi then Black should win more often then White. If you > > are using komi then the percentages should be more or less even, i.e. > > 50%-50%. Am I missing something? > > The program uses a komi of 7.5. That may not be the correct value, > especially for so weak program that can not take full advantage of > having the first move... > > You can always adjust the komi (I think it is in the automagic file) > > - 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/
