Re: [computer-go] .. if Monte-Carlo programs would play infinite strong

Maybe I did no explain my point well enough. The problem with infinite is that we get a better approximation to a wrong value. With few simulations we get that value with, say 1/10 error. With an astronomical amount of simulations we get the same value with an error of 1e-200, but it's

[computer-go] Poetry in Motion

My contribution to the Java question: I am working in go for the pleasure and not as much as I would like to. Recently, I was experimenting with the urgency of a shape as a sorting method for ab-pruning. I needed to rotate 7x7 masks. I wrote: Procedure Rotate90cl (var jm: jeitoMask); {

Re: [computer-go] language choices

Dave Dyer wrote: Guys, keep your eyes on the prize. If your only problem is that you need to double your speed, all you have to do is wait 1.5 years. It is not twice as fast, if you write the critical parts in asm its more like 10 times. like assembly language (or C) is almost completely

[computer-go] MC/UCT question

I post this question in the form of a problem whose answer I don't know: *Problem* : At the given position B loses by 5 pts. He has only 1 winning move, which is winning a ladder. For simplification he always has 25 legal moves. The ladder is 20 ply deep. And, as it is the case with ladders, the

Re: [computer-go] Anchor Player

Hideki Kato wrote: In Nihon Kiin's ELO system(1), 1000 ELO is 1 rank, The Elo rating is based on two assumptions: a. The performance of each player in each game is a normally distributed random variable. b. All players performance have the same standard deviation. (This is

Re: [computer-go] Anchor Player

Vlad Dumitrescu wrote: The best move may be a somewhat risky invasion - of course one has to assume the partner will not play perfectly, but everybody does that every time anyway, right? Otherwise nobody would have any hope to win and so nobody would play. I agree. That's easy for humans

Re: [computer-go] Fw: Compensation for handicap plays?

Markus Enzenberger wrote: would it make sense to treat players with handicap as completely different players? For example, GNU Go giving one handicap stone would be a different player and get a rating independent of GNU Go in an even game? I like that !! It would give very valuable

[computer-go] Re: computer-go Digest, Vol 29, Issue 29

Lukasz Lew wrote: The unification needs that *pass* costs one point. And this is only modification needed. Passing when a game is finished is the only Kami No Itte move we, the mortals, can play. Probably, all our other moves are suboptimal. And playing when one should pass, deserves the most

[computer-go] Re: Interesting problem

David Fotland wrote: Most of the world plays be Japanese rules, so any commercial program must implement Japanese rules. I totally agree. A strong chinese player using chinese rules will pick up a point or two during the dame filling stage when playing a strong japanese player. The Chiense

Re: [computer-go] Re: Interesting problem

Hi Don, I know of players who thought Go might be an interesting game, but gave up quickly when they realized they could never play by Japanese rules. I am not saying the opposite, and again, I think the ideal rules for computer championships today are Chinese, but without penalizing pass

[computer-go] To be done before using Japanese rules

Hi Today computer tournaments should be played under Chinese as, I think, most agree. This is a thread about how could Japanese rules be implemented. Open question 1: I think dame has to be filled. Programs like gnugo, even old versions, can to that in fractions of a second per move. Filling

Re: [computer-go] To be done before using Japanese rules

Robert Jasiek wrote: executed solely by the programs versus executed by supervising assistance (like the programmers, software, or referees, etc.) Thats what I suggest: executed by supervising assistance, perfect or not. I think its the only way. Expecting all the programs to agree is not very

Re: [computer-go] UCT memory issues and scalability

Hi, Don Don Dailey wrote: v + sqrt((2*log(t))/(10*n)) .. .. n the number of simulations of this move 1. Does that mean the number in any branch? Do you store an array with the number of times each move is played, no matter in what branch? 2. Do you have some explanation for this expression?

Way off topic, on behalf of physical evidence of the dimension of universe: In an n-dimensional universe any radiation that propagates under common circumstances: 1. Conservation of energy 2. Constant speed 3. Isotropy (same intensity in all directions) satisfies: At a distance d from the

[computer-go] Re: computer-go Digest, Vol 30, Issue 26

Arend Bayer wrote: . . without ever believing anything that some of the strong go players (some a lot stronger than me) have to say. Please, don't think that. I am sure there is more people in this list who, like myself, do not think computer go will do it through global search only. The

Re: [computer-go] Re: Scaling monte carlo up to 19x19

Nick Apperson wrote: There are certain times when this technique is highly useful. ... imagine a board with two walls down the middle bordering on each other I agree. We have to divide the board to create strong programs! But division is a very complicated subject. In the isolated areas UCT

Re: [computer-go] MC Go Effectiveness

Matt Gokey wrote: But what are some of the reasons MC is not even better? 1-Since MC engines don't deal with tactics directly, they're not likely going to play tactical sequences well for low liberty strings, securing eye space, cutting and connecting, ko fights, or ladders, etc. 2-Also because

Re: [computer-go] MC Go Effectiveness

Magnus Persson wrote: This is not a problem for scalability for MC/UCT. It just means that a program .. You are right. I didn't mean it is not scalable, of course it is. What I mean is complexity is not, as one could expect, about ~boardsize^4. (The square of legal moves times the square of

Re: [computer-go] Zobrist hashing with easy transformation comparison

As Antoine de Maricourt says, this weakens the key. I think it is a serious problem and it is a dangerous answer to a small question. I compute hashes and patterns for database lookup eight at a time, which is faster (much more optimizable) than one after the other. Then I also use the smallest

Re: [computer-go] Serializing a very large object in Java

Peter Drake wrote (3 times): Exception in thread main ... . . . and 91.449 bytes later . . . ... (ObjectOutputStream.java:1369) I studied the log file in depth and the problem is . . . . . . (you guessed) using Java ;-) Jacques. BTW. I store this list. If you need your log file in the

