Re: [computer-go] Strong programs on cgos 19x19?
On Thu, Feb 18, 2010 at 10:30:56AM +0100, Jean-loup Gailly wrote: It's exactly the same software. The only difference is that is running on 23 cores. I am amazed at how well MCTS scales on 19x19. It would be interesting to know how well Pachi scales on KGS against ranked humans vs a single core version. It's well established that monte carlo scales well against itself, but there's very little data against humans, especially in the near dan range. -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Strong programs on cgos 19x19?
On Thu, Feb 18, 2010 at 02:57:32PM +0100, Jean-loup Gailly wrote: Yes it would be interesting but it's a bit difficult to run this experiment. The software and its parameters is constantly changing. We can't create a new kgs bot for every new version or parameter change, it wouldn't have enough time to get a rating. Also people escape more often against bots, it takes time to get these escaped games counted in favor of the bot. I'd argue that measuring performance against humans is the main challenge now. Beating up other monte carlo bots with bigger hardware isn't very interesting. The way to get good measurements is to put a stake in the sand and let it run, preferably with somewhere between 15 and 30 seconds byo-yomi. However, I don't really have the hardware or inclination to run the test myself, so I won't harp on the issue. -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Congratulations to Fuego!
On Mon, Jan 11, 2010 at 11:29:33PM +, Nick Wedd wrote: Congratulations to Fuego, clear winner of yesterday's KGS bot tournament! My report is at http://www.weddslist.com/kgs/past/55/index.html, probably with the usual errors. I hope you will report these to me so that I can correct them. From your report: In round 15, gomorra9 and pachi [...] The game was counted as a win to Black; I don't know how it was counted this way, but Black did deserve to win the game. The score was correct by area scoring. Black gained enough points via captures and also because White passed a few times when Black didn't. -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Mathematical Go
On Sat, Nov 28, 2009 at 06:25:10PM -0500, compgo...@aol.com wrote: It's the only pulication on Go that qualify as science. I'd say it's more math than science. It's completely theory based and has little if any practical applicaton. There are plenty of quality, scientific papers that have been published on Go. -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Hahn system tournament and MC bots
On Tue, Nov 24, 2009 at 03:06:51PM +0100, Vlad Dumitrescu wrote: So the only difference in play is when losing, one has to keep trying to lose as little as possible, resigning isn't an option. When ahead, there's no reason to try to win big, unless the goal is to reach a certain amount of points in a certain number of games. (Programs aren't greedy in the same way we people are :-) Let's assume that the program will play for a gambler, and will play many (an indefinite number) of independent games. Then I think no reason to try to win big is wrong. The rational approach to gambling is to maximize your expected value for each game. So now the problem becomes harder -- you have to realistically guess the risk vs reward over a spectrum of points. I think this game is clearly more difficult than a binary win/loss game. -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Hahn system tournament and MC bots
On Tue, Nov 24, 2009 at 03:57:37PM +0100, Vlad Dumitrescu wrote: Yes, but that doesn't necessarily mean that the strategy should be to push each game to the limit. Trying to win with a large margin is less safe than with a small one, so it depends on the gambler's mindset. That's why I said expected value, and specified an indefinite number of independent games. In this case, the only rational play is to judge the winning percentage for each move and weight it against the value. Mindset has nothing to do with it in this situation. This is standard gambling behavior for this kind of game. And also possibly add knowledge about the opponent(s). This problem is applicable to the standard win/loss game too -- programs are sometimes tuned against other programs. For the sake of discussion, I'm assuming that you know nothing about the other player and just assume best play from him. -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Hahn system tournament and MC bots
On Tue, Nov 24, 2009 at 04:19:45PM +0100, Vlad Dumitrescu wrote: Sure. But different gamblers have different break-even limits, i.e. different mindsets. Some are cautious and prefer 80% for those 25 points; some are reckless and would go for B even with 60%. No professional gambler, if he had the numbers laid out for him, would ever choose unoptimal play, not when he's playing for the long term. The computer, in the same way, would have to be modeled to maximize expected value. Nothing else makes sense. In a single game with high stakes, yes mindset (risk aversion, your finances, etc) might come into it. But that is exactly why I specified the long term scenario. -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Hahn system tournament and MC bots
On Wed, Nov 25, 2009 at 12:11:55AM +0100, Stefan Kaitschick wrote: A professional gambler has a 2 step task. 1. Find a weaker player (aka fish) [...] So the whole idea of optimizing the score it totally besides the point. I was using the professional gambler as a rational player in an idealized and defined setting. The point was to get around all the talk about player modelling, gods and devils, fish, and whatnot. Sure all of that other stuff is interesting and appropriate in a real setting, but the discussion wasn't getting anwhere. Even a professional poker player looking for fish or playing in tournaments understands the basic probabilities and fundamental concepts like implied odds that have nothing to do with psychology or player skill. -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Great Wall Opening by Bruce Wilcox
On Sun, Oct 18, 2009 at 09:57:45PM +0200, Ingo Althöfer wrote: I forgot to make clear the following: * I own some go programs, but only with commercial interfaces. So I have to start each new test game by hand. Why not just use one of the free and strong monte carlo programs that work with GTP, like Feugo for example? Even if there is a difference of a few stones in strength the results would still be of interest, and you wouldn't be stuck doing it by hand. -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Dynamic komi at high handicaps
On Wed, Aug 19, 2009 at 07:27:00AM -0700, terry mcintyre wrote: Consider the game when computer is black, with 7 stones against a very strong human opponent. Computer thinks every move is a winning move; it plays randomly; a half-point win is as good as a 70-point win. Didn't this game actually happen? Didn't MoGo *beat* a pro with 7 stones? Did it play randomly? Don't the monte carlo bots frequently win as White when giving handicap stones on KGS? I think we need some real statistical evidence that this problem is even worth talking about, aside from stylistic issues. I'm not the first to say this, but I think it bears repeating. -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] time measurement
On Tue, 2009-02-03 at 10:41 +, Nick Wedd wrote: Providers of Go servers claim that it would be pointless to try to implement client-side time, as players would be able to cheat by hacking their clients and fiddling with the clock. I don't doubt that they would try to cheat, indeed I know that they would; but providers of chess servers have been able to prevent cheating. As I understand it, their clients perform CRC checks on themselves to ensure that they have not been hacked, and the packets they send are CRC-checked by the server to ensure that the packets have not been hacked. And how does the chess server know when I suspend my cable modem or yank the plug from the wall to give my program (or myself?) more time to think? It looks exactly like lag. That's the easy, crude way. I'm also willing to bet that any client-side CRC check could be hacked, in exactly the same way that people hack software piracy checks. I mentioned last time we discussed network lag that on the chess server FICS there were constant accusations of cheating based on timeseal. I haven't played there in years, but I'd be surprised if the situation has changed. -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] time measurement
On Tue, 2009-02-03 at 10:16 -0800, Ian Osgood wrote: Frankly, I'm baffled that nobody in the online Go world cares about network lag. Timeseal has been a mature technology on the chess servers for over a decade. I logged into FICS today for nostalgia and one of the first thing I see is somebody complaining on channel 53 about somebody lag cheating. It's just a can of worms to require some proprietary binary that people have to use, trust, and believe is unhackable. And remember, pulling your network cable from the wall is an unstoppable hack. -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] time measurement
On Tue, 2009-02-03 at 18:54 +, Nick Wedd wrote: What sort of cheating does he complain about? Does he provide evidence that it happens? He couldn't flag his opponent when he ran out of time. Of course this could just be lag, or maybe he killed his process when he was losing. Once you introduce allowances for lag there's no way of telling if it's legitimate or intentional. Whenever I have connected to a server, for Go, chess, or any other game, I have used a proprietary binary, the client. I have never found this a problem. Keeping up-to-date binaries for all platforms tends to be a problem. That's why KGS runs on Java -- which tends to be trivial to hack. For something like FICS, there are many open source clients or clients built for particular platforms, so finding a suitable one is easy. However, the timeseal binary itself is separately maintained and compiled for many platforms. Yes, but it only gives you more pondering time, not more full thinking time. If the game is being relayed live then I can delay the timesealed connection (traffic shaping isn't hard) after my program makes its move but before the opponent responds, and on another connection anonymously observe the opponent's reply and enter it manually into another running copy of my program. Now I have as much thinking time as I want. -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
RE: [computer-go] Monte-Carlo and Japanese rules
On Thu, 2008-11-06 at 09:43 -0800, David Fotland wrote: Many Faces of Go's Monte Carlo engine plays strongly using Japanese rules. So what do you do in the playouts? Do you score with area or territory? Does your program play optimally where different rules would result in different winner? -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: OT: Teaching Go (was Re: [computer-go] Re: Disputes under Japanese rules)
On Fri, 2008-09-19 at 22:37 -0700, Ross Werner wrote: Do you see any mechanical issues with these rules, or do they still seem ad-hoc? group is ill-defined. It can mean indivisibly connected stones or loosely connected ones. In the false eye case, for example, there are two indiviual groups involved, but one umbrella group under consideration. Your rules as stated are already more complicated than I'd want to expose a beginner too. Any ruleset that requires agreement with restoration is a non-starter when just play is the alternative. To be honest, I don't really want to get in a back and forth with you while you implement/design your rules. Trying to formalize Japanese rules with some subset of being (logical, complete, simple) is a well travelled path. Ikeda, Lasker-Maas, Jasiek, Spite, Japanese-1989, Kee -- these are just some of the names that roll of the top of my head. I only suggested that you implement your rules so you could see just how hard it is, but you'd also do well to study those that have gone before you. Then again, I'd recommend you not go down that path at all :) When two beginners play each other, in real life (not on a computer), there is definitely a drawback to having to remember the original position. However, I believe there are also slight drawbacks to beginners when using area scoring--and those drawbacks are present in every game played, whereas the drawbacks of position restoring are only present in cases of a dispute. For territory rules, there is a drawback in every game played -- the beginner is unsure when to end the game, yet the rules tell him up front that he needs to stop early. Experimentation and seeing things to the logical end are punished. -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: OT: Teaching Go (was Re: [computer-go] Re: Disputes under Japanese rules)
On Thu, 2008-09-18 at 19:41 -0700, Ross Werner wrote: I teach informal territory rules with virtual play out. However in practice, I should note, the difference between territory rules with *actual* (not virtual) playout and area rules with actual playout ends up being identical. The only exception is the ridiculous invasion scenario that started this thread--that's the only case that I have seen in which the virtualness of the playout matters. That's a gross simplification and untrue. Consider some dead stones with a false eye. The player who has dead stones will pass, thinking his stones are alive. The player forced to kill them will lose points by removing the false eyes. This is a genuine dispute. Now after the false eye is removed you have to roll it back, making it virtual. Consider typical nakade shapes. The beginner will only have a simple understanding of these, if any. Shapes that look alive will be dead, and vice versa. You demonstrated this yourself when I showed you one of my disputed games in our last discussion: http://computer-go.org/pipermail/computer-go/2006-March/005061.html We haven't even discussed ko yet. That's another can of worms. I recall the discussion, but I don't recall (and looking over the posted thread doesn't bring to mind) being convinced of its impracticality. Are you speaking only of the combative opponent, multiple-group-dispute scenario? If so, then I agree that playout-and-restore is impractical. But in all other scenarios (e.g. combative opponent single-group-dispute), I think virtual playout is a perfectly reasonable procedure. I have several problems with your rules: 1) They are ad hoc. I am certain that you could not specify them mechanically. I would love to see you try and program them. This is of practical importance, because tools like Igowin are extremely helpful to beginners, but if they can't use the dispute phase the tool leads to confusion. 2) Fuzzy concepts that aren't easily verified by the beginner are confusing, because they have no concept of what seems obvious to you as an experienced player. Again I'm talking about the vague descriptions of your rules. 3) If the dispute phase is impractical to use (requiring remembering the original position and restoring it -- or not, since you say sometimes you don't restore it), then the beginner is discouraged from using it. Compare this with just continuing play and scoring as normal when using area scoring rules. It is extremely helpful for a beginner to experiment and see the result, while confident he is playing by the rules. Pass stones are probably superior for things like tournament or online play, but I find that the logic of playout-and-restore is easier for beginners to understand when the inevitable question of why can't I play a single stone in your territory and insist that you capture it, gaining me four points? comes up. YMMV. That's probably fine to explain the one and simple scenario where a stone is plunked down in the middle of a clearly uninvadable territory. That's just enough for an experienced player to get a beginner to nod is head, yeah I can see that, and not nearly enough to let a beginner play on his own with other beginners with a true understanding of the rules. -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: OT: Teaching Go (was Re: [computer-go] Re: Disputes under Japanese rules)
On Wed, 2008-09-17 at 21:39 -0700, Ross Werner wrote: And, of course, once a beginner understands life and death in this manner, playing out disputed groups is the most natural way to determine the life-or-death status of a group. (And, I submit, the best way no matter what ruleset you're using.) The ruleset has to specify a way to resolve disputes. You can't just play it out using any ruleset. So are you teaching informal territory rules with an ad hoc virtual play out, or are you using AGA rules with pass stones? -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: OT: Teaching Go (was Re: Disputes under Japanese rules)
On Thu, 2008-09-18 at 08:54 -0700, Peter Drake wrote: I was planning to teach Japanese rules (because that's what the books use). Most of the books say nothing at all about how to handle disputes. They teach an informal territory ruleset. That's a major flaw in the books that should not be repeated. I don't think it matters at all if you teach area scoring rules, since pretty much everything taught in the books can be applied to area scoring. I think you should teach both area scoring and territory scoring. Area scoring first because it is simple and can be played without agreeing to dead stones, and territory scoring once they have some games under their belt. Show that they are essentially equivalent to within a point. I got the sense from the earlier messages in this list that the virtual playout is not ad hoc. The earlier messages appear to be a mix of informal Japanese rules and official 1989 rules, the latter being the tortured details. David Fotland talks about an informal procedure where you play it out and then restore, but this is not practical and also doesn't really work, which I've debated on this list before: http://computer-go.org/pipermail/computer-go/2006-March/005019.html Nick Wedd is talking about the 1989 rules (tortured details), which if you're teaching beginners I recommend running away from at light speed. -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: OT: Teaching Go (was Re: Disputes under Japanese rules)
On Thu, 2008-09-18 at 11:12 -0700, Peter Drake wrote: Eventually, sure -- but I'd like them to have a few games under their belts before I bring up the issue of different versions of the rules. Ok, then play some 9x9 games with area scoring rules as Dave Devos suggested. I was making the same suggestion. Don't hit them with both rules at the same time, but make sure to choose the right set to start with! I may just follow Kim and Jeong's pedagogical lead and let the students experiment with pieces of the rules before trying to play a complete game. It's ok to teach unconditional life or simple life and death first, but once you get beyond that you need to be able to end and score the game, and beginners just can't do that easily with territory scoring and an agreement phase. I tried to learn with Kim's Learn to Play Go, and I was absolutely confused and frustrated when it came to end game scoring. The computer scientist's instinct is to lay down a terse and elegant set of rules and then deal with the consequences of those rules, but perhaps that is a bad thing when teaching. You need foundations to build on. One foundation is life and death; however, life and death is just a simple consequence of the capturing rule. The other foundation is the score at the end of the game. Having an easy way to score let's the beginner experiment with what is alive and what is dead, what is true territory that cannot be invaded. An informal agreement phase with rules that punish a player for trying to play it out is a detriment. Nobody is advocating that you give noobs Tromp-Taylor and letting them figure it out. Just don't give them territory rules with dead-stone agreement as a first ruleset. -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Disputes under Japanese rules
On Mon, 2008-09-15 at 21:05 -0700, Ross Werner wrote: Agreed. Japanese may be bad for computers, but I think it's one of the best rulesets for humans. Ok, tired old topic, tired old response: Japanese rules aren't good for beginners. They also aren't good at resolving disputes (genuine disputes, not just somebody acting stubborn just because they can). -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Congratulations to Leela and to Many Faces!
On Tue, 2008-09-16 at 14:21 +0100, Nick Wedd wrote: I would also appreciate views on my proposal to change the time system used for these events, so that instead of say 18 minutes absolute time, they will use 18 minutes plus 20 stones/20 seconds Canadian overtime. What happens if you get two bots that don't pass? I think you'll have to manually stop the game. Given the current time systems on KGS, I think absolute time is the best way to keep to a fixed schedule. The bot author can reserve a few minutes for a cleanup-phase -- many reasonable approaches to allocating time have been discussed in the past. Alternative time proposal: Have the overtime use a fast Canadian time (like your 20/20), but limited to something like 5 minutes. This way you get the benefit of a fixed schedule and a short cleanup period. I know KGS doesn't support this, but I think it would be a great option for tournaments, both human and computer. -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Congratulations to Leela and to Many Faces!
On Tue, 2008-09-16 at 10:10 -0400, Don Dailey wrote: It's a shame Fischer Timing is not available. A small Fischer increment of 1 or 2 seconds would do the job nicely. It doesn't solve the problem of two programs that don't pass. You can't keep to a fixed schedule if you keep on allowing just a few seconds more ad nauseum. -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Congratulations to Leela and to Many Faces!
On Tue, 2008-09-16 at 12:29 -0400, steve uurtamo wrote: without vast captures of territory, someone will either violate the superko rule or make an illegal move before lots of time passes. It depends on how the bots play. What if you get two bots that each insist on playing in the opponent's territory? If each player has 50 points of territory, this could go on for quite awhile. -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Disputes under Japanese rules
On Wed, 2008-09-17 at 00:00 +0200, Basti Weidemyr wrote: If dame was filled, I see no reason why this would not be possible to implement as a cleanup phase on go-servers, like the one used for new zealand and chinese rules. Do you? It would be the human-adaption of the play-it-out-then-restore-and-count-again, that David mentioned. What you have described are essentially the AGA rules, which David also mentioned. The thing is they are just the Chinese rules in disguise -- dame then becomes worth 1 point, as opposed to Japanese rules. AGA has the peculiar rule about pass stones, and that White must pass last. If you don't have the peculiar rules and try to keep the Japanese idea of dame being worth 0 points, then you get into trouble like pass fights and one-sided dame that should only be played in a dispute phase. I'm not aware of a single source that describes all these issues, but you can Google around for pass fight and Ikeda rules. Sorry to brush you off on further details, but I'm not an authoritive source, though I have gleaned enough over the years to know that Japanese rules are trouble :) -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] 10k UCT bots
The 10k refers to ten thousand playouts, not rank, and yes it's 9x9. As for open source UCT, off the top of my head there's libego (C++) and Orego (Java). -Jeff On Wed, 2008-05-14 at 12:14 -0700, Carter Cheng wrote: I assume this implies that there arent any open-source basic-UCT bots which utilize the basic eye rule and a simple permute and retry scheme as described by many ppl on the group? When we speak of these sorts of bots playing at about 10kyu I assume what is meant is 10kyu at 9x9 not 19x19. --- On Wed, 5/14/08, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] [EMAIL PROTECTED] Subject: Re: [computer-go] 10k UCT bots To: computer-go@computer-go.org Date: Wednesday, May 14, 2008, 10:44 AM -Original Message- From: Jacques Basaldúa [EMAIL PROTECTED] To: computer-go@computer-go.org Sent: Wed, 14 May 2008 6:38 am Subject: Re: [computer-go] 10k UCT bots Don Dailey wrote: [EMAIL PROTECTED] wrote: For those currently coding this up, I think the most important thing about this playout algorithm is that it is *temporary*. You will almost certainly be replacing it with something different and better just a little bit down the road. So you probably don't want to worry about hair-splitting tweaks except as an academic exercise. Yes, I agree. Also my hair brained scheme of pre-generated tables of list traversal orderings was just an academic exercise as you say. But the problem is that when you do heavy playouts you have the same problem except that the probabilities of the legal moves are no longer equal. The problem doesn't go away but the trade-offs change considerably. This is an interesting and relevant discussion, but if I were trying to code up light MC playouts for the first time, right now, I would be feeling that this dead-simple algorithm was actually very difficult and confusing. For someone in that position (and only them), my advice is 1. Implement light playouts first. It's simple; you will find many bugs that way; it's standardized enough that other people will understand what you're talking about; it's a fast way to get a basic bot; it will be a very handy thing to have as a baseline when you test other things. 2. Get it working the standard way before improving it. It's your baseline that you'll be testing improvements against. 3. Make it fast but don't spend excessive effort optimizing. Better is the enemy of good enough. - Dave Hillis___ 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] Congratulations to LeelaBot2 and to CzechBot
On Mon, 2008-05-12 at 21:14 +0200, Gian-Carlo Pascutto wrote: But I still categorically object to the stance that it's the bots or the programmers fault that it forfeits on time. As log as lag is not compensated there is no way to avoid time losses, even if the bot always moves instantly. You can at best improve the odds of this not happening. I disagree. Playing games over the Internet introduces a lag problem. Stuff like timeseal solves one problem and introduces others. How much time are you willing to let the opponent lag? This can introduce scheduling problems and also accusations of cheating to intentionally introduce lag. This accusation was somewhat common when I played on FICS, and disabling timeseal was a frequent topic of discussion. I think playing on the Internet without lag compensation is one of the realities a bot coder should just take into account, the same way a coder must take into account different rulesets depending on the tournament. I liked Jason's approach to measuring the lag. Occasionally somebody will lose a game because of lag. *shrug*, it happens. -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Congratulations to LeelaBot2 and to CzechBot
On Wed, 2008-05-07 at 18:36 +0100, Nick Wedd wrote: If I had the ability to change the way the game-end protocol is implemented, I would do so. I do not know what I would implement, but it might well include Fisher time. However, the implementation is not under my control. My problem is to make the best use of what is provided by KGS. The last time the topic of time came up, it was generally agreed that it is up to the bot to manage its own time, and that absolute time was used to make scheduling easier. Leela lost because it mismanaged its time. I hope you reconsider your position on probabation and assigning wins arbitrarily when nothing out-of-bounds has happened. -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: Re : [computer-go] How to use CGOS ?
On Tue, 2008-02-26 at 12:28 -0500, Don Dailey wrote: Regarding use GTP for the CGOS communication protocol: At one point I actually seriously considered using GTP as the communication protocol for CGOS.It seemed rather cool that it might be possible to hook up a program directly without needing a separate client. It seems like we may have even discussed it on this group. I did discuss this with the gogui people I believe. I found at least one discussion from the early CGOS days. It was part of a larger thread that had nothing to do with CGOS so I'll link to Don's post and you can click the [thread] view from there to see the follow-ups: http://computer-go.org/pipermail/computer-go/2006-March/004903.html It discusses the authentication issues, the socket issues, and nice ideas like being able to re-use GoGui with different servers, like the Random Go Challenge mentioned by Markus: http://www.lysator.liu.se/~gunnar/gtp/random_go_challenge.html One quote from you (Don) stands out: I know this is one of those things I would regret later - not sticking to just 1 way to communicate. Even when it seems like it wouldn't be a big deal - I always kick myself for not following my instinct. I think you should be kicking yourself for not going with GTP all the way through :) A couple of issues made me change my mind. One of them is exactly what Álvaro mentions, the authentication issue.There is nothing in the GTP protocol to cover this and it seemed to be outside the scope of the protocol. You could separate authentication and consider it just a separate step in the process, but this is certainly no simplification. It seems to me adding two GTP commands for login and password is extremely simple, and could always be replaced later by ssh or kerberos or whatever, should the need arise. The other issue is that GTP is normally done over pipes, not sockets. It doesn't really matter how you send and receive the messages of course, but it certainly doesn't make most programs immediately usable. It's easy enough in unix based systems using unix tools but at this point you already using an external program anyway. But they are standard tools and you don't need to install ad-hoc clients for every server that somebody dreams up. The Random Go Challenge page shows how simple it is to convert from a TCP stream to a GTP standard input stream with tcpconnect. A third issue is that I wanted the flexibility to add things not covered by GTP, such as informational messages.I did not want to require people to constantly be modifying their GTP implementations to accommodate CGOS. GTP messages that aren't understood can be ignored. As long as the server only requires the basics from a GTP engine (boardsize, genmove, etc), with everything else optional, I don't see what the problem is. A fourth issue is that wanted to minimize the number of messages passing back and forth. So the CGOS protocol is less verbose in that sense. If I stayed with strict GTP I would be sending a more tiny message back and forth. How much are you saving? The vast majority of commands are genmove w/b followed by a response. That and there's only a handful of people connecting anyways. This sounds like pre-mature optimization. Every few months, I get a private email asking why I didn't use GTP. I think this is the first one sent to the computer-go list. Each time the person believes he is the first to think of the idea. This is overly harsh. There's a difference between asking a why isn't this done this way Frequently Asked Question and believing that you're the first to ask the question. Anyways, I'm glad it was brought up again. I'd like to see a move to GTP for the server -- it's almost GTP anyways. You did say in that old thread I linked to: But if enough people express interest I may very well do this - it's a trivial modification to the server. It seems that there is interest. -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] scalability and transitivity
On Tue, 2008-01-29 at 17:41 -0500, Don Dailey wrote: This is in response to a few posts about the self-test effect in ELO rating tests. [...] So my assertion is that scalability based on sound principles is more or less universal with perhaps a small amount of self-play distortion, but nothing to get too excited about. You've also hypothesized in the past that a scalable program will remain scalable. But then why was FatMan scalable for so long and then flattened out, but MoGo didn't? So I think you can excuse people for reserving some doubt, though in general I find your scalability arguments persuasive. -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] New scalability study progress report
On Fri, 2008-01-18 at 20:31 -0500, Don Dailey wrote: Although it's not on the graph itself, Gnugo-3.7.11 level 10 is set to be 1800.0 ELO. On the web page it says you are using --min-level 8 --max-level 8. Each data point in the x axis represent a doubling in power. There are 13 doublings represented This is a bit confusing. I think it's clearer to say there is 1 baseline and 12 doublings. It's also confusing on the web page that Mogo_01 actually corresponds to 0 doublings in the graph. So if I understand correctly: Mogo_13 = 64 * 2^12 = 262,144 simulations FatMan_13 = 1024 * 2^12 = 4,194,304 simulations Sorry for the minor nitpicks. Looking forward to the results! -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Congratulations to valkyria, and to GNU Go!
On Mon, 2008-01-07 at 14:55 +, Nick Wedd wrote: The event was notable for unjustified resignations. Seems strange so many bots had resignation trouble. Looks like beta code. Probably in response to the Please have your bot resign, for your own good thread? -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Please have your bot resign, for your own good
On Thu, 2008-01-03 at 10:30 -0800, Dave Dyer wrote: CGOS uses Chinese scoring with play-outs so that we can get fully automated scoring with no chance of errors. No chance of errors is vacuously true. Errors, if any, were made in the playout leading to the final state. errors is probably not the best word to use for what Don is describing, since it can be confused with imperfect play. Of course imperfect play is a common occurrence at any point in the game, not just during playout. What Don means is that the game is decided by the skill of the players, and not arbitration by some 3rd party. Not only is this practical to run an automated server, it is true to the spirit of the game. -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Please have your bot resign, for your own good
On Wed, 2008-01-02 at 15:29 -0500, Don Dailey wrote: I am considering to implement Fischer time on CGOS How are you going to deal with keeping the games on a fixed schedule? -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Some Games against MoGo
On Wed, 2007-12-12 at 17:24 +0100, Robert Jasiek wrote: I have played 10 9x9, 6.5 komi, 5 min. games against MoGo release 3 using GoGui's command line path\GoGui\MoGo\mogo.exe under Vista Ultimate 32b on a Core2Duo E6600. The typical mogo.exe's usage of both processors is ca. 48.5% - 50.5%, i.e., one core is used fully while Windows' system services, my personal firewall, and some low time consumption processes have the other core, so to say, but reach a total consumption of only 0% - 5%. Result: My wins: 9 Mogo wins: 1 You might want to try your experiment again using the following flags with MoGo: path\GoGui\MoGo\mogo.exe --9 --pondering 1 --totalTime 300 This will allow MoGo to use it's 9x9 opening database, think on your time, and ensure that it knows correctly how much time it has. Also, note that the download page for MoGo states that under Windows it will only use 1 core and is 30% slower than Linux. If you're really ambitious, you could run MoGo under a live version of Linux. -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] GTP back to basics.
On Tue, 2007-12-04 at 19:45 -0500, Joshua Shriver wrote: Wish computer-go had a google search :) Put this in Google's search box: site:http://computer-go.org/pipermail/computer-go/ foobar Of course, replace foobar with your search terms. -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: Re[2]: [computer-go] use for Monte Carlo on 19X19?
On Tue, 2007-11-06 at 16:30 +0100, Lars Schäfers wrote: By the way: a 9x9 CGOS server using japanese rules... I have a dream.. ;) What formal and automatable Japanese ruleset are you proposing? A computer implementation would also lend credibility. -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] use for Monte Carlo on 19X19?
On Tue, 2007-11-06 at 16:55 -0500, Don Dailey wrote: Hi Jeff, Yes, I agree with your points.Well behaved on CGOS means that your bot will resign as soon as it knows it's losing. I think when a bot should resign is a matter of personal preference. I myself prefer to see games played out if it's somewhat close or very near the end. If there's a handful of moves left what's the point of resigning? But against humans it should technically be the same, but isn't.When playing against humans a bot needs to be able to mark dead groups. I have the same feelings whether it's a bot vs bot game or bot vs human. As for marking dead stones, obviously a bot needs to be able to against humans, and I never suggested otherwise. My only point is that you don't need territory scoring rules for this. -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] use for Monte Carlo on 19X19?
Ok, this is my last post on this topic for a while, promise. On Tue, 2007-11-06 at 17:21 -0500, Jason House wrote: I think having a way to generate a lot of games to test this style of behavior is helpful. I really care little about the rules, except that it provides a mechanism to encourage the human-like behavior that I want my bot to exhibit. This behavior is not dependent on the rules! Even if your monte carlo bot uses territory scoring, it will still play useless moves if it is losing. If you want more human-like behavior, you'll still have to make your program know when to pass under either ruleset. I see no benefit in putting up a territory-based CGOS server that you couldn't have gotten from local experimentation with GnuGo. -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
RE: [computer-go] 19x19 CGOS
On Sun, 2007-10-28 at 11:54 +0100, Edward de Grijs wrote: Hi all, For CGOS 19x19 I prefer a short time control (10min/game) because: 1) More quickly a more accurate rating can be established. I agree with Don. 10 minutes sudden death is brutally short for 19x19. You are limiting the pool and strength of programs available for CGOS. If all you want is a quick and dirty rating for minor updates, why don't you just run your program against Gnu Go and/or MoGo at fast time settings on your own machine? Then when you think you have a stable and significant improvement, run your program on CGOS for a beefier test? This is how MoGo achieved dominance in 9x9. -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
RE: [computer-go] 19x19 CGOS
On Sun, 2007-10-28 at 15:59 +0100, Edward de Grijs wrote: Hi, maybe so, but can you name some programs which cannot cope with 10 minutes thinking time for 19x19? I'm working on my own program, and I don't want to be limited to 10 minutes for 19x19. I'll let others speak about their own programs. Maybe I am confused about the goals of CGOS? I thought that programmers could use it to get a good impression of improvements over time. Sure, to track improvements, but also to see which program is the strongest. Having the strongest program at a very fast speed is not as interesting as having the strongest program at a reasonable speed, for some definition of reasonable. I think getting a very fast rating on minor updates should not be the goal of CGOS -- you can do that on your own machine with Gnu Go, MoGo, and your own test suites. CGOS should be more like a continuous tournament to test major updates of programs. Waiting a day or two to get a rating at reasonable time controls then shouldn't be a big deal. That's my 2 cents, anyways. -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] XML alternatives to SGF
On Tue, 2007-10-23 at 01:16 -0700, Phil G wrote: As a community, I believe we can improve SGF by extending the specification slightly to allow points to also be encoded in standard coordinates and depreciated, admittedly slowly, the use of the old coordinate system. We already see Go programs (SmartGo, GoGui and others) supporting this format. Maybe this can be a key point in the proposed FF[5] specification. As a community, I don't think we should support *breaking* an existing, well-established data format over something as trivial as the coordinate system used. There are much bigger issues with sgf, such as not being able to follow a teaching review that jumps around nodes. What I would support is a new standard that was backwards compatible with existing tools. -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] XML alternatives to SGF
On Tue, 2007-10-23 at 08:42 -0400, Don Dailey wrote: GTP pretty much replace GMP.A lot of resistance because GMP was the defacto standard at the time. It would have been foolish to insist on being backwards compatible. GTP was a huge change in protocol with clear benefits. What's being quibbled over now is minor change in the coordinate system at the cost of breaking all existing tools, with the exception of a couple that have implemented this incompatible change. The benefit does not outweight the cost. -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Former Deep Blue Research working on Go
On Sun, 2007-10-07 at 17:33 -0400, Joshua Shriver wrote: Found this link and thought you all might find it interesting. http://www.spectrum.ieee.org/oct07/5552 Umm, this article was linked to and discussed heavily here within the past week: http://computer-go.org/pipermail/computer-go/2007-October/thread.html#11302 -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Engine development for beginners
On Fri, 2007-07-27 at 18:03 -0700, Joshua Shriver wrote: Are there any really simple engines out there that know just enough to play a legal game of Go? Preferably C, Perl or Java? Have a look at GoGui and the included gtpdummy engine, which plays a random game. It's Java based. If you write your engine to understand GTP, you can then plug it seamlessly in to GoGui. Using GTP also means your engine will be usable on CGOS and KGS and playable against other GTP engines. http://gogui.sourceforge.net/ http://gogui.sourceforge.net/doc/reference-gtpdummy.html -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] OT U. of Alberta bots vs. the Poker pros
On Sat, 2007-07-28 at 13:01 +0100, Tom Cooper wrote: Any variety of poker is sufficiently complicated that it is very difficult to find an optimal mixed strategy, and therefore it is, as far as my interest in it is concerned, very different from Roshambo. I followed the link to Iocaine that Brian posted: http://ofb.net/~egnor/iocaine.html which I ended up following to this link: http://www.cs.ualberta.ca/~darse/rsb-results1.html And this is what Darse Billings, the guy behind Polaris and sponsor of the RoShamBo tournament had to say: Personally, I just want my poker program to play better. :) I don't mean to say that poker is simple, but that a lot of strategy involves rock-paper-scissors psychology, which dilutes the intellectual idea of how strong a program (or person) is. It's interesting in it's own way, but I prefer a game like Go, where the information is perfect but the game is very deep and strength easily measured. In poker there's a huge advantage to knowing your opponent's internal strategy. In Go a stronger player can tell you exactly what he's doing at a high level, but it won't help much because his skill will overcome yours. -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] U. of Alberta bots vs. the Poker pros
On Thu, 2007-07-26 at 18:14 +0200, chrilly wrote: Chess/Go... can be played in an autistic way. There is no need for an opponent model. Ah, an opponent model. Where's the poision? http://www.imdb.com/title/tt0093779/quotes#qt0250635 Too much rock, paper, scissors in poker for my tastes. Can there ever be a best player? At least in Go the differences in strength are very clear, and some guy off the street who learned the game a year ago is not going to win a tournament. -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Some CGOS changes and updated pages
On Mon, 2007-07-16 at 19:46 -0400, Don Dailey wrote: Anyone else have an opinion on this? Sure. I disagree with Gunnar's statement that the engine shouldn't know who is playing or their strengths. Maybe the engine will want to change the way it plays based on the rank. Or maybe between Don's CGOS client and the engine is another GTP controller, written by the bot author, that handles it's own logs. Here's the way I think the current archtecture works: cgos-server - GTP - cgos-client - GTP - [...] - GTP - engine where [...] could be the GTP controller I mentioned above. The point is that all layers use GTP to communicate. Sending the players and ranks is a perfectly valid thing to do. Whether a particular GTP consumer cares about it is determined by asking if the consumer supports the command. So I fully support a command like: cgos-gameinfo FatMan 1800 ggmc-x86-1.3Q 2008 -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Why are different rule sets?
On Thu, 2007-07-12 at 08:50 -0700, Dave Dyer wrote: On the other hand, all the rules arguments in Go are really only applicable to incredibly marginal, bordering on imaginary situations. That ignores the very real problems that many beginners have trying to understand the logic behind Japanese rules. Computer Go has also benefitted tremendously by using Chinese-style rules. I don't think MoGo would have achieved such stunning success in 1 year without them. I also find it ugly that in the small percentage of games where disputes occur, the common solution is to stop the clock and verbally dispute the position, or appeal to a higher authority, instead of having the players finish the game on the board. In tournament play this ugliness is magnified. As a cute example, I recently ran across a KGS game (non-tournament) where a player was complaining that his opponent had lost the game and escaped. After looking at the game, it was clear that the escaper had actually won by half a point, but his opponent didn't agree to the status of a group. He escaped in frustration. The player who misunderstood the position was rated 7k, but it took me several minutes worth of demonstrations before he could understand the position. I have attached the game. Finally, I think the people involved with the AGA rules would be rightfully upset at your summary of the situation. Those interested in their view on the matter can read: http://www.cs.cmu.edu/~wjh/go/rules/AGA.commentary.html In particular, the section Transmittal letter, dated from 1991. Yep, these rule debates have been going on for quite some time. -Jeff Piet-yukatto.sgf Description: application/go-sgf ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Congratulations to GNU and to MoGoBot19!
On Sun, 2007-06-10 at 22:19 -0400, Don Dailey wrote: Did something happen that unfairly caused the player to lose on time? No, but the games were absolute time games where CrazyStone was often in a losing position but ended up winning on time. The endgame in Go takes a long time but is mostly just cleanup. That is why a small amount of time to play each move is usually allowed, even in fast games. The 2k rank is not indicative of how well CrazyStone would play in a typical game of Go. It's like a 1 minute lightning game in Chess; you wouldn't use that to rank a computer. It just isn't very interesting. -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Absolute time in KGS robots
On Mon, 2007-04-09 at 17:36 +0100, Nick Wedd wrote: I have written a short report on yesterday's bot tournament on KGS, it is at http://www.weddslist.com/kgs/past/25/index.html From the writeup: CrazyStone has achieved an implausible 1k rating on KGS. Yes, very implausible. It has only played a handful of ranked 19x19 games. It won two games against a 2k on time in which CrazyStone was getting beaten badly. The time settings were 10 minutes absolute for each side. Absolute time games are bad, at least for humans. Why not have at least a 5 or 10 second byo-yomi for bot vs human games? -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] MoGo
On Thu, 2007-04-05 at 09:17 -0400, Don Dailey wrote: How does Japanese make any difference? Because the vast majority of games use Japanese rules on KGS, I think many players do not notice if they are playing Chinese rules. If they then find out that dame is worth 1 point, they may feel cheated if the opponent plays dame while they pass. I always play by Chinese rules on KGS and I can verify that many players aren't aware that they are playing by Chinese rules, because in my games they often pass when they could be playing dame (and I doubt they counted odd vs even). In that case I pass too; I wouldn't want to take a bunch of points while they kept on passing. Some players who play by Chinese rules will take these points, and so people have become somewhat aware of this issue. I've seen this discussed as a kind of cheating, so perhaps people are thinking of this when they lose by half a point? There is another reason for the negative reaction with regard to monte carlo endgame play -- it is completely unhuman and unaesthetical. It is natural to make safer plays when ahead, but the monte carlo plays are *so* ultra-safe as to look ugly. They are plays no human except an absolute beginner might make. So I think the reaction by humans is to be expected. Obviously playing strength is the most important thing, though if play could appear more reasonable without impacting strength and without too much effort then that would be best. -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Taking the D plunge
On Sat, 2007-03-31 at 16:09 -0400, Don Dailey wrote: I know that the author of D has not emphasized optimizations but I think he is now that it has reached version 1.0 and beyond. I've been following D via their newsgroups. The 1.0 version was a joke. The long wait and big coming out party implied that it was stable and big feature changes would wait for a much later version. In reality, several critical bugs were immediately found (but quickly fixed) after release. The really crazy thing is that it seems like every new 0.001 version brings out changes to the core language. I kid you not; have a look at the Changelog: http://www.digitalmars.com/d/changelog.html The author is working on some pretty drastic stuff, too, trying to make D into a powerful macro language, so that you can build your own domain languages in D. Don't get me wrong, I'm not dismissing the language. D is a cool language and a worthy C/C++ replacement. Walter (the author) does good work at an amazing pace. He even finds time to fix obvious performance problems when they are pointed out. I just wanted to correct the impression that D is stable and being optimized. I'd also say that using C when a sane alternative keeps you within 1.5 the speed of C is nuts, but to each their own :) -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Taking the D plunge
On Sun, 2007-04-01 at 00:43 -0400, Jason House wrote: No const - C++ style const for functions doesn't exist - both const functions and const function parameters Const is one of the major features being worked on. There's huge threads about it in the newsgroup :) Last I read there are going to be *three* varieties of const! Anyways, this is getting way off-topic for the list. Back to lurking. -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: Re[4]: [computer-go] Why not forums?
On Sun, 2007-02-11 at 10:59 -0200, Mark Boon wrote: Don't be discouraged please. The big-mouths don't always represent what the majority thinks. The opinions expressed for not wanting to move to a forum were polite and thoughtful. Calling them big-mouths is uncalled for. It's also quite clear by the number of responses from different people (as opposed to a vocal minority) that the majority does not want to move to a web forum. I agree a forum would be a superior platform. The reasons against it I see posted cling too much to old known ways instead of being open to new possibilities. I have tried web forums many times and they aren't as usable. Something like Slashdot works well on the web because of the sheer volume, and the user moderation keeps it readable. However, the typical list/newsgroup with around 20 messages per day or less does not benefit. It's not a matter of clinging to old ways. It's a matter of bsaic usability that is lost by moving to a web page over a dedicated reader. There's no reason why we can't have a forum that includes an option of having all messages e-mailed to you and allow for posting through an e-mail reply. In that sense it would act the same as the current mailing-list for those who don't like to have any extra features. It's just a matter of finding one that suits our needs best. And has already been mentioned, there's no reason why the *existing* list can't be fed to a web forum, instead of asking people to move. And in fact there is already at least one such web interface that hosts this list: gmane. One particular feature I've come to appreciate on forums is a 'recommendation' feature. Useful for Slashdot; not so useful for a small mailing list. Threading of messages on the same subject is a very useful feature too of course. And also available on many email clients, as has already been mentioned. The number of messages posted to this list is rather limited, so a mailing-list still works. So there's no screaming need for change. Agreed. The thread had died a graceful death, too. *sigh* But if someone can find a good forum to act as a host instead it would be an improvement. Asking people to resubscribe to a new host would not be an improvement. Putting up a forum that seamlessly works with the existing environment (like gmane does) would be ok. -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: Re[2]: [computer-go] Why not forums?
On Fri, 2007-02-09 at 01:35 +0300, Dmitry Kamenetsky wrote: Actually this is all I ever wanted! Now if only I could convince the whole Computer Go community to use it, but that seems unlikely :) Smiley aside, wouldn't it be more constructive to do as somebody else suggested, and use the email list as a feed into whatever interface you prefer? Why ask everybody to switch? -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Gnugo vs commercial programs
On Thu, 2007-01-11 at 07:40 -0500, Don Dailey wrote: Of course there is some questions about how long Moore's law will hold. If you are referring to CPU speed doubling (as opposed to transistor count), then that has been over for at least 5 years. The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software http://www.gotw.ca/publications/concurrency-ddj.htm The problem is that concurrency doesn't scale well. -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Interesting problem
On Wed, 2007-01-03 at 14:05 -0800, David Doshay wrote: I do not think that any apology is needed. The length of the game was due only to a setting you have that is totally appropriate for a Chinese rules tournament game. I don't agree with this at all. Is it appropriate under Japanese rules to continue playing, when the game is lost for sure and all territory has been made? This point has been made before, and yet needs repeating whenever this discussion comes up: Nothing forces you to pass in Japanese rules. A losing computer could keep on playing in the hopes of forcing the opponent out of time or to hit a bug. If a computer program knows how to play the endgame so that it doesn't lose points under Chinese rules, then it should know when to pass, and should do so. There's no need for a game to go on for 500 moves just because Chinese rules are being used. -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
