Re: [computer-go] MoGoRel3_3550pps
Sylvain Gelly wrote: 2008/1/10, [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Hi Sylvain, Have you finished your thesis? We are eager to read it:-) Hi, Yes I did! :).It is not on my website, but will (soon?). However, you should not be so eager to read it :) Cheers, Sylvain Google finds it: http://tao.lri.fr/Papers/thesesTAO/SylvainGellyThesis.pdf Rémi ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] handicap for mogo against pro ?
Don Dailey wrote: But with the type of scoring that MC does (where we optimize for winning percentage over score) it's more difficult to construct go problems. You have to construct them so that you LOSE the game if you don't play the right move, but if you do play it you win the game. Life death problems of large groups are a good start. -- GCP ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] handicap for mogo against pro ?
Hideki Kato wrote: No. Remember UCT is a sequential algorithm. Parallelizing UCT make playouts ineffective. Increasing the number of threads and/or communicating delay decreases the effectiveness of the playouts. With my experiments on a symmetrical threads implementation on a four core SMP system, winning rate against GNU Go decreases from 50.4+-1.1% to 46.7+-1.1%, which corresponds to -25 ELO, where 1.1% are the standard deviations [1]. This just shows that this SMP implementation has no *effective* speedup, but probably a effective slowdown. And so a loss of ELO is expected. I clearly stated what I meant by effective: How much faster you find the correct move. Not interesting is: how many positions you search per second or how many playouts you do per second. The fact that parallel UCT is not the same as serial UCT does not change anything at all with the above definition. Either it finds good moves faster, and hence is stronger, or it does not. -- GCP ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] handicap for mogo against pro ?
Gian-Carlo Pascutto: [EMAIL PROTECTED]: Hideki Kato wrote: No. Remember UCT is a sequential algorithm. Parallelizing UCT make playouts ineffective. Increasing the number of threads and/or communicating delay decreases the effectiveness of the playouts. With my experiments on a symmetrical threads implementation on a four core SMP system, winning rate against GNU Go decreases from 50.4+-1.1% to 46.7+-1.1%, which corresponds to -25 ELO, where 1.1% are the standard deviations [1]. This just shows that this SMP implementation has no *effective* speedup, but probably a effective slowdown. And so a loss of ELO is expected. Above are measured with fixed number of playouts. Speed is, of course, almost linearly up with the number of threads (within the number of cores). But I'm sorry I didn't read your [1] carefuly. It's my fault. I clearly stated what I meant by effective: How much faster you find the correct move. Not interesting is: how many positions you search per second or how many playouts you do per second. What is correct move? It has sense only for some artificial problems or very limited positions, and so, it cannot evaluate total performance of a program. The fact that parallel UCT is not the same as serial UCT does not change anything at all with the above definition. Either it finds good moves faster, and hence is stronger, or it does not. I agree but how to? One way I can think of is to run a program on cgos or similarbut Olivier wrote it's not allowed. -Hideki -- [EMAIL PROTECTED] (Kato) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
RE: [computer-go] visual tree (gogui extension) help request
Hi, You have to put the file vtbeta.jar in the lib directory of the gogui. For me, it is ~/Go/gogui-0.9.2/lib. vtbeta.jar uses the other files that are in this directory. Note that the visual tree is not compatible with gogui 1.x yet, only with version 0.9.x :( Visual Tree was also used by Sylvain Gelly in Mogo. I'm happy that other people are trying it, even if I don't have time to work on it now (for instance I would like to upgrade it for the gogui 1.x). However there are all the sources plus a lot of documentation on my website, so anybody can adapt it to his requirements. Best, Guillaume -Original Message- From: [EMAIL PROTECTED] on behalf of Peter Christopher Sent: Sat 12/01/2008 11:14 To: computer-go@computer-go.org Subject: [computer-go] visual tree (gogui extension) help request Hi, By any chance does anyone have a tip to help me get VisualTree working? http://www.cs.unimaas.nl/g.chaslot/vt/vt09/docs/install.html says I should run java -jar vtbeta.jar but this produces the error: Exception in thread main java.lang.NoClassDefFoundError: net/sf/gogui/utils/ErrorMessage The original page also states to store the jar in a certain lib directory I cannot find on my linux ubuntu system. Gogui does work fine. I use it regularly (great tool). Thanks in advance. Peter ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ winmail.dat___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] handicap for mogo against pro ?
Hideki Kato wrote: What is correct move? It has sense only for some artificial problems or very limited positions, and so, it cannot evaluate total performance of a program. This is true, but we are interested in search performance. So, it makes sense to evaluate on those positions where the search makes the difference, no? -- GCP ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] handicap for mogo against pro ?
I clearly stated what I meant by effective: How much faster you find the correct move. Not interesting is: how many positions you search per second or how many playouts you do per second. What is correct move? It has sense only for some artificial problems or very limited positions, and so, it cannot evaluate total performance of a program. This is true, I learned long ago that problem tests do not measure program performance well at all. However, in this case my guess is that it would be an accurate measure of effective program speedup.It's possible this assumption is wrong but I am assuming that parallelizing UCT does not change the characteristics of the playing strength in a measurable way - just the efficiency. - Don The fact that parallel UCT is not the same as serial UCT does not change anything at all with the above definition. Either it finds good moves faster, and hence is stronger, or it does not. I agree but how to? One way I can think of is to run a program on cgos or similarbut Olivier wrote it's not allowed. -Hideki -- [EMAIL PROTECTED] (Kato) ___ 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] handicap for mogo against pro ?
Gian-Carlo Pascutto wrote: Don Dailey wrote: But with the type of scoring that MC does (where we optimize for winning percentage over score) it's more difficult to construct go problems.You have to construct them so that you LOSE the game if you don't play the right move, but if you do play it you win the game. Life death problems of large groups are a good start. Yes, and you can adjust the komi in some cases to make the problem work. - Don ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] MoGoRel3_3550pps
Sylvain Gelly wrote: It looks like MoGo does respect the time_left commands from GTP, so I don't think the totalTime parameter is required in this case. What do you mean? If you don't put --totalTime, then MoGo indeed ignores time_left. If you put --totalTime, then it respect the time_left. The reason I said that was this behavior from mogo. If I start it without that switch and as for a move, it allocates 20 seconds. If I then issue a small time_left command and ask for another move, it allocates a much smaller amount of time. Here is the output: [EMAIL PROTECTED]:~/go$ ./mogo --19 initiateNodeUrgencyForShisho at root node! Load opening database openingValues_19 succeed (nbEntries=60629) (nbIllegalMoves removed 0) tried to open openingValues_19, success 1 genmove b time left: 12 secs time given for this move: 20.0 sec time shishoCheck is called. Now we have 0 shishoLocations: and 0 attackShishoLocation initiateNodeUrgencyForShisho at root node! Self train initiation time: 0.00 0.450253(81%) || 1186/ 1(12%)(72%)(54%/0.59) ||44 |12 || G4 E5 F5 E4 E6 D6 D7 E7 F6||SSP:G4 C2 H1 J9 J4 ||PSP:G4 C2 H1 J9 J4 0.436817(80%) || 4487/ 2(22%)(31%)(72%/0.59) ||89 |13 || F6 D5 E4 F5 G5 E6 F7 E7 E8 F8 ||SSP:F6 G4 C2 H1 J3 ||PSP:F6 G4 C2 H1 J3 0.476407(90%) || 5277/ 3(18%)(91%)(59%/0.54) || 190 |13 || E5 E4 F4 D4 E3 F5 D5 G4 F3 D3 ||SSP:E5 F6 D5 G4 C2 ||PSP:E5 F6 D5 G4 C2 0.454793(91%) || 11005/ 4(28%)(44%)(80%/0.56) || 275 |14 || E5 E4 D5 F4 D4 D3 C3 F5 F6 C2 ||SSP:E5 F6 D5 F5 E4 ||PSP:E5 F6 D5 F5 E4 0.47(94%) || 12436/ 5(25%)(88%)(93%/0.53) || 323 |15 || F5 H5 E2 D7 F7 G7 G6 H7 G8 H8 ||SSP:F5 E5 F6 D5 E4 ||PSP:F5 E5 F6 D5 E4 0.481018(97%) || 22284/ 6(37%)(49%)(94%/0.52) || 374 |15 || F5 H5 E2 F7 C6 D6 D5 D7 E6 C7 ||SSP:F5 E5 F6 D5 E4 ||PSP:F5 E5 F6 D5 E4 0.477984(94%) || 32022/ 7(46%)(34%)(75%/0.52) || 428 |17 || F5 H5 E2 F7 C6 D6 D5 D7 E6 C7 ||SSP:F5 E5 F6 D5 E4 ||PSP:F5 E5 F6 D5 E4 0.470916(86%) || 39111/ 8(49%)(28%)(61%/0.52) || 483 |17 || F5 H5 E2 F7 C6 D6 D5 D7 E6 C7 ||SSP:F5 E5 F6 D5 E4 ||PSP:F5 E5 F6 D5 E4 earlyCut : max1 42505; max2 11005; sum 84807 max1/sum 0.501191 ; max1/max2 3.861984 (hard 0) 0.467192(41%) || 42505/ 84807(50%)(26%)(56%/0.52) || 513 |17 || F5 H5 E2 F7 C6 D6 D5 D7 E6 C7 ||SSP:F5 E5 F6 D5 E4 ||PSP:F5 E5 F6 D5 E4 84807 simulations(average length:0) done, time used: 14.63 seconds.( 5796.8 games/sec) A B C D E F G H JABCD EFGHJ +---+ +-+ 9 | . . . . . . . . . | | 0.3568 0.4000 2.4650 0.4468 0.3739 0.2987 0.3438 0.3775 0.3531 | 8 | . . . . . . . . . | | 2.4638 0.4384 2.4519 2.4556 2.4667 2.4589 2.4645 0.3612 0.3939 | 7 | . . . . . . . . . | | 0.4314 0.5714 2.4512 2.4637 2.4521 0.4403 0.4340 0.4259 0.3842 | 6 | . . . . . . . . . | | 0.3411 2.4606 2.4569 2.4634 2.4618 0.4322 0.5333 2.4670 0.3783 | 5 | . . . . . . . . . | | 0.3688 0.4433 2.4625 0.4450 0.4548 0.4672 0.4218 0.3996 0.3436 | Black to play 4 | . . . . . . . . . | | 0.3558 0.4111 2.4648 0.0001 0.4474 2.4652 0.4343 0.4400 0.4055 | Black eaten stone(s): 0 3 | . . . . . . . . . | | 0.3318 0.4500 0.4452 0.4113 2.4602 0.4554 0.3784 0.4123 0.4050 | White eaten stone(s): 0 2 | . . . . . . . . . | | 0.3658 0.3900 0.4232 0.4286 0.3070 0.4504 0.4053 0.3831 0.3723 | 1 | . . . . . . . . . | | 0.3201 0.3807 0.3238 0.3694 0.3747 0.3673 0.4036 0.3938 0.3508 | +---+ +-+ A B C D E F G H J A B C D E F G H J +---+ +---+ 9 | . . . . . . . . . | | 0 0 0 0 0 0 0 0 0 | 8 | . . . . . . . . . | | 0 0 0 0 0 0 0 0 0 | 7 | . . . . . . . . . | | 0 0 0 0 0 0 0 0 0 | 6 | . . . . . . . . . | | 0 0 0 0 0 0 0 0 0 | Move 1: F5 5 | . . . . . (@) . . . | | 0 0 0 0 0 1 0 0 0 | White to play 4 | . . . . . . . . . | | 0 0 0 0 0 0 0 0 0 | Black eaten stone(s): 0 3 | . . . . . . . . . | | 0 0 0 0 0 0 0 0 0 | White eaten stone(s): 0 2 | . . . . . . . . . | | 0 0 0 0 0 0 0 0 0 | 1 | . . . . . . . . . | | 0 0 0 0 0 0 0 0 0 |time_left w 1 0 = genmove w time left: 1 secs time given for this move: 0.0 sec time fast end mode gives one move:D8 A B C D E
Re: [computer-go] handicap for mogo against pro ?
Gian-Carlo Pascutto: [EMAIL PROTECTED]: Hideki Kato wrote: What is correct move? It has sense only for some artificial problems or very limited positions, and so, it cannot evaluate total performance of a program. This is true, but we are interested in search performance. So, it makes sense to evaluate on those positions where the search makes the difference, no? I'm not sure but it's possible, as Don wrote, parallelizing mc/uct doesn't make its behavior change in the sense of search result will not change, ie, just decreases the efficiency of simulations. However, it's also likey that unbalanced long communication delay makes search results change. Because the order of arrivals of results of simulations may change if unbalanced (long) delay exists. Anyway, I'm implementing network parallel version of MC/UCT now and will make such things clearer. -Hideki -- [EMAIL PROTECTED] (Kato) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] handicap for mogo against pro ?
Hideki Kato wrote: What is correct move? It has sense only for some artificial problems or very limited positions, and so, it cannot evaluate total performance of a program. There are many positions where winning the game requires one or a small set of moves. Suppose the board is equally divided, and all groups are settled but one. The last group will live or die, depending on whether the program makes the single correct move or not. Many life-and-death program can be converted to this form. An alternative approach would be to take a traditional life-and-death problem, and assign a komi such that the problem must be solved to win the game. A third approach might be to devise a UCT framework which can be given specific goals, such as kill this group or live, or select a move from this subset, which otherwise uses the same algorithms for whole-board play. Given a large set of life-and-death problems which have been converted into whole-board problems, I believe that any UCT program which handles the life-and-death problems correctly would probably do quite well in whole-board play also. The knowledge should generalize well. Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] MoGoRel3_3550pps
From: Rémi Coulom [EMAIL PROTECTED] Sylvain Gelly wrote: Yes I did! :).It is not on my website, but will (soon?). However, you should not be so eager to read it :) Cheers, Sylvain Google finds it: http://tao.lri.fr/Papers/thesesTAO/SylvainGellyThesis.pdf Thanks, Rémi! Now eagerly awaiting the English translation! Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] MoGoRel3_3550pps
There is lots of English in it. Just scroll down. terry mcintyre wrote: From: Rémi Coulom [EMAIL PROTECTED] Sylvain Gelly wrote: Yes I did! :).It is not on my website, but will (soon?). However, you should not be so eager to read it :) Cheers, Sylvain Google finds it: http://tao.lri.fr/Papers/thesesTAO/SylvainGellyThesis.pdf Thanks, Rémi! Now eagerly awaiting the English translation! Never miss a thing. Make Yahoo your homepage. http://us.rd.yahoo.com/evt=51438/*http://www.yahoo.com/r/hs ___ 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] Sylvain Gelly thesis in english
Le dimanche 13 janvier 2008, terry mcintyre a écrit : From: Rémi Coulom [EMAIL PROTECTED] Sylvain Gelly wrote: Yes I did! :).It is not on my website, but will (soon?). However, you should not be so eager to read it :) Cheers, Sylvain Google finds it: http://tao.lri.fr/Papers/thesesTAO/SylvainGellyThesis.pdf Thanks, Rémi! Now eagerly awaiting the English translation! It is in english since page 24. pages 1-23 are french summary :-) Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] handicap for mogo against pro ?
I don't think such positions are enough to evaluate total performance of a program. Because they don't include middle games nor opening games, for examples. -Hideki terry mcintyre: [EMAIL PROTECTED]: Hideki Kato wrote: What is correct move? It has sense only for some artificial problems or very limited positions, and so, it cannot evaluate total performance of a program. There are many positions where winning the game requires one or a small set of moves. Suppose the board is equally divided, and all groups are settled but one. The last group will live or die, depending on whether the program makes the single correct move or not. Many life-and-death program can be converted to this form. An alternative approach would be to take a traditional life-and-death problem, and assign a komi such that the problem must be solved to win the game. A third approach might be to devise a UCT framework which can be given specific goals, such as kill this group or live, or select a move from this subset, which otherwise uses the same algorithms for whole-board play. Given a large set of life-and-death problems which have been converted into whole-board problems, I believe that any UCT program which handles the life-and-death problems correctly would probably do quite well in whole-board play also. The knowledge should generalize well. Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs inline file ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ -- [EMAIL PROTECTED] (Kato) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Sylvain Gelly thesis in english
Thanks Alain. I see I had given up on the paper too soon. - Dave Hillis -Original Message- From: Alain Baeckeroot [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Sun, 13 Jan 2008 11:51 am Subject: Re: [computer-go] Sylvain Gelly thesis in english Le dimanche 13 janvier 2008, terry mcintyre a écrit : From: Rémi Coulom [EMAIL PROTECTED] Sylvain Gelly wrote: Yes I did! :).It is not on my website, but will (soon?). However, you should not be so eager to read it :) Cheers, Sylvain Google finds it: http://tao.lri.fr/Papers/thesesTAO/SylvainGellyThesis.pdf Thanks, Rémi! Now eagerly awaiting the English translation! It is in english since page 24. ages 1-23 are french summary :-) Alain ___ omputer-go mailing list [EMAIL PROTECTED] ttp://www.computer-go.org/mailman/listinfo/computer-go/ More new features than ever. Check out the new AIM(R) Mail ! - http://webmail.aim.com ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Sylvain Gelly thesis in english
Google finds it: http://tao.lri.fr/Papers/thesesTAO/SylvainGellyThesis.pdf That is NOT the latest version. Please at least let me put the latest version on my web site, it took me so long to correct it :). Sylvain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] MoGoRel3_3550pps
The reason I said that was this behavior from mogo. If I start it without that switch and as for a move, it allocates 20 seconds. If I then issue a small time_left command and ask for another move, it allocates a much smaller amount of time. Here is the output: Because you give a time_left 20, so MoGo is in fast end mode, just playing randomly to avoid loosing by time. Sylvain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] MoGoRel3_3550pps
Sylvain Gelly wrote: The reason I said that was this behavior from mogo. If I start it without that switch and as for a move, it allocates 20 seconds. If I then issue a small time_left command and ask for another move, it allocates a much smaller amount of time. Here is the output: Because you give a time_left 20, so MoGo is in fast end mode, just playing randomly to avoid loosing by time. OK, here it is with 60 seconds (still no command-line switch): [EMAIL PROTECTED]:~/go$ ./mogo --19 initiateNodeUrgencyForShisho at root node! Load opening database openingValues_19 succeed (nbEntries=60629) (nbIllegalMoves removed 0) tried to open openingValues_19, success 1 time_left b 60 0 = genmove b time left: 60 secs time given for this move: 1.0 sec time shishoCheck is called. Now we have 0 shishoLocations: and 0 attackShishoLocation initiateNodeUrgencyForShisho at root node! Self train initiation time: 0.00 0.443380(83%) || 1148/ 1(11%)(93%)(58%/0.60) ||47 |12 || B2 C3 D3 D4 E4 E3 D2 F4 E5||SSP:B2 C3 A1 H8 J1 ||PSP:B2 C3 A1 H8 J1 earlyCut : max1 1364; max2 1120; sum 12061 max1/sum 0.113082 ; max1/max2 1.216771 (hard 0) 0.435484(16%) || 1364/ 12061(11%)(82%)(65%/0.60) ||53 |12 || B2 C3 D3 D4 E4 E3 D2 F4 E5||SSP:B2 C3 A1 H8 A6 ||PSP:B2 C3 A1 H8 A6 12061 simulations(average length:0) done, time used: 0.96 seconds.(12563.5 games/sec) A B C D E F G H JABCD EFGHJ +---+ +-+ 9 | . . . . . . . . . | | 0.0001 2.4427 2.4315 0.0001 0.2353 0.3509 0.3750 0.3204 0.3867 | 8 | . . . . . . . . . | | 2.4245 0.4698 2.4267 0.0001 2.4426 0.5111 2.4430 0.4303 0.3468 | 7 | . . . . . . . . . | | 0.5000 2.4244 2.4167 2.4193 0.5317 2.4296 2.4360 0.4259 2.4463 | 6 | . . . . . . . . . | | 0.4343 2.4323 2.4267 0.5000 2.4398 2.4261 0.0001 0.3043 0.3857 | 5 | . . . . . . . . . | | 0.3961 2.4463 2.4310 2.4306 0.4898 0.5248 2.4324 0.4249 0.3109 | Black to play 4 | . . . . . . . . . | | 0.3663 0.0001 2.4404 2.4231 2.4280 2.4326 2.4394 0.4268 0.3033 | Black eaten stone(s): 0 3 | . . . . . . . . . | | 0.3582 0.3846 0.4429 0.5417 2.4329 2.4407 2.4381 2.4381 0.3387 | White eaten stone(s): 0 2 | . . . . . . . . . | | 0.2000 0.4355 0.5000 0.4000 0.3438 2.4395 2.4387 0.3760 0.3895 | 1 | . . . . . . . . . | | 0.4284 0.4000 0.3867 0.3780 0.4011 0.3805 0.3782 0.4040 0.4129 | +---+ +-+ A B C D E F G H J A B C D E F G H J +---+ +---+ 9 | . . . . . . . . . | | 0 0 0 0 0 0 0 0 0 | 8 | . . . . . . . . . | | 0 0 0 0 0 0 0 0 0 | 7 | . . . . . . . . . | | 0 0 0 0 0 0 0 0 0 | 6 | . . . . . . . . . | | 0 0 0 0 0 0 0 0 0 | Move 1: B2 5 | . . . . . . . . . | | 0 0 0 0 0 0 0 0 0 | White to play 4 | . . . . . . . . . | | 0 0 0 0 0 0 0 0 0 | Black eaten stone(s): 0 3 | . . . . . . . . . | | 0 0 0 0 0 0 0 0 0 | White eaten stone(s): 0 2 | . (@) . . . . . . . | | 0 1 0 0 0 0 0 0 0 | 1 | . . . . . . . . . | | 0 0 0 0 0 0 0 0 0 | +---+ +---+ B2 = B2 ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] MoGoRel3_3550pps
Hi, Nothing strange here. You tell MoGo to play 19x19 and you tell him that there is only 60 s left. It can be understood that it takes only 1s for this move... BTW, if you see him play in 9x9, it is because while you told him to set his parameters for a 19x19, by default the boardsize is 9x9 and MoGo expects a gtp command to override it. Cheers, Sylvain 2008/1/13, Michael Williams [EMAIL PROTECTED]: Sylvain Gelly wrote: The reason I said that was this behavior from mogo. If I start it without that switch and as for a move, it allocates 20 seconds. If I then issue a small time_left command and ask for another move, it allocates a much smaller amount of time. Here is the output: Because you give a time_left 20, so MoGo is in fast end mode, just playing randomly to avoid loosing by time. OK, here it is with 60 seconds (still no command-line switch): [EMAIL PROTECTED]:~/go$ ./mogo --19 initiateNodeUrgencyForShisho at root node! Load opening database openingValues_19 succeed (nbEntries=60629) (nbIllegalMoves removed 0) tried to open openingValues_19, success 1 time_left b 60 0 = genmove b time left: 60 secs time given for this move: 1.0 sec time shishoCheck is called. Now we have 0 shishoLocations: and 0 attackShishoLocation initiateNodeUrgencyForShisho at root node! Self train initiation time: 0.00 0.443380(83%) || 1148/ 1(11%)(93%)(58%/0.60) ||47 |12 || B2 C3 D3 D4 E4 E3 D2 F4 E5||SSP:B2 C3 A1 H8 J1 ||PSP:B2 C3 A1 H8 J1 earlyCut : max1 1364; max2 1120; sum 12061 max1/sum 0.113082 ; max1/max2 1.216771 (hard 0) 0.435484(16%) || 1364/ 12061(11%)(82%)(65%/0.60) ||53 |12 || B2 C3 D3 D4 E4 E3 D2 F4 E5||SSP:B2 C3 A1 H8 A6 ||PSP:B2 C3 A1 H8 A6 12061 simulations(average length:0) done, time used: 0.96 seconds.( 12563.5 games/sec) A B C D E F G H JABCD EFGHJ +---+ +-+ 9 | . . . . . . . . . | | 0.0001 2.4427 2.4315 0.0001 0.2353 0.3509 0.3750 0.3204 0.3867 | 8 | . . . . . . . . . | | 2.4245 0.4698 2.4267 0.0001 2.4426 0.5111 2.4430 0.4303 0.3468 | 7 | . . . . . . . . . | | 0.5000 2.4244 2.4167 2.4193 0.5317 2.4296 2.4360 0.4259 2.4463 | 6 | . . . . . . . . . | | 0.4343 2.4323 2.4267 0.5000 2.4398 2.4261 0.0001 0.3043 0.3857 | 5 | . . . . . . . . . | | 0.3961 2.4463 2.4310 2.4306 0.4898 0.5248 2.4324 0.4249 0.3109 | Black to play 4 | . . . . . . . . . | | 0.3663 0.0001 2.4404 2.4231 2.4280 2.4326 2.4394 0.4268 0.3033 | Black eaten stone(s): 0 3 | . . . . . . . . . | | 0.3582 0.3846 0.4429 0.5417 2.4329 2.4407 2.4381 2.4381 0.3387 | White eaten stone(s): 0 2 | . . . . . . . . . | | 0.2000 0.4355 0.5000 0.4000 0.3438 2.4395 2.4387 0.3760 0.3895 | 1 | . . . . . . . . . | | 0.4284 0.4000 0.3867 0.3780 0.4011 0.3805 0.3782 0.4040 0.4129 | +---+ +-+ A B C D E F G H J A B C D E F G H J +---+ +---+ 9 | . . . . . . . . . | | 0 0 0 0 0 0 0 0 0 | 8 | . . . . . . . . . | | 0 0 0 0 0 0 0 0 0 | 7 | . . . . . . . . . | | 0 0 0 0 0 0 0 0 0 | 6 | . . . . . . . . . | | 0 0 0 0 0 0 0 0 0 | Move 1: B2 5 | . . . . . . . . . | | 0 0 0 0 0 0 0 0 0 | White to play 4 | . . . . . . . . . | | 0 0 0 0 0 0 0 0 0 | Black eaten stone(s): 0 3 | . . . . . . . . . | | 0 0 0 0 0 0 0 0 0 | White eaten stone(s): 0 2 | . (@) . . . . . . . | | 0 1 0 0 0 0 0 0 0 | 1 | . . . . . . . . . | | 0 0 0 0 0 0 0 0 0 | +---+ +---+ B2 = B2 ___ 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] MoGoRel3_3550pps
I'm not saying that it's anything strange. I was just pointing out that it does seem to heed the time_left number, even without specifying totalTime on the command line. Yes, I started mogo with the --19 switch so that it would have to think about the first move on 9x9 instead of using the opening book. It's easier to type than --useOpeningBook 0. Sylvain Gelly wrote: Hi, Nothing strange here. You tell MoGo to play 19x19 and you tell him that there is only 60 s left. It can be understood that it takes only 1s for this move... BTW, if you see him play in 9x9, it is because while you told him to set his parameters for a 19x19, by default the boardsize is 9x9 and MoGo expects a gtp command to override it. Cheers, Sylvain 2008/1/13, Michael Williams [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Sylvain Gelly wrote: The reason I said that was this behavior from mogo. If I start it without that switch and as for a move, it allocates 20 seconds. If I then issue a small time_left command and ask for another move, it allocates a much smaller amount of time. Here is the output: Because you give a time_left 20, so MoGo is in fast end mode, just playing randomly to avoid loosing by time. OK, here it is with 60 seconds (still no command-line switch): [EMAIL PROTECTED]:~/go$ ./mogo --19 initiateNodeUrgencyForShisho at root node! Load opening database openingValues_19 succeed (nbEntries=60629) (nbIllegalMoves removed 0) tried to open openingValues_19, success 1 time_left b 60 0 = genmove b time left: 60 secs time given for this move: 1.0 sec time shishoCheck is called. Now we have 0 shishoLocations: and 0 attackShishoLocation initiateNodeUrgencyForShisho at root node! Self train initiation time: 0.00 0.443380(83%) || 1148/ 1(11%)(93%)(58%/0.60) ||47 |12 || B2 C3 D3 D4 E4 E3 D2 F4 E5||SSP:B2 C3 A1 H8 J1 ||PSP:B2 C3 A1 H8 J1 earlyCut : max1 1364; max2 1120; sum 12061 max1/sum 0.113082 ; max1/max2 1.216771 (hard 0) 0.435484(16%) || 1364/ 12061(11%)(82%)(65%/0.60) ||53 |12 || B2 C3 D3 D4 E4 E3 D2 F4 E5||SSP:B2 C3 A1 H8 A6 ||PSP:B2 C3 A1 H8 A6 12061 simulations(average length:0) done, time used: 0.96 seconds.(12563.5 games/sec) A B C D E F G H JABCD EFGHJ +---+ +-+ 9 | . . . . . . . . . | | 0.0001 2.4427 2.4315 0.0001 0.2353 0.35090.3750 0.3204 0.3867 | 8 | . . . . . . . . . | | 2.4245 0.4698 2.4267 0.0001 2.4426 0.5111 2.4430 0.4303 0.3468 | 7 | . . . . . . . . . | | 0.5000 2.4244 2.4167 2.4193 0.5317 2.4296 2.4360 0.4259 2.4463 | 6 | . . . . . . . . . | | 0.4343 2.4323 2.4267 0.5000 2.4398 2.4261 0.0001 0.3043 0.3857 | 5 | . . . . . . . . . | | 0.3961 2.4463 2.4310 2.4306 0.4898 0.5248 2.4324 0.4249 0.3109 | Black to play 4 | . . . . . . . . . | | 0.3663 0.0001 2.4404 2.4231 2.4280 2.4326 2.4394 0.4268 0.3033 | Black eaten stone(s): 0 3 | . . . . . . . . . | | 0.3582 0.3846 0.4429 0.5417 2.4329 2.4407 2.4381 2.4381 0.3387 | White eaten stone(s): 0 2 | . . . . . . . . . | | 0.2000 0.4355 0.5000 0.4000 0.3438 2.4395 2.4387 0.3760 0.3895 | 1 | . . . . . . . . . | | 0.4284 0.4000 0.3867 0.3780 0.4011 0.3805 0.3782 0.4040 0.4129 | +---+ +-+ A B C D E F G H J A B C D E F G H J +---+ +---+ 9 | . . . . . . . . . | | 0 0 0 0 0 0 0 0 0 | 8 | . . . . . . . . . | | 0 0 0 0 0 0 0 0 0 | 7 | . . . . . . . . . | | 0 0 0 0 0 0 0 0 0 | 6 | . . . . . . . . . | | 0 0 0 0 0 0 0 0 0 | Move 1: B2 5 | . . . . . . . . . | | 0 0 0 0 0 0 0 0 0 | White to play 4 | . . . . . . . . . | | 0 0 0 0 0 0 0 0 0 | Black eaten stone(s): 0 3 | . . . . . . . . . | | 0 0 0 0 0 0 0 0 0 | White eaten stone(s): 0 2 | . (@) . . . . . . . | | 0 1 0 0 0 0 0 0 0 | 1 | . . . . . . . . . | | 0 0 0 0 0 0 0 0 0 | +---+