Re: [computer-go] Zobrist hashing with easy transformation comparison

Erik van der Werf wrote: And then we get another small questions with a dangerous answer... 1. What makes a question big or small is not a personal preference, but the number of millions times it happens during a game. 1a. Database lookup. Happens very few times (Unfortunately, I must

Re: [computer-go] Zobrist hashing with easy transformation comparison

Hi Erik And what distinguishes database look up from things like transposition table look up? Why wouldn't one use database look up during tree search? The interest in rotation/mirror. In database search, what is good for a position is good for the mirror/rotation. In tree search, rotation of

Re: [computer-go] Big board

David Doshay wrote (on behalf of the 3x3 block of pixels applied repeatedly): But if done all the way to just one pixel it will show the winner. Shouldn't that require some kind of error propagation? In dithering techniques, you count the error produced, because it is not the same to count

Re: [computer-go] Big board. Torus ?

Magnus Persson wrote: ... it is impossible to make eyes when attacks on the eyes has so many directions to escape. Every reasonable well played game will end in seki. I totally agree. In 2D a free stone has 4 liberties. In 3D, 6. In nD, 2n. The higher n, the less interesting. You could give

Re: [computer-go] Big board, ++physics

Ray Tayek wrote: it's also hard to see why 21x21 would be boring (i can see 17x17 being too simple in some sense). There is also the length of a game. 21x21 is 22% bigger in terms of cells. Professional players can work two days on a 19x19 game. Making the board bigger would probably make

Re: [computer-go] Big board, ++physics

Hello igo: igo wrote (on behalf of Making the board bigger would probably make the game weaker for humans. I presume the day a computer is world champion, increasing board size would give the computer even more advantage.): I presume exact the opposite way. Of course, who knows. This is

[computer-go] MC - Estimating a moves true probability of winning

Hello Jason I think what you are trying to do can be done more easily. A. You have a Bernoulli random variable whose result is 0 or 1 following an unknown probability p. (Excuse me for explaining obvious things, this is for anyone who reads it.) You want to estimate p from a random sample. The

Re: [computer-go] MC - Estimating a moves true probability of winning

Hello, Just an explanation on something I may have explained badly. I see we agree in the fundamental. Correcting bias in that estimate should lead to better sampling. This is usually called continuity correction http://en.wikipedia.org/wiki/Continuity_correction. The estimator is not

Re: [computer-go] Re: Big board. Temperature

In CGT the temperature is the difference between the value if you play and the value if you pass. The name question should be answered by a native English speaker, but I guess it is an common use of the word hot. Let's call it hotness ;-) Jacques.

Re: [computer-go] Grid Cosmos

Hi Yoshii I have some questions about your program. 1. Is this a complete go engine? I have renamed the gnugo.exe file in the /exe directory and the program no longer works. If it is not an engine, what is it? 2. The program has a 368 Mb file named Tree_Set in the /exe directory, the pattern

Re: [computer-go] Help me test CGOS

Hi Don Could you provide some minimum protocol documentation so that we do not have to use any scripting language? The tcl script seems very simple. Is it possible to just open greencheeks.homelinux.org:6867, send login and then read/write commands? This way everyone would be free to implement

Re: [computer-go] Time Control for the new CGOS

Is 10 minutes a standard and if so it is standard for 19x19 or 9x9? For 19x19 I find it a little too fast. I would prefer fastest: 4 sec/move (x240 moves) = 16 min slowest: 30 sec/move (x240 moves) = 2 hours I would like to try both. Usually fast because, as you pointed, you get useful

Re: [computer-go] Help me test CGOS

Hellwig Geisse wrote: I just finished the translation of the old TCL script cgosGtp.tcl to plain C . . . Thanks Hellwig . I will try your program tomorrow. I prefer hacking C than tcl because its more transparent. I see what the tcl sends, but I don't know what details it may hide, and these

Re:[computer-go] MoGo

Sylvain Gelly wrote: You should also know that we never claimed that MoGo plays 9x9 go near the level of a professional go player, . . . Just curious: Do 9x9 professionals exist? When we say professional we mean 19x19 professional. Of course, there must be a correlation. One expects an

Re: [computer-go] MoGo

Don Dailey wrote (about big/small wins) It actually surprises me that go players care about this ... One difference with chess is that you don't play chess after the game is over. The comparison could be: the king is captured, the loser keeps playing and then the winner gives the queen for

Re: [computer-go] MoGo

Hello Sylvain Sylvain Gelly wrote: If the program blundered as you said and still wins, it means that the program already won much earlier in the game. You are totally right. I said that in my post already. But what the user thinks is: 1. He was behind, but not desperately behind. 2. The

Re: [computer-go] MoGo

Hello Don Don Dailey wrote: Many people DO play chess after the game is over. They continue to play a game long after they could have resigned. My example wasn't very good but I meant over literally. = The king is captured (changing the rules a little). How does Japanese make any

Re: [computer-go] professional knowledge

Darren Cook wrote: All except joseki-knowledge is board-size independent. Maybe human player's adapt to different board sizes without even noticing. But if you try to model strategy with algorithms it is totally board size dependent. The extreme case is 5x5 where black 3,3 claims the four

Re: [computer-go] The dominance of search (Suzie v. GnuGo)

Don Dailey wrote: I have this idea that perhaps a good evaluation function could replace the play-out portion of the UCT programs. I thought about something similar but only for initializing the counters: introduce 10 fake playouts and estimate the number of wins by a function returning

Re: [computer-go] Simplified MC evaluator ?explained?

Weston Markham wrote: 1. Uniform playouts, as used in practice, are not really uniform over all legal go moves. Generally, pass moves are excluded until necessary, and moves that fill eyelike points are excluded. So, I assume that when you use the word legal, you mean admissible within

[computer-go] Sylvain's results

Thanks Sylvain. Sylvain Gelly wrote: The results are that in order to keep the same winning rate, you have to increase the number of simulations by something a little larger than linear in the board area. From 9x9 to 13x13, you need something like 3 times more simulations for the same

Re: [computer-go] 19x19 Go, scalability with time vs handicap

Christoph Birk wrote: I am sure that Daniel is wrong here ... 2 kyu difference is more like 80% likelyhood of win. That depends on strength. Between a 20 and 22 kyu, it is even lower. But in professional play Daniel should be right. Note that 2 steps means 2 stones handicap. It is clear

Re: [computer-go] analysis of UCT and other bandit algorithms for tree search

Remi Munos wrote: .. only when the tree is very smooth, ie. when the branches that appear good (from obtained rewards so far) are actually good and the branches that appear bad are truly bad. Go is a territorial game. I.e. an accumulative game, therefore when you loose territory you could

Re: [computer-go] 9x9 vs 19x19 (was: computer-go Digest)

Heikki Levanto wrote: I think it is better to stick to 9x9 as the beginners tournament, where it is easy to test new ideas in quick games, and 19x19 as the serious tournament where we can see how good computers are at playing the game like we humans do. I agree 100%. Other board sizes are

[computer-go] June KGS Computer Go tournament: 19x19, an hour each

We all think about UCT all day long, ;-) but universal time is called UTC. The acronym is far from obvious, because: The International Telecommunication Union http://en.wikipedia.org/wiki/International_Telecommunication_Union wanted Coordinated Universal Time to have a single abbreviation for

