Re: [computer-go] 19x19 game strategy.

Andrés Domínguez wrote: >Also, as white with komi, is very easy to defeat a pure mirror go program .. >Tengen has not points if you don't use it. It is even easier if you capture tengen as in this example where white (O) moves at (a) and captures. The [X] at the center is the initial black at

Re: [computer-go] A plan for building a 7x7 GO solver.

Don Dailey wrote: >Another question is how many illegal board configurations are there ... >by assigning each point on the board a random state of (white,black,empty) That does not represent real game positions. All positions have about 7x7x2/3 = 33 stones. (A normal distribution assuming the st

Re: [computer-go] When is Pass the best move?

Don Dailey wrote: The only reason to have a KO rule is to prevent by force, long cycles. So I don't see a point in imposing more restrictive conditions than necessary. Talking about superko, I agree at 100%. John Tromp's arguments are sound and probably the best from the _ruleset's_ point of

[computer-go] How do you insert Go diagrams into papers?

Anton Safonov wrote: >- to convert sgf or graphical board setup into images to be inserted >into Word (powerful ActiveX control will also work, but e.g. RenderSoft >Corinnax Go Control didn't suit me); >- arbitrary board sizes and also partial boards (e.g. corner); >- not just the moves, but als

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

Chrilly wrote: (thread was "Positions illustrative of computer stupidity") With an infinite fast chip chess programs would be "infinite" strong. Most current Go programs would only play infinite fast. Its an interesting question if Monte-Carlo programs would also play infinite strong. I thin

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 still

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

Thank you Magnus, you are right about UCT. I misunderstood it. But the essence of my post is still valid, even if not applicable to UCT. Simulation is a very sound, stable and "blunder-avoiding" value of a board position, but it does not represent perfect play. This is something that should not

[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 a

[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

I would like to take part in the 19x19 competition. I also prefer kyu rating to Elo, but I got the impression that you were relating kyu rating with handicap games (that is usually done by human players). I think handicap is a bad idea for computers. Handicap requires human intelligence to unders

Re: [computer-go] Anchor Player

Hideki Kato wrote: Increasing KOMI is much easier than placing stones, right? Stuart A. Yeates wrote: Increasing komi is much easier than placing stores, but a much weaker representation of how go games are actually played in the real world. A very huge komi >30 points, apparently solves th

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 controversial

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 to

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 informat

Re: [computer-go] Interesting problem

Aloril wrote: Actually given *enough* games "fully random including eye filling and passing moves" will win against a pro player. That is "true", at least as it is true that a monkey would write Hamlet typing at random long enough. That probability is in the range of 1 to (x·100)^(y·100) wh

[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 m

Re: [computer-go] Interesting problem

Don Dailey wrote: >Your odds of finding a "winning move against a pro >player" is different from finding one of the "best >move(s)" in the position, ... I agree. I was oversimplifying. It would be more appropriate to say: Except, probably for the first moves (as you point correctly, where the nu

[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 >Chiens

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 mov

[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 dam

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 ve

Re: [computer-go] Way MC plays

Jonas Kahn wrote: > I mean, if Crazy Stone played against himself from the position where > Katsunari was thought to be ahead, would he win with its original color, > or with Katsunari's ? That is a very big question. I hope it would win with Katsunari's stones *if* Katsunari was really ahead.

Re: [computer-go] Way MC plays

Don Dailey wrote: I personally have serious doubts about knowledge extraction from human games, but I hope you have success.I think you can get more from computer games of strong players even though the level is weaker. Here is why I say that: 1. A strong computer still plays a lot of go

Re: endgame (Was [computer-go] Re: Should 9x9 komi be 8.0 ?])

> Petr Baudis wrote: > >> MoGo can indeed play out some rather spectacular ko fights; > >> unfortunately, I couldn't find any quickly, so here is at least an > >> example of a shorter one. > I see you made the following comment in that game record, which seems > relevant to recent discussions he

Re: [computer-go] State of the art of pattern matching (Oops)

"Santiago" wrote: ... Oops, wrong name ... (Santiago is my official name, because I was born in a dictatorship that did not allow foreign names. After that, I was too lazy to change it. Jacques, like my French grandfather, is my real name.) Jacques.

Re: [computer-go] State of the art of pattern matching

Mark Boon wrote: Sorry, without a bit more explanation, the assembler code is very hard to understand. What exactly does it do? The first source code was just an example to see what kind of code is generated. The second is useful, if you understand asm you should understand it. The board has

Re: [computer-go] State of the art of pattern matching

terry mcintyre wrote: It is possible to get some remarkably high correlation between the moves played by pros and a predictor - yet still not have a good program. Why? We have a random variable, the place at which a player plays, and some variables that we can compute. The distribution of the

Re: [computer-go] State of the art of pattern matching

Mark Boon wrote: > I suppose there's no reason why it has to be assembler, > you could just as well generate C-code. I don't think so. But I don't write that much asm as it may appear. I see what the compiler writes when I debug and write critical parts only. And automatically generated code.

Re: [computer-go] State of the art of pattern matching

Mark Boon wrote: >There are 16 4-distance points, so if you spill ino that by one > point you get 315 or a little over 14 million patterns. Multiplied > by 3 for every don't-care point within less than 4 distance. Ouch. True, but the number of patterns is learned automatically. When I first lea

Re: [computer-go] State of the art of pattern matching

82.3%. I don't know why. Jacques. Łukasz Lew wrote: On Sat, Mar 29, 2008 at 3:47 PM, Jacques Basaldúa <[EMAIL PROTECTED]> wrote: Mark Boon wrote: > I suppose there's no reason why it has to be assembler, > you could just as well generate C-code. I don't think so. Bu

Re: [computer-go] State of the art of pattern matching

Jonas Kahn wrote: > I guess you have checked that with your rules for getting probability > distributions out of gammas, the mean of the probability of your move 1 > was that that you observed (about 40 %) ? If I understand your post, there may be a misunderstanding by my fault. Here gamma is no

Re: [computer-go] Paper for AAAI (David Silver) PDF problem

Hi David http://www.cs.ualberta.ca/~silver/research/publications/files/MoGoNectar.pdf Your paper has a PDF problem concerning "embedded font BXGQFO+CMR12". I have used different versions of Adobe Reader. I even updated one of the computers to the latest version and I still cannot read any math

Re: [computer-go] Paper for AAAI (David Silver) PDF problem

Thanks, Hideki > I have the same problem with version 7.0.7 of Adobe Reader but > version 8.1.2 works fine. That was the problem. I used the automatic upgrade "feature", but that only upgrades to the latest 7.xx version not to version 8.xx. Don Dailey wrote: "... this general distaste of feeli

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 proba

[computer-go] Counting the final score with seki

Hi all, When you detect self atari in the playouts (something I haven't tried yet, but from recent posts in this group I am convinced that it is an important issue) a new problem arises: How can you score the board _fast_ at the end? My previous version killed all groups in seki and scanned s

[computer-go] MoGo v.s. Kim rematch (Jason House's paper)

> "The approach of this paper is to treat all win rate estimations as independent estimators with additive white Gaussian noise. " Have you tried if that works? (As Łukasz Lew wrote "experimental setup would be useful") I guess there may be a flaw in your idea, but I am not a specialist. I will

[computer-go] [Fwd: ICGA Events 2009 in Pamplona]

Good news! I am very happy the ICGA has chosen Pamplona. Other destinations (e.g. Beijing) are more attractive, but way out of my reach. I can travel to Pamplona easily, but cannot find the details. The website at http://www.icga.org/ is not updated and the attached .eml file contains 2 .pdf f

Re: [computer-go] Rules for remote play at the Computer Olympiad

> About the "thinking process" log. Enabling debugging options can result in serious performance loss. In my system only the "admin thread" can do such things as tree dumps and that makes all other "pawn threads" idle. I don't think such preventive measures are justified. In case of doubt, it

[computer-go] Fuego 04 native Windows

I have made a native Windows Fuego build compiled with MS Visual Studio 2008. Thanks to the Fuego team for making such a nice program free software !! I will use it to measure some tree metrics to tune my own program and for a validation experiment for an evaluation function I have developed.

[computer-go] [Fwd: Announcement ICGA Events 2010]

Is it possible to participate in these tournaments remotely? I think I would like to start participating in these, but I certainly have no budget (or time) to travel outside of Europe. :-( Petr "Pasky" Baudis For the ICGA Computer Olympiad, there should be no pro

Re: [computer-go] still an outstanding command

I think it is OK to lose the one game where it crashes, but it should be able to restart for new games at least. Martin You can restart everything Ok, but you have to kill the process java.exe and then run kgsgtp again. When the program crashes, the clock is still running, I think. If it is

Re: [computer-go] Can Go be solved???... PLEASE help!

A quibble: Go is already solved, but not when the board is empty! It may sound stupid and obvious but I think its a good starting point. Even between two 20kyu players, when the board is solved and there is only a 1-cell gap between the walls and the border, the last 4 moves threaten, block, conn

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

Re: [computer-go] Can Go be solved???... PLEASE help!

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 sour

[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] Is skill transitive? No.

Don Dailey wrote: It would be interesting if it would be possible to construct a 2 dimensional model statistically. A 2 dimensional system would not be a perfect fit either, but would simply be a better approximation. And another constraint is, it must be supported by evidence. I think this p

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 o

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

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 say

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] Zobrist hashing with easy transformation comparison

Hi Erik So please tell us, if the topic is really that 'big', how many bits does your hash-strengthening procedure safe, compared to the average uniform random key generator with some basic checking? 1. As I told, I compute 64 bit hashes for the whole board, but since the lowest 32 bits are s

Re: [computer-go] Big board

Weston Markham wrote: However, I was puzzled at the time because I had expected my inability to visualize the interactions across the edge of the board. That is true with a physical board, but a computer program can automatically copy rows and columns as necessary to support infinite scrollin

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 gi

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 th

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 e

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 r

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 li

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 th

Re: [computer-go] Help me test CGOS

Don Dailey wrote: I have several binary clients for the prototype server that do not require tcl to be installed. Several people have reported issues with tcl versions and such. These clients are just temporary but will work with the protoype test 2 minute server. Sorry. I hadn't read so f

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 res

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 the

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 Olymp

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 n

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 e

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 differ

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 cor

[computer-go] Simplified MC evaluator ¿explained?

Daniel Liu wrote: An imperfect evaluation has errors. Is the exact value of the error known? No. I have an idea on that I will try to explain: Given any finite combinatorial game where the ending nodes have two possible values: win/loss, any node has a "winning rate" (I ignore if there is a

Re: [computer-go] Simplified MC eva luator ¿explained?

I will try to explain it better: What had puzzled me until recently is how to combine two facts: a. As Jason says, "A single MC playout corresponds to a Bernoulli trial with probability p" and therefore, p-hat is distributed as a binomial which converges to the normal. b. The playout itself is

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 somet

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

Martin Müller Pedersen wrote: See also: http://en.wikipedia.org/wiki/Bernoulli_process Regards That was obvious from the beginning and is applicable to any experiment of probability p. It is the playout's case because: same initial conditions => same p. But my post goes a lot further than tha

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 wi

[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 th

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 size

Re: [computer-go] Progressive unpruning in Mango 19x19

I am not an English speaker. I read both verbs for the first time in a mid-80s MS/DOS program called PC-Tools (Central Point Software). It was the first MS/DOS program that was able to move a complete directory from one path to another and it called that "pruning" and "grafting". Since then, ma

[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 wanted Coordinated Universal Time to have a single abbreviation f

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 Stud

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 f

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

For the problem in which moves have probability in {0, 1/n} of being selected (n = number of legal moves or empty points depending on the approach), what Don does, i.e.: Keeping a vector of selectable/not selectable points with a moving limit: When you have to fill a gap, do it immediately by mov

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

Thank you for your ideas. The shapes Rémi is using have values as high as 143473. Of course, that would invalidate my idea. But I planned trimming the upper probability to a reasonable number, say 100 as scaling everything to a 1..100 scale (in the runtime database). I don't know yet if that make

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

[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

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 expect

Re: [computer-go] scalability study - final results

Don Dailey wrote: > I don't know if this is very popular any longer due to the > Internet but I'm going back a few years. I am afraid today a postal chess game is a computer analyst against another computer analyst. An interesting challenge, no doubt, but that has little to do with chess. Anoth

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

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

chrilly wrote: The results in Go are spectacular, because the quality of conventional evaluations is low. There is more than that. As the proverb states "Go is a territorial game". You win a game of go by wining points and at the end one point is one point no matter where it is. This accumul

[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 impa

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 19x19

[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 t

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

Don Dailey wrote: For instance, in a set of master games what feedback do I have about each move other than that it was chosen? How do I get the opinion of the master player concerning the moves played and not played? Just an example: Search corner joseki sequences played often enough. Onc

[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

  1   2   >