Re: [computer-go] language choices
To me, computer go programming means basic research for now, as I don't believe the existing algorithms get you very far (I may be too ambitious, but I cant help it..). Thus, I would program in a way that let's me explore everything very fast, without caring too much about performance. This is why I' using Common Lisp. If I'd be happy with the status of the research as it is, trying to get as much out of it as possible for tournament programs, I would go Chrilly's way and use C, assembler or my own special chip (if I could afford it or knew some nice sheik =) Just my 2 cents, Ben Don Dailey wrote: On Mon, 2006-12-04 at 19:30 -0200, Mark Boon wrote: The object pooling is the only thing I'd rather do without. But for speed that's not possible, unfortunately. However it hardly affects cleanliness or readability as there's not such a big difference between a constructor call and a factory call. It does add some extra code, that's true. However, that's the same for any language, also low-level ones like C or assembler. I don't see the logic why you can't do in Java something that performance gurus do in C. Just because it's Java? Because it makes sense? No, for me it's the total time/effort trade-off for a given level of performance. If I program in C, it will take a little longer to write the code, but it will run significantly faster even if I don't do any special optimizations. If I program in Java and claim it is to save time, but then I spend a significant amount of time trying to make it go fast, I have spend MORE time than I did in C, and it's not as fast. Not a reasonable trade-off. I agree that you can do some reasonable optimizations and still have readable code. But avoiding object creation doesn't seem to me like a natural way to use an object oriented language. But my main point is that if you claim to use Java to save yourself time, but you expect to have to do a significant amount of optimizations to be happy, then why bother? Just program in C and don't do any optimizations and be faster with less time invested. I think that's enough for me. I'm not going to post any more on this subject because it's starting to seem stupid going back and forth on this. - Don ___ 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] Knowing nothing about it
Sylvain Gelly wrote: You are totally right. For Yizao (one of the author of MoGo), who is a good Go player, this gives a bad style to MoGo. As I don't know how to play Go (beyond the rules :)), I don't see any style and I don't care :). I forwarded this to other people in the computer-chess community. The common answer was: Sylvain has the right qualification to be the new shooting star in Computer-Go. Feng Hsu wrote in the beginning of the Deep Blue project a paper Building a GM-level chess programm without knowing nothing about chess. This was probably a paraphrase of Hans Berliner, the former correspondence chess world-champion who build HiTech. I assume everytime Feng Hsu made a proposal Berliner did not like, he told him that he knows nothing about chess. Feng Hsu had even at the end of the Deep Blue project problems to make moves correctly on the board. It was not obvious for him were the square c5 is. There is another Chrilly's law: Everybody besides a GM can write a strong chess programm. Maybe this holds also for Go-Programms. Everyboyd beside a Dan can write a strong programm. Or maybe its the other way round. The programms are relative weak, because the programmers are all too strong. Chrilly ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] language choices
Give me a program that beats a dan level taking less than a week to process. I will code it in assembler if necesary to make it efficient for a competition. (parallel if necesary) The first part difficult. The second one is just engineering. 20 minutes or 20 hours is the same in this problem. yes, but to discover that it's dan-level, you need to wait a week for each move. that could be some mighty slow experimentation. could be that the move chosen after 1 minute is 20kyu, the move chosen after 20 minutes is 10kyu, and the move chosen after a week is 1kyu. but you might never discover that last fact... s. Need a quick answer? Get one in minutes from people who know. Ask your question on www.Answers.yahoo.com ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] language choices
I'll bet Mogo would give a dan level player fits at 9x9 if 1 week of thinking time per move could be compressed enough to play a 30 minute game. If you think so, go and try it! Its quite important to know that. You can play a game with some dan level at http://itsyourturn.com/ __ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! ¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] language choices
I'll bet Mogo would give a dan level player fits at 9x9 if 1 week of thinking time per move could be compressed enough to play a 30 minute game. you could always get a dan player to volunteer for such a game. he would promise not to spend more than 1/2 hour on the game, and mogo would play postally. i'd be very impressed if mogo could give him fits. also, 30 minutes / 50 moves (guess) == .6 min / move. 7 days = 10080 minutes, so it's just a factor of 16800 speed increase that's needed. is mogo parallelizable? if so, i could probably get 10 machines on the job, so we'd just need another factor of 1700 increase or so. :) s. Any questions? Get answers on any topic at www.Answers.yahoo.com. Try it now. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Knowing nothing about it
I'm not sure sometimes if a person's arguement is for the truth or just politics. I'm going to assume that it's for the truth. Feng Hsu may not know much about chess, but he enlisted the help of one who does. His name is Schaffer if I remeber correctly. He was decribed as a competitive chess player. Feng Hsu dragged him to IBM for the Deep Blue project. This is before IBM. Once at IBM a grand master works with the Feng Hsu group constantly. Let put things in perspective. The contribution of Feng Hsu is that He spear headed a effective chess hardware. Is he alone reponsible for the success of the Deep Blue? I, and anyone with a common sense, doubt it. By the way I read through his book in the Bookstore in couple hours when it just got published. My objection is that he didn't mention any technical details about the Deep blue. Actually Deep Thought as well. So I didn't buy it. Dan Liu -Original Message- From: [EMAIL PROTECTED] To: computer-go@computer-go.org Sent: Tue, 5 Dec 2006 8:10 AM Subject: Re: [computer-go] Knowing nothing about it Sylvain Gelly wrote: You are totally right. For Yizao (one of the author of MoGo), who is a good Go player, this gives a bad style to MoGo. As I don't know how to play Go (beyond the rules :)), I don't see any style and I don't care :). I forwarded this to other people in the computer-chess community. The common answer was: Sylvain has the right qualification to be the new shooting star in Computer-Go. Feng Hsu wrote in the beginning of the Deep Blue project a paper Building a GM-level chess programm without knowing nothing about chess. This was probably a paraphrase of Hans Berliner, the former correspondence chess world-champion who build HiTech. I assume everytime Feng Hsu made a proposal Berliner did not like, he told him that he knows nothing about chess. Feng Hsu had even at the end of the Deep Blue project problems to make moves correctly on the board. It was not obvious for him were the square c5 is. There is another Chrilly's law: Everybody besides a GM can write a strong chess programm. Maybe this holds also for Go-Programms. Everyboyd beside a Dan can write a strong programm. Or maybe its the other way round. The programms are relative weak, because the programmers are all too strong. Chrilly ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ Check out the new AOL. Most comprehensive set of free safety and security tools, free access to millions of high-quality videos from across the web, free AOL Mail and more. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] language choices
On 12/5/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Mogo would also have a memory problem. The UCT programs build trees in memory. My own program cannot think more than a few minutes without running out of memory - so even the experiment you propose cannot be done. Yes you are right. For MoGo it is even worst. As all the games we have to play in are short games, we did not at all optimize the memory use, and in fact MoGo a lot more memory than necessary. I am not totally sure, but I think even 1 minute/move is already too much :). Of course, we can be more carefull with memory usage, but for the moment it is not the higher priority. How long would it take Mogo to fill up 16GB of memory on a quad core opteron machine? regards, -John ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Technical Report on MoGo
Hello, I'd be a bit more careful about the comparison with alpha-beta in section 2.3. I believe that iterative deepening of alpha-beta is very common. It can be argued that when iterative deepening is used, an early termination isn't very detrimental. [...] Alpha-Beta is for practical reasons of course also an anytime algorithm. [...] .My reaction when I read this statement was: iterative deepening is not yet invented in the Go community. Of course iterative deepening exists. But to me it does not make Alpha-Beta algorithm an anytime algorithm. First because the unit (one iteration) costs much more in alpha-beta. By iteration I mean that if you stop your program during an iteration, then it behaves as in the last iteration (the current iteration is lost). In MC/UCT, the iteration takes less than 1 ms. Second, and more importantly, the time increase of the iteration is huge in alpha-beta. The time to perform the search at depth k+1 is much higher than for depth k. So for me the reasons we gave comparing to alpha-beta hold, even if you are right by saying that we should have mentionned iterative deepening. Sylvain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] language choices
Le Mardi 5 Décembre 2006 20:50, John Tromp a écrit : On 12/5/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Mogo would also have a memory problem. The UCT programs build trees in memory. My own program cannot think more than a few minutes without running out of memory - so even the experiment you propose cannot be done. Yes you are right. For MoGo it is even worst. As all the games we have to play in are short games, we did not at all optimize the memory use, and in fact MoGo a lot more memory than necessary. I am not totally sure, but I think even 1 minute/move is already too much :). Of course, we can be more carefull with memory usage, but for the moment it is not the higher priority. How long would it take Mogo to fill up 16GB of memory on a quad core opteron machine? It depends on the speed of your opteron :). Perhaps something like 10 minutes. I think stl vector implementation on my linux box takes much more memory than necessary (I mean using a memory pool, and a big time against memory tradeoff), so perhaps being carefull, with 16 GB we could reach 20 minutes. Sylvain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] language choices
not to be overly critical here, but... Mogo would also have a memory problem. then the proposed gendankenexperiment (if it could run for a week in only a few minutes' time) doesn't even make sense -- if it couldn't make use of all of the extra time (compressed or otherwise), then it can't make use of it. do you mean that if it had a cpu that ran 7*24*60*2 times as quickly, *and* that if it had 7*24*60*2 times as much ram, that it could beat a 1-dan player? I think you are falling for the standard misconception that the computer must be superior in every aspect of the game to have a chance. no, i just said that i'd be impressed. which i would. because i haven't seen any computer program at the dan level, or even heard anyone claim that when they doubled (or 10x or 100x or 1000x) the amount of thinking time for their machine that they were at dan strength. so really you're suggesting (almost) that you're within a log_10 factor of 4 of dan strength. which can quite easily be overcome with enough hardware. i'd just like to see it happen. :) I know exactly how these things work. The match would begin, the human would probably be outplaying the computer and then make some error. The computer would win and everyone would cry it shouldn't have happened.The computer just got lucky this time. i think that if a dan-level player had 10 games, the first 5 of which were considered just to be for fun, and that no reprogramming or recoding were allowed inbetween, that the program would either get crushed, or lose by a slim, but appreciable margin over a 5-game series. the difference between 1-dan and 3-dan, say, is about the same as the difference between 1-dan and 2 kyu, or 2kyu and 4kyu, 4-6, or 6-8. so if mogo is currently at (say) 8kyu on 9x9, then you're suggesting that it could gain 9 stones' strength with a factor of 1 in time. this (sort've) implies that you think that you're within a factor of 10 of 3-dan, for instance, if the only issue is scaling. or within 10^6 of 5-dan. an i think that if you were to perform these experiments one at a time (i.e. give yourself 10x more time, and see if you can beat an 6kyu, then 100x more time and see if you can beat a 4kyu, etc.), many of which are reasonable (we all could donate some cpu time to the task), we could see if the linear scaling argument actually holds water. :) which i'm not saying that it wouldn't. i'm just saying that it's a testable hypothesis (minus your equivocation about ram usage), and we ought to get cracking to see if it's true. s. Yahoo! Music Unlimited Access over 1 million songs. http://music.yahoo.com/unlimited ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] language choices
On Tue, 2006-12-05 at 20:40 +0100, [EMAIL PROTECTED] wrote: On Tue, 2006-12-05 at 09:51 -0800, steve uurtamo wrote: I'll bet Mogo would give a dan level player fits at 9x9 if 1 week of thinking time per move could be compressed enough to play a 30 minute game. you could always get a dan player to volunteer for such a game. he would promise not to spend more than 1/2 hour on the game, and mogo would play postally. i'd be very impressed if mogo could give him fits. What do you mean by dan level? I don't mean high dan, I mean 1 dan. So that I can follow this discussion, how would be the kgs level of this player (it is the only level I have access to when looking at the results of game)? Wouldn't it be 1 dan on KGS? Maybe the group can help me extrapolate. What estimated (or actual) rating would gnugo 3.7.4 have on KGS? Whatever rating that is, would it play better or worse at 9x9? In other words, if it were EQUAL to a 15 kyu player at 19x19 for example, would it be better or worse at 9x9? On CGOS, gnugu_3.7.4 is rated 1720. MoGo is is in the 2100-2200, presumably it's save to assume it is significantly stronger. But if we can assign an ELO rating to Gnugo 3.7.4, then we can add 300 or 400 to get Mogo's current ELO rating. We will then know approximately how to estimate what a 1 Dan players ELO would be (once we know about what kyu level gnugo 3.7.4 is) by extrapolation. (About 100 ELO per kyu as I understand it.) Then if we estimate the ELO of a 1 Dan player, we can estimate what percentage of games Mogo would win now, and how much it needs to improve to be equal. This would all be somewhat speculative of course but it would give us a rough idea of where we are. I would be willing to be conservative on all the calculations - by assuming Mogo isn't as strong as we think, a doubling in time does not add as much ELO strength as we know it does, etc. We would have to estimate the improvement expected from extra thinking time. The Mogo team probably already has estimates, but I have my own too based on experiments with Lazarus. My studies show that it's about the same as chess used to be, about 100 ELO points for a speed doubling. This may not be accurate for higher levels - I don't really know for sure. I would be willing to assume only a modest 50 points per doubling, to get what I would consider a very safe lower bound.If Mogo is averaging approximately 10 seconds per game on CGOS to achieve 2100, then I've estimated about 16 doublings of speed if it's been given 1 week per move. That is 800 ELO points even using very conservative calculations. Yes, I know a lot of this is supposition but I'm confident that the program given a hypothetical 1 week per move would be pretty impressive. I don't feel these calculations are unreasonable or way out of the question - we have seen that UCT is very nicely scalable.I have not forgotten the computer chess lessons of the past either, where 1 ply gave 250 ELO points but everyone said that formula would not apply to the next ply. People were silly enough back then to believe that after 6 ply searches going beyond wouldn't help any (or very little.) - Don Mogo would also have a memory problem. The UCT programs build trees in memory. My own program cannot think more than a few minutes without running out of memory - so even the experiment you propose cannot be done. Yes you are right. For MoGo it is even worst. As all the games we have to play in are short games, we did not at all optimize the memory use, and in fact MoGo a lot more memory than necessary. I am not totally sure, but I think even 1 minute/move is already too much :). Of course, we can be more carefull with memory usage, but for the moment it is not the higher priority. In fact, in honor of Chrilly's laws I will call this Don's law. What really counts is how bad your bad moves are. I think this is a interesting point. I think I agree with that law :). 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] language choices
On Tue, 2006-12-05 at 21:15 +0100, John Tromp wrote: On 12/5/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: How long would it take Mogo to fill up 16GB of memory on a quad core opteron machine? It depends on the speed of your opteron :). Perhaps something like 10 minutes. I think stl vector implementation on my linux box takes much more memory than necessary (I mean using a memory pool, and a big time against memory tradeoff), so perhaps being carefull, with 16 GB we could reach 20 minutes. The opterons run at 1.4Ghz. If you can provide me with a Linux amd64 executable, in which Mogo allocates, say, 14GB (leave some for the OS) and thinks until it exhausts this memory, I'd be happy to test it out for a few games (I'm a Dutch 2dan with a fair bit of 9x9 experience). You would win every game but it would be fun to watch. Would you set up Mogo to run on KGS so we could watch all the games and of course never take back a move? Are you actually willing to wait for 20 minutes per move and are you saying you will limit your own thinking time? (Humans improve more with extra thinking time than computers do, every computer chess programmer knows this - it's all about the error rate stuff I talked about.) Again, even if you do all those things I think you would win all the games - but it would still be fun to see if you feel any resistance whatsoever. - Don regards, -John ___ 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] KGS Computer Go Tournaments
Nick, I would love to see such a tournament, but the UCT programs could not take full advantage of the extra time. As you see, we run out of memory after a minute or two! - Don On Tue, 2006-12-05 at 20:48 +, Nick Wedd wrote: Jason: Thank you for pointing out these errors. I have fixed them now. Sylvain: Thank you for your explanation of MoGoBot19's play. I have added it to the page. I keep promising to hold a slow tournament soon, with 12 hours each for each game. I would propose next week, with games on 11th 12th 13th 14th 15th. But I understand that SlugGo is off sick at present, and as it is the program that would most enjoy such time settings, maybe I should wait until I hear that it has recovered? Nick ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] language choices
Sylvain, You can extend this pretty easily by doing 2 or more simulations at a time. The trade-off is very good for doing this although not 100%.I HAVE to do this for Lazarus because I have very little memory in my machine. I believe I'm doing 8 simulations at a time in order to use about 1/8th of the memory. - Don On Tue, 2006-12-05 at 21:03 +0100, [EMAIL PROTECTED] wrote: How long would it take Mogo to fill up 16GB of memory on a quad core opteron machine? It depends on the speed of your opteron :). Perhaps something like 10 minutes. I think stl vector implementation on my linux box takes much more memory than necessary (I mean using a memory pool, and a big time against memory tradeoff), so perhaps being carefull, with 16 GB we could reach 20 minutes. Sylvain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] KGS Computer Go Tournament: results
In message [EMAIL PROTECTED], Arend Bayer [EMAIL PROTECTED] writes On 12/5/06, House, Jason J. [EMAIL PROTECTED] wrote: Sorry to be such a pest about the web site status, but the finished link for December is wrong (see http://www.weddslist.com/kgs/future.html). While we are at it, I suggest you remove the copy of kgsgtp.xhtml from your webpages. It's worse to have outdated documentation on your pages than no documentation, since everyone gets the updated one when downloading the kgsGtp client. Agreed. Done. Nick -- Nick Wedd[EMAIL PROTECTED] ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] UCT/MoGo confusion
Hi, Perhaps I am oversimplifying, but if I understand correctly, MoGo primarily gets its strength in 9x9 go by improving upon the random simulations by preferring good moves over purely random moves during the random game. Yet I have two results that seem to indicate that it's not really that simple The first is that we have a purely random UCT version running on CGOS (GoJin) and its rating seems to sit around 1640. But in the paper we are told that the very first Mogo achieved almost the identical rating, yet Well, it's possible that the two programs have not the same speed this might make a big difference. it already had some improvements, such as preferring large captures. Can I conclude that those improvements to the random simulations actually have no effect on the performance of the program? Surely there would be some effect, but might not be that much as expected. But even more confusing to me is that we've tried some simple improvements to the random program that have had no effect. The ones that I was certain would improve performance were versions that changed random simulations so that moves near existing stones would be preferred over stones placed too far away from the action. Many versions have been tried, e.g., moves that must be adjacent to some other stone, moves that must be no more than 1 space away from existing stones, etc. Surely on Well, I think we have tried some similar things. Personally I don't think this will lead to a significant improvement, and it is what the result shows in our experiment. average these are going to be better moves than purely random moves -- or is this, indeed, the flaw in my logic? Shouldn't these versions outperform the purely random versions? In almost every case the modified No not necessary. version performed identical to the purely random version -- no worse and no better -- at least according to the self tests. Does this really I dont know what do you mean by 'identical' and 'self tests' here. Intuitively it is not a good idea to have your program test against itself. I believe every change will bring something different, but sometimes not very significant. Yizao sound right? -Richard ___ 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] language choices
Le Mardi 5 Décembre 2006 22:03, Don Dailey a écrit : Sylvain, You can extend this pretty easily by doing 2 or more simulations at a time. The trade-off is very good for doing this although not 100%.I HAVE to do this for Lazarus because I have very little memory in my machine. I believe I'm doing 8 simulations at a time in order to use about 1/8th of the memory. Don, we experimented this on MoGo and this gave us bad results. I mean that, with the same number of nodes, having more simulations do not improve the level much (even very little). Are your experimental results different? Sylvain On Tue, 2006-12-05 at 21:03 +0100, [EMAIL PROTECTED] wrote: How long would it take Mogo to fill up 16GB of memory on a quad core opteron machine? It depends on the speed of your opteron :). Perhaps something like 10 minutes. I think stl vector implementation on my linux box takes much more memory than necessary (I mean using a memory pool, and a big time against memory tradeoff), so perhaps being carefull, with 16 GB we could reach 20 minutes. 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] language choices
So that I can follow this discussion, how would be the kgs level of this player (it is the only level I have access to when looking at the results of game)? Wouldn't it be 1 dan on KGS? I don't know because some seem to say that the KGS level is not the true level? If so, MoGo has already won against players with a d on KGS, you can look at the archive looking for regular expression \[.d at: http://www.gokgs.com/gameArchives.jsp?user=mogoboty=2006m=11 Of course, I don't know if it was real games in the sense that players were playing at their best level. But perhaps some of these games, and it was 13 minutes games. MoGo also won a game against a [8d?] on kgs (the game is marked as unfinished, but I think it is, isn't it?). http://files.gokgs.com/games/2006/11/20/MoGoBot-chunga.sgf Again, it is perhaps not real games, but perhaps, I can judge that, sorry. Of course, it is still a low winning rate... Again, I can't judge the games, so I apologize if what I say is irrelevant :). Sylvain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] language choices
On Wed, 2006-12-06 at 00:04 +0100, [EMAIL PROTECTED] wrote: So that I can follow this discussion, how would be the kgs level of this player (it is the only level I have access to when looking at the results of game)? Wouldn't it be 1 dan on KGS? I don't know because some seem to say that the KGS level is not the true level? If so, MoGo has already won against players with a d on KGS, you can look at the archive looking for regular expression \[.d at: http://www.gokgs.com/gameArchives.jsp?user=mogoboty=2006m=11 Of course, I don't know if it was real games in the sense that players were playing at their best level. But perhaps some of these games, and it was 13 minutes games. MoGo also won a game against a [8d?] on kgs (the game is marked as unfinished, but I think it is, isn't it?). http://files.gokgs.com/games/2006/11/20/MoGoBot-chunga.sgf Again, it is perhaps not real games, but perhaps, I can judge that, sorry. Of course, it is still a low winning rate... Again, I can't judge the games, so I apologize if what I say is irrelevant :). I don't know either. I assumed William Shubert tries to keep them in line with actual ratings but I can't say if they are off.Of course you realize that people will say ratings are off even if they are close. The human mind finds patterns where there are none. Of course they may really be off. I just don't know. We could start with GnuGo's rating at 19x19 pretend it's accurate for 9x9, but I'm sure most programs are better relative to humans at smaller boards. I cannot find gnugo on kgs - there is no way that I can find to do partial searches on user names and I don't know the exact name of any gnugo bots. Sylvain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [spam probable] Re: [computer-go] KGS Computer Go Tournaments
Le Mardi 5 Décembre 2006 21:55, Don Dailey a écrit : Nick, I would love to see such a tournament, but the UCT programs could not take full advantage of the extra time. As you see, we run out of memory after a minute or two! At least we have to make changes to remove from memory a lot of nodes. This can take so time to do (at least for me). But this could be an interesting tournament! Sylvain On Tue, 2006-12-05 at 20:48 +, Nick Wedd wrote: Jason: Thank you for pointing out these errors. I have fixed them now. Sylvain: Thank you for your explanation of MoGoBot19's play. I have added it to the page. I keep promising to hold a slow tournament soon, with 12 hours each for each game. I would propose next week, with games on 11th 12th 13th 14th 15th. But I understand that SlugGo is off sick at present, and as it is the program that would most enjoy such time settings, maybe I should wait until I hear that it has recovered? Nick ___ 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] language choices
Le Mardi 5 Décembre 2006 21:15, John Tromp a écrit : On 12/5/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: How long would it take Mogo to fill up 16GB of memory on a quad core opteron machine? It depends on the speed of your opteron :). Perhaps something like 10 minutes. I think stl vector implementation on my linux box takes much more memory than necessary (I mean using a memory pool, and a big time against memory tradeoff), so perhaps being carefull, with 16 GB we could reach 20 minutes. The opterons run at 1.4Ghz. If you can provide me with a Linux amd64 executable, in which Mogo allocates, say, 14GB (leave some for the OS) and thinks until it exhausts this memory, I'd be happy to test it out for a few games (I'm a Dutch 2dan with a fair bit of 9x9 experience). This could be very interesting! If by anyway I can have an user account on this machine, I can try to compile MoGo and launch it on KGS so that you can easily play, and everyone can watch the games. What do you think? Sylvain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] language choices
hi Sylvain, This could be very interesting! If by anyway I can have an user account on this machine, I can try to compile MoGo and launch it on KGS so that you can easily play, and everyone can watch the games. What do you think? The machine is a central component of the Linux supercomputer cluster at CWI, where I used to work. Access is limited to CWI users I'm afraid:-( Can you compile it on any other Linux machine with an up to date gcc -O3 -static -m64 ? Once I get it running, I'll be happy to replay the game life on KGS as a demo game. regards, -John ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] language choices
I think stl vector implementation on my linux box takes much more memory than necessary (I mean using a memory pool, and a big time against memory tradeoff), so perhaps being carefull, with 16 GB we could reach 20 minutes. The STL vector is fairly efficient, especially if you are using reserve(). But if you are allocating same-size blocks then there is a quality memory pool in boost. It is hidden in one of the details directories, but I've been using it for a long time for my Chain class. If you are interested I can isolate and post the relevant bits. Darren ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] language choices
The machine is a central component of the Linux supercomputer cluster at CWI, where I used to work. Access is limited to CWI users I'm afraid:-( Ok I understand. Can you compile it on any other Linux machine with an up to date gcc -O3 -static -m64 ? I will try and send it to you. We'll see if at least it works :) (I never tried it on a 64 bits machine). Once I get it running, I'll be happy to replay the game life on KGS as a demo game. Great! Sylvain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] language choices
Le mercredi 6 décembre 2006 00:04, [EMAIL PROTECTED] a écrit : So that I can follow this discussion, how would be the kgs level of this player (it is the only level I have access to when looking at the results of game)? Wouldn't it be 1 dan on KGS? I don't know because some seem to say that the KGS level is not the true level? If so, MoGo has already won against players with a d on KGS, you can look at the archive looking for regular expression \[.d at: http://www.gokgs.com/gameArchives.jsp?user=mogoboty=2006m=11 Of course, I don't know if it was real games in the sense that players were playing at their best level. But perhaps some of these games, and it was 13 minutes games. MoGo also won a game against a [8d?] on kgs (the game is marked as unfinished, but I think it is, isn't it?). http://files.gokgs.com/games/2006/11/20/MoGoBot-chunga.sgf Very impressive ! Mogo win by 0.5 :) Looking at Mogo results, it sems more than KGS-1-dan for 9X9 I m 1k, and won only 1 game out of 4 or 5 , more precisely Mogo lost the game by playing a bad move and let me live when my group should have die. I suspect some ko was implied and mogo mess up the sequence, trying to kill without ko, or playing directly the final move of the ko. btw, on 19X19 GNU is kgs-6k, and slightly weaker on 9X9 (maybe 8k). Congrats Alain. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] language choices
hi Don, Why can't you just play it live on KGS? This is much more exciting. We would have no way to know if you were taking back moves or anything. (Although I believe you to be an honest person I still like to see for myself :-) If Sylvain provides me with a Mogo version that can connect to KGS, then I'll try to play it directly there. But I thought it might be easier for him to provide a console version... Let's wait and see:) regards, -John ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] UCT/MoGo confusion
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 program that have had no effect. The ones that I was certain would improve performance were versions that ... ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