Re: [computer-go] Efficiently selecting a point to play in a random playout

Lukasz Lew wrote: Is libego too complicated? Do You have problems with compilation? Or You are not comfortable with the GNU license? Any other reason? I only wanted to compare performance ( and see what good ideas you had ;-) ) but could not compile libego. Neither with Microsoft Visual

Re: [computer-go] Efficiently selecting a point to play in a random playout

Hola, Álvaro: Álvaro Begué wrote: Could not compile libego is not a very helpful error message. What exactly did the compiler complain about? My guess is that you don't have the required boost libraries installed. Yes. It must be that. I didn't know about boost libraries. Where can I find

Re: [computer-go] OSS or Free Engines

Hola, Eduardo Eduardo Sabbatella wrote: Take a look at: http://sourceforge.net/projects/javago I get a This project has not yet created any file release packages. message at the mentioned URL. In one of your recent posts you mentioned data mining and that is what I am interested to see how

[computer-go] Opening

Heikki Levanto wrote: I am sure there is a mathematically sound way to measure how symmetric the evaluation is, but my math is a bit rusty, so I am asking if someone can come up with a good way. After that, I'm asking if various programmers would be willing to run this test, and publish the

Re: [computer-go] Congratulations to GNU and to MoGoBot19!

steve uurtamo wrote: true, and a good point. time management other than attempting to equally divide remaining time among the expected number of remaining moves (which itself isn't so easy to estimate) is complicated. But that is so much better than human time management! If the expected

Re: [computer-go] correspondence or turn-based servers

terry mcintyre wrote: Computer Go play in general is nowhere close to dan-level play, but a computer program can read out smaller tactical problems with a very high level of accuracy. That is true. Computers can analyze closed positions as Thomas Wolf's go tools at dan level, but .. .. If

[computer-go] Re: computer-go Digest, Vol 36, Issue 5

George Dahl wrote: Is it still cheating if the program learns and discover's the patterns itself? Then isn't it just precomputing a few things? I agree. Many chess and go grand masters, e.g. Capablanca are supposed to have learned the game as children by watching others play. I do intensive

Re: [computer-go] Explanation to MoGo paper wanted.

Hi, Magnus Magnus Persson wrote: Weak tactics is a problem of the playouts in my opinion. UCT as a general search method has thus little to do with ladders and other game specific details. If there are no tactical mistakes in the playouts the problems disappear. Also tactics has a large

Re: [computer-go] Explanation to MoGo paper wanted.

Don Dailey wrote: I have posted before about the evils of trying to extract knowledge from human games. I don't think it is very effective compared to generating that knowledge from computer games for several reasons. I would agree if we could have quality games played by computers. In

[computer-go] How can one possibly design an optimal playout agent

Peter Drake wrote: 1) If the computation necessary to find better moves is too expensive, performing many dumb playouts may be a better investment. 2) If the playouts are too deterministic, and the moves are merely pretty good, the program may avoid an important move and thus misjudge

[computer-go] Re: computer-go Digest, Vol 36, Issue 6

terry mcintyre wrote: Lately, I've been studying joseki, and I find that it's hard to really know a joseki until you know why non-joseki moves are bad - and why moves which are locally joseki may be bad in relation to other stones on the board. No doubt. That is the most complicated part. I

Re: [computer-go] 9x9 games wanted and the next big challenge

Except for the relation between not finding 9x9 games which is *not* real go, you can find as many 19x19 games as you want, I agree with Chrilly. Let's accept it. We are amateurs, all except those who are paid by some University to research on go. And even some of them are, because a serious go

Re: [computer-go] Explanation to MoGo paper wanted.

Hi, Don I can find arguments to disagree. I think what makes humans homo sapiens is reasoning, not the ability to compute numerical simulations. As a human (I am one) I feel disappointed when the explanation I get for a best move is after x millions of simulated matches it proved to be the

Re: [computer-go] UCT caveat (was in Explanation to MoGo paper wanted)

Brian Slesinsky wrote : When you favor defense (or attack) you may think: This is unbiased since some times it favors black and other times it favors white But the fact is when black is in danger at the root of the tree, it is in danger in most of the tree, therefore the trick gets the

Re: [computer-go] UCT caveat (was in Explanation to MoGo paper wanted)

Brian Slesinsky wrote: And this would mean that a position where black is in trouble would look stronger than in a random playout (due to black playing well only for this kind of situation) which would make it harder to tell which positions are actually good. Or in general, an improvement

Re: [computer-go] Why are different rule sets?

Jason House wrote: I run some really dumb bots online that play perfectly fine blitz games (10s/move) with Chinese rules and it still drives humans insane because the computer doesn't stop playing. People resign won games in endgame because they can't take it. There is some value in reducing

Re: [computer-go] Slides for Villach-EC Lecture

The word in AI I don't feel conformable with is Artificial, not Intelligence. I use _Abstract_ Intelligence (also AI) as a replacement. Have you ever heard of artificial aerodynamics (applicable to planes but not to birds) or artificial thermodynamics (the same). I understand that AI is the

Re: [computer-go] Intelligence

Hideki Kato wrote: Creativity here is, to generate a new method by combining methods the system already has, in order to solve a problem. That is creativity for the job of designing algorithms. Playing go, creativity is finding moves _that work_ that nobody would have thought of. I think

[computer-go] Why Poker-GMs don't win at poker.

Chrilly Donninger wrote: I think poker is more difficult than Go and of course chess. Poker can be analyzed well by (even naif) Monte Carlo methods. Of course, the fact that you get a better estimate than any human could dream of, won't necessarily make you win. This common misconception can

Re: [computer-go] Why Poker-GMs don't win at poker.

Poker can be analyzed well by (even naif) Monte Carlo methods. How? Simulation! Whatever evaluation you need and don't know how to compute because it is too complex for easy formulas can be simulated. This applies to the probability of winning, but also on the betting decisions (call,

[computer-go] Go in hardware

Hi Chrilly: You have mentioned go in hardware twice recently and I have, knowing that you have experience in hardware development, some questions: 1. What should be implemented? In your Hydra cluster I have read you implemented mobility, and somewhere you proposed something like influence. Can

Re: [computer-go] playing strength of programmers

I agree with all those who say it is important, but there is some precision to be made: As a player you are as strong as your weakest link because you are punished for your mistakes. As a programmer you are a strong as your strongest link. You know that mistakes are just mistakes, as long

Re: [computer-go] Update of MoGo binary release, and windows version available!

Thank you Sylvain! It works fine for me. A very good sparring strong and so different in style! You mean that with the .dll in WINDOWS\system32 that goes further? I thought that the .dll in the same directory as the .exe was enough. Copy/pasting from Microsoft's API reference: The function

Re: [computer-go] Re: Most common 3x3 patterns

Cenny Wenner wrote: Care to elaborate on what you mean by scores here and how they are similar to the 9x9 equivalence? I guess Dave is using Bradley Terry scores. This idea was introduced by Rémi Coulom in Computing Elo Ratings of Move Patterns in the Game of Go The paper is available on the

Re: [computer-go] XML alternatives to SGF

Heikki Levanto wrote: Even if a new proposed standard would have many benefits, obvious to everyone (which I have not yet seen), I would stuill urge people to consider those benefits carefully, and to weigh them against the problems that arise from having two incompatible standards. I

RE: [computer-go] XML alternatives to SGF

Bob Myers wrote: Many of those complaining about XML don't seem to really know too much about it. That is exactly my point. I don't know and I don't want to know! SGF is fine. It has been stable for years because there is no problem at all. Should we find a problem, there is a

Re: [computer-go] 19x19 CGOS

Don Dailey wrote: Of course that's better, but I'm talking about a quick and dirty solution. I may never implement handicap games since it's tricky with ELO ratings. This can also be done by the programmers. E.g. If CrazyStone is too strong, Rèmi can introduce a CrazyStoneH3 which passes

Re: [computer-go] Connecting a gtp engine to CGOS 19

Solved! It is working now. The problem was the tcl script does not pass all remaining parameters to the called application (gnugo in the example). To solve this, the command line should be delimited with a quote char. tcl cgos3.tcl testingTCL password E:\\GO\\PROGRAMS\\GnuGo\\gnugo37 --mode

Re: [computer-go] Language

Don Dailey wrote: My Go program doesn't use any libraries except the standard C libraries. I agree at 99.9% !! The only exception in my case is SFMT. http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/index.html SFMT is 100% clean C software, easy to compile, easy to use and free. A good

[computer-go] CGOS 19X19 is down

Hello I was waiting till someone restarts, but nobody seemed to notice. CGOS was hanging yesterday morning (European time) with 3 games 4849..4851 where no black engine placed any stone. If black restarted (one of the black bots was mine) it lost on time because the 30 minutes had been used.

Re: [computer-go] Drunken sailor on payday

Raymond Wold wrote: Do you have anything to back this up? I was under the impression that most decent assembly programmers agreed that they can't compete with the best C compilers. Absolutely NOT. Only the typical, perhaps 99.9% of the programs, made of: transfers, conditionals, integer

Re: [computer-go] New engine? From a Chess programmer perspective.

Christoph Birk wrote: I don't think 2200 ELO on the 9x9 CGOS is equivalent to 'high dan-level' play. Neither do I. In fact the whole kyu/dan rating system applies only to 19x19. 9x9 is not deep enough to have have so many ranks. On a 9x9 board an average amateur beats a pro with handicap 3.

[computer-go] ELO Ratings of move pattern

Lars wrote: Anyone of you have similar or other experiences with the algorithm? I use at runtime the same Bradley-Terry formulas Remí introduces in his paper. That is a huge advance compared to naif urgency scores because it gives a measure of how hard it was to win for a move candidate. But I

[computer-go] Redirecting i/o in the Windows version of Mogo (Was in Re: Update of MoGo binary ..)

Edward de Grijs wrote: Can someone help me with this problem, for which I cannot find a solution: I am trying to run MoGo in an automatic way, using the cygwin toolkit. I guess you are trying to do this in Windows and using the Windows binary. If this is the case, you don't need any library.

[computer-go] Re: The global search myth

Dave Dyer wrote: In cases where the good moves are the obvious ones, you've found them anyway. Ok. Here I agree. In other cases, you prune them away. You are not really pruning, just postponing. Of course you may overlook moves of genius, who doesn't? But if your probabilities are

[computer-go] Microsoft Research Lectures: Akihiro Kishimoto

David Stern wrote: Akihiro's talk has finally been put online at: http://content.digitalwell.washington.edu/msr/external_release_talks_12_05_2005/15004/lecture.htm Good lecture. Is there a link to a binary (or source code) somewhere ? I can't find any TsumeGo Explorer website. At

Re: [computer-go] Microsoft Research Lectures: Akihiro Kishimoto

Thank you, Harri. It sounds promising. I will have a look at that. Jacques. I coded algorithm based for that representation, it really looks another awesome thing worth of investigating. Planning to use that for at least small board search investigations as it has quite much power. That

Re: [computer-go] A thought about Bot-server communications

Nick Wedd wrote: In one of the British Championship Match games, a bit over ten years ago, Zhang Shutai made an illegal ko move against Matthew Macfadyen, and immediately conceded that he had lost the game. Is the game record available? I am interested because I have only found 2 situations

Re: [computer-go] rotate board

Ben Lambrechts wrote: Now I got the following problem: how to rotate/mirror the board for a unique representation. Both are the same board, but has anyone made an algorithm that rotates the board or an area of the board in a unique way? I don't need the move order, just the snapshot of the

Re: [computer-go] rotate board

Don Dailey wrote: You can use Zobrist hashing for maintaining all 8 keys incrementally, but you probably need a fairly good reason to do so. Incrementally updating of 1 key is almost free, but 8 might be noticeable if you are doing it inside a tree search or play-outs. Yes. Don is

Forrest Curo wrote (quoting David Fotland): for example, go books make a big deal about where to extend along the side, or when to play in one corner or another, but the difference between these various moves is usually only a few points. The difference between similar-appearing various moves

The problem is avoiding that an inferior program wins a lost position on time extending the number of moves. If you could choose, what side would you prefer to be? As a human, there is no doubt. But as a program it is even better: the strongest program. Because computers can play faster than

[computer-go] Is CGOS sending TIME_LEFT?

Hi.. My gtp program does not receive any time_left commands. I have checked that the command is listed without mistakes in list_commands. I even tried CGOS 9x9 and I get the same sequence. Jacques. -- This is a 19x19 game start (after

Re: [computer-go] Is CGOS sending TIME_LEFT?

Hi Don The client does not sent time_left unless time_settings is also implemented.So your engine must also implement time_settings which is needed to inform your program of the level it will be playing at. I do implement time_settings. The server only sends a list_commands at the

Re: [computer-go] Is CGOS sending TIME_LEFT?

Hi Don I noticed that your list is upper-case. This might be the problem. I don't remember if GTP is case sensitive or not, but I'm pretty sure cgos requires lower case in these commands. Thank you. That was the problem. It was uppercase. To make it case insensitive, I convert all input to

Re: [computer-go] How to get more participation in 19x19 CGOS?

Don Dailey wrote: My suggest to Olivier is to compromise and set time control 20 minutes per side and give 1 second gift. That's good for me. Until now, I have been running tests and gnugo clones just to support the server, but I will start serious work soon. I have some time for computer

Re: [computer-go] cgos from windows

I think you are right about the tclkit exe. I used the one that the instruction page linked, which does throw up a GUI if you run it with no args. I wonder if it even works. It appears to be a way to cripple the server. It does work. I have played over 600 games with it. It does not

[computer-go] Suicide question

Gian-Carlo Pascutto wrote: Multi-stone suicide is allowed, single stone not. I hadn't even considered suicide.(It would be a major change for me, as neither my Gui nor my board system allow such moves.) The question is Why do you do it? a. Just in case you wanted the entire program to

Re: [computer-go] Suicide question

Michael Wing wrote: In my program (which implements undo), the cost of for suicide detection is around 1%, which means it would lose 1.5 ELO points. In programs that somehow maintain lists of legal moves or even probability distribution functions over the legal moves, avoiding suicide is

Re: [computer-go] Suicide question

Hi Michael Another cost is undo. Superko requires undo, unless you want store a hash value with each chain of stones. I am not sure exactly what undo costs, but lets say 5% to 10%. Well, every implementation is different. In its slowest mode, my board stores information about neighbor stones

Re: [computer-go] 19x19 cgos ranking page

Olivier Teytaud wrote: the 19x19 CGOS ranking page is back (but might be still unstable) and Leela seemingly performs quite well. The crosstables will come back soon also. The crosstables are back, but the sgf archives ar not. I get: Forbidden You don't have permission to access

Re: [computer-go] New scalability study : show uncertainty ?

Hideki Kato wrote: It's rather odd. I'm checking the log file and then I will check the source code to see if I have some artificial limits in there. Why odd? It all depends on the bias or policy of simulations. If there is a flaw in the policy, the score will converses to the score

Re: [computer-go] New scalability study : show uncertainty ?

I don't think only uniformly random playouts will scale to perfection because what we need for playouts is not just a simple average of final scores but a maximum (in negmax sense) score. It should be the perfect evaluation function. In other words, as MC simulation is a way to get an

Re: [computer-go] 19x19 Study - prior in bayeselo, and KGS study

Dave Hillis wrote: I've noticed this in games on KGS; a lot of people lose games with generous time limits because they, rashly, try to keep up with my dumb but very fast bot and make blunders. What Don says about humans scaling applies to humans making an effort to use the time they have,

[computer-go] Re: 19x19 Study. Nakade is difficult

I mentioned nakade in a list including not filling own eyes. Perhaps, not filling own eyes is a simpler example: | . . . . . . . | . # # . # . . | . O # . # . . | O O O . # # . | # # O O O # . | . # # . . . . --- (Unless I made a mistake: Black to play and a1 is the only move