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

If the search was depth first, and you seeded the search with some well played games, then alpha beta pruning ought to result in some truely enormous reductions in the search space. ___ computer-go mailing list computer-go@computer-go.org http://www.com

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

The absolute truth (when pass is the best move) is not relevant to the current state of the art. The only case that matters, where a pass is the best move globally, is when the game is over. A program should only pass when some heuristics suggest the end is near (board nearly full, etc) and whe

[computer-go] Re: How to improve my minimax speed?

Just as a caveat, keep in mind that alpha-beta is only guaranteed to not affect the result if the rest of your search is completely deterministic. While that's a good first order approximation to the truth, it's rarely actually true in anything as complex as a Go program. For example, if one p

[computer-go] Re: language choices

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. All this talk of optimizing speed by tweaking language xx to be more like assembly language (or C) is almost completely a waste of time. Likewise, algoritmic opt

Re: [computer-go] 19x19 CGOS?

There's still plenty of juice left at boardspace, so feel free to host more experiments at cgos.boardspace.net ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/

[computer-go] Re: komi argument = silly

To a first order approximation, would changing the komi change the rankings? Presumably, programs are playing the same number of games as black and white, so any "unfair" advantage or disadvantage black has would balance out. Komi only matters when there is only one game between a pair of oppon

[computer-go] off topic: Tobacco

> >By the way, has anyone seen the Philip Morris commercials? I believe they were forced into this as part of the extortion by the state attorneys general. It's Penance for illegally targeting young non-smokers with Joe Camel, and promoting their products while denying that they were dangero

[computer-go] Re: My experience with Linux

The thing that really kills multiple platform programs are GUIs. Unless your GUI is "born" expecting to be cross platform, you're pretty much screwed. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listin

[computer-go] Re: linux and windows

At 09:29 AM 7/17/2008, David Fotland wrote: >It irks me a little that Linux people refuse to consider porting their >programs to Windows :) With cygwin, it's pretty easy to port Linux >programs. Isn't it the case that Cygwin is no help if the program has a GUI.

[computer-go] Re: linux and windows

At 09:29 AM 7/17/2008, David Fotland wrote: >It irks me a little that Linux people refuse to consider porting their >programs to Windows :) With cygwin, it's pretty easy to port Linux >programs. Isn't it the case that Cygwin is no help if the program has a GUI.

[computer-go] Re: tournaments

One possibility is to use one of the VM products that are available to host unix on a windows machine, or windows on a unix machine. VirtualBox looks particilarly promising, since it's free and available for all the common platforms. There is some performance penalty associated with the virtual

[computer-go] Re: tournaments

One possibility is to use one of the VM products that are available to host unix on a windows machine, or windows on a unix machine. VirtualBox looks particilarly promising, since it's free and available for all the common platforms. There is some performance penalty associated with the virtual

[computer-go] Re: linux and windows

> >Of course C can be more or less platform independent if you take some care. Purely for engine code, that's true. Standard windows has APIs that are nearly compatible with xxux for command line initialization and ordinary file and network operations. If your program has ANY gui at all t

[computer-go] re: What Do You Need Most?

Boardspace is a VPS, so CGOS is currently running as a subaccount of a VPS. Boardspace is going to be upgraded sometime in the next few months, which will allow me to add another 1GB to CGOS allocation. Or, if computer Go gets a rich sugar daddy, spending $400/yr for your own VPS would be an exc

[computer-go] Re: Java SGF Parser

> >1) Does anybody know of a good Java SGF parser out there? I have one I've used for many types of games, including Go. I've used it to represent large collections with no problems. ___ computer-go mailing list computer-go@computer-go.org http://www

[computer-go] Re: Java SGF Parser

> >1) Does anybody know of a good Java SGF parser out there? I have one I've used for many types of games, including Go. I've used it to represent large collections with no problems. ___ computer-go mailing list computer-go@computer-go.org http://www

[computer-go] Re: mogo beats pro!

I watched all the games, and I must say, mogo performed really badly at the blitz games, and quite a bit better at the 1-hour game. I'd still take any claims of dan level play with lots of salt. My take-away from watching the match is that blitz performance wasn't at all representative. A human

[computer-go] Re: Program don't start playing on CGOS

> >I'm really very weak on networking so I'm not sure what I'm actually >reading or whether this fix needs to be applied on the server end or the >client end. Any ideas is this is relevant? You also have the same problem, but with much less real information, if the client end end of the connect

[computer-go] Re: Program don't start playing on CGOS

> >I'm really very weak on networking so I'm not sure what I'm actually >reading or whether this fix needs to be applied on the server end or the >client end. Any ideas is this is relevant? You also have the same problem, but with much less real information, if the client end end of the connect

[computer-go] Re: What's happening at the European Go Congress?

I think the result "computer in hopelessly lost position resigns." is much more satisfactory than "computer in hopelessly lost position wins by playing 100 additional pointless moves" I think a human who used this tactic in a tournament situation might win the trophy, but would be unable t

[computer-go] Re: What's happening at the European Go Congress?

I think the result "computer in hopelessly lost position resigns." is much more satisfactory than "computer in hopelessly lost position wins by playing 100 additional pointless moves" I think a human who used this tactic in a tournament situation might win the trophy, but would be unable t

[computer-go] Re: Some thoughts on the event in Leksand

>This was typically to pick up my queen, change its colour, and >> capture my rook with it. > >Now there's a feature that would make a tournament interesting... If this appeals to you, try Martian Chess or Shogi ___ computer-go mailing list computer-go

[computer-go] Re: Disputes under Japanese rules

>Japanese: bad. I don't think this is the case at all. The Japanese rules are just a human optimization, to avoid having to make the last 100 meaningless moves, and still arrive at the correct score with a minimum of extraneous manipulation. The tortured details, while not elegant, rarely m

[computer-go] Re: Disputes under Japanese rules

The formalized rules are the "tortured details" I referred to. I've played thousands of games of Go, and I've never even seen any of those versions of the rules. The Japanese rules I refer to are the informal procedures I use every time I play, both to estimate the score during the game, and at

[computer-go] Re: reference bots testing.

I suggest you add an identical RNG for testing purposes, which you will know is identical in both implementations even if it is not ideal. Run a test with a seeded random sequence which should provide identical playouts. ___ computer-go mailing list c

[computer-go] Re: Git, any other ideas?

For those of you who use windows, I highly recommend tortoise cvs and tortoise svn, which map access to whichever repository you prefer into an incredibly useful and intuitive interface piggybacked on windows explorer. ___ computer-go mailing list compu

[computer-go] Re: Git, any other ideas?

For those of you who use windows, I highly recommend tortoise cvs and tortoise svn, which map access to whichever repository you prefer into an incredibly useful and intuitive interface piggybacked on windows explorer. ___ computer-go mailing list compu

[computer-go] Re: OT: Harder than go?

I think the question is largely meaningless, because few games have been studied by humans (or human computer programmers) with the depth and intensity that has been achieved for games like chess and go. In general, games with many choices and no obvious strategies are good for people and bad for

[computer-go] Re: Another enhancement to AMAF

Here's a chance to share an amusing and illustrative anecdote. I was working on optimizing "Goodbot", a program that plays Tantrix, and because of the nature of the game, the only way to really qualify an improvement is to run many test games against a standard opponent. At one point, I was mak

[computer-go] Re: Another enhancement to AMAF

Here's a chance to share an amusing and illustrative anecdote. I was working on optimizing "Goodbot", a program that plays Tantrix, and because of the nature of the game, the only way to really qualify an improvement is to run many test games against a standard opponent. At one point, I was mak

[computer-go] Re: flash crowd from TV

> >That's impressive, especially considering the fairly long search path between >"Go" and "igowin". It happens. One day recently I was idling at boardspace.net, when in the course a few minutes the site was overrun by about 30 guests, all speaking German and wanting to play Hex. It turned ou

[computer-go] Re: hex robot

At 01:31 PM 11/26/2008, Denis fidaali wrote: >Speaking of hex ... I really think it would be a nice intermediary game before >tackling the complexity of go. Do you know of any good community (and protocol >equivalent to GTP) where i could start to look for submitting a bot ? There are a couple o

[computer-go] Re: hex robot

At 01:52 AM 11/27/2008, Denis fidaali wrote: ... > But what really lacks (or i wasn't able to find anyway) is a strong community > like there is for go. > > A CGOS equivalent. > A GTP equivalent. > A Gogui equivalent. > A Kgs equivalent. I don't think there's a match between your goals and what

[computer-go] RE: hex robot

Permit me to play the skeptic here; I think you're going about it absolutely backwards - unless you already have a strong algorithm which depends on 128 bit rotations, and only lack an efficient hardware engine to run it on. If your idea of fun is to really feel the bits squishing between your

[computer-go] Re: Hardware limits

I think general hardware limits are good, because they will permit more teams to be competitive without altering the nature of the competition. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/comp

[computer-go] Re: Hardware limits

Lets look at it another way - no one would care what hardware you choose to use, unless you win. So at the very least, you ought to be able to use arbitrary hardware until it becomes established that only that class of hardware can win. ___ computer-

[computer-go] Re: Is computer Havannah welcome here?

There's already a "havannah" section on this game programming forum: http://www.grappa.univ-lille3.fr/ -- which could use an influx of traffic. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/compute

[computer-go] Re: remote time measurement

My theory is that the organizers of tournaments with remote participants could appoint official observers, to observe the operators at the remote end of connections. Not foolproof, but simple and doesn't interfere with the conduct of the tournament. __

[computer-go] Re: remote time measurement

At 12:59 AM 2/4/2009, David Fotland wrote: >What do you mean by operator at remote end? In my case, the program was >running on a cluster at Microsoft in some computer data center. There was >no operator at Microsoft. The cluster was operated from Beijing through a >remote desktop. The operator

[computer-go] Re: static evaluators for tree search

While your goal is laudable, I'm afraid there is no such thing as a "simple" tree search with a plug-in evaluator for Go. The problem is that the move generator has to be very disciplined, and the evaluator typically requires elaborate and expensive to maintain data structures. It all tends to b

[computer-go] Re: static evaluators for tree search

>Do you mean that the evaluator might be used during move ordering somehow >and that generating the nodes to expand is tightly coupled with the static >evaluator? That's the general idea. No search program can afford to use a fan-out factor of 361. The information about what to cut has to co

[computer-go] Re: static evaluators for tree search

>Do you mean that the evaluator might be used during move ordering somehow >and that generating the nodes to expand is tightly coupled with the static >evaluator? That's the general idea. No search program can afford to use a fan-out factor of 361. The information about what to cut has to co

[computer-go] Re: static evaluators for tree search

This is old and incomplete, but still is a starting point you might find useful http://www.andromeda.com/people/ddyer/go/global-eval.html General observations (from a weak player's point of view): Go is played on a knife edge between life and death. The only evaluator that matters is "is thi

[computer-go] cgos: Donn Daily?

Donn, your email at d...@mit.edu is bouncing. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/

[computer-go] Berlekamp lecture on mathematical Go

Highly recommended Mathematics and Go by Elwyn Berlekamp ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/lis

[computer-go] Re: Implications of a CPU vs Memory trend on MCTS

Storing an opening book for the first 10 moves requires 331477745148242200 nodes. Even with some reduction for symmetry, I don't see that much memory becoming available anytime soon, and you still have to evaluate them somehow. Actually storing a tree, except for extremely limited speci

[computer-go] Re: Implications of a CPU vs Memory trend on MCTS

At 02:13 PM 5/12/2009, Michael Williams wrote: >Where does your 99% figure come from? 1/361 < 1% by endgame there are still easily 100 empty spaces on the board. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailm

[computer-go] Re: Implications of a CPU vs Memory trend on MCTS

At 02:13 PM 5/12/2009, Michael Williams wrote: >Where does your 99% figure come from? 1/361 < 1% by endgame there are still easily 100 empty spaces on the board. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailm

[computer-go] Re: Implications of a CPU vs Memory trend on MCTS

An essential feature of monte carlo is that it's search space is random and extremely sparse, so consequently opportunity to re-use nodes is also extremely sparse. On the other hand, if the search close to the root is not sparse, my previous arguments about the number of nodes and the number of t

Re: [personal] Re: [computer-go] Re: Implications of a CPU vs Memory trend on MCTS

> >I assume Dave Dyer does not understand alpha beta pruning either, or he would >not assume the branching factor is 361. The branch at the root is about (361-move number) - you have to consider all top level moves. A/B only kicks in by lowering the average branching factor at lower le

[computer-go] Re: Implications of a CPU vs Memory trend on MCTS

> >If I use persistent storage and do that search again in another game, I can >start exactly where I left off and generate 50,000 more nodes. It will be >the same as if I did 100,000 nodes instead of 50,000 nodes.Or put another >way, it will be the same as if I spent 20 seconds on thi

[computer-go] Re: Implications of a CPU vs Memory trend on MCTS

>> >>But then MCTS is invalid. The point is that you do spend time learning that >>these nodes are not relevant, so you might as well try to remember that. It is invalid. It's just a heuristic that is working within the current domain. >>If you are playing a game of chess and fall for a trap

[computer-go] Re: verifiable claims

Some lines of play involving large captures will effectively never terminate, even with superko rules in effect. I doubt it is possible to eliminate all these non-terminating lines of play in any way that is provably correct. .. So while claims of solution by exhaustive search might be very conv

[computer-go] Re: verifiable claims

> >You can just prove that you can make a large-enough chain that is >unconditionally alive. I believe that's what Erik did. In practice, >you cannot do an exhaustive search using superko rules because then >hash table scores cannot be used. I don't think you can always do that. For example, if

[computer-go] Re: verifiable claims

At 06:31 PM 5/22/2009, David Doshay wrote: >there are no chains of size 30 on a 5x5 board, I'll concede for a 5x5 board, but I think my point is valid for "sufficiently large" boards, probably 7x7. Almost any strategy other than playing out all legal moves involves a lot of hand waving that is u

[computer-go] Re: verifiable claims

I've written dozens of games with alpha-beta searches, so I think it's fair to say that I have a basic understanding of the process. Your description is correct but incomplete. Alpha beta is good at eliminating lines of play once a strong outcome is known somewhere in the tree, but much weaker be

[computer-go] Re:verifiable claims

> >And somehow I don't ever see comments anywhere suggesting that this could be a >problem. So what I'd like to know is: is this so trivial that no one ever >mentions it, or are the heuristics that programs use to terminate playouts so >obscure that they are too embarrasing to mention? Comple

[computer-go] Re:verifiable claims

> >And somehow I don't ever see comments anywhere suggesting that this could be a >problem. So what I'd like to know is: is this so trivial that no one ever >mentions it, or are the heuristics that programs use to terminate playouts so >obscure that they are too embarrasing to mention? Comple

[computer-go] Re: Problems with CGOS

> >So I believe this is a design flaw in CGOS itself. I wrote CGOS without >having had any experience writing servers. If there's a problem with larger databases, perhaps it can be fixed by adding the right indexes to the sql database. If you add a little time monitoring code around your q

[computer-go] Re: Cgos redesign

My $0.02 The choice of language is mostly arbitrary. CGOS is really two separate programs: (1) an I/O multiplexer that manages the clients connections and detailed communication, (2) a scheduler/planner/recorder that manages the overall operation of the site. I would definitely separate

[computer-go] Re: MCTS, 19x19, hitting a wall?

I think one approach to scaling playouts is to subdivide the board, stipulate the outcome in a fixed part, and do "norman" playout in the interesting part. The trick is to do a reasonable subdivision in the first place. Imagine an advanced UCT model that conceptually behaves like human evaluatio

[computer-go] Re: Dynamic komi in commercial programs

If you are in a lost position, "good play" is play that maximizes the probability of a turnaround, which is quite different depending on how far behind you are, and for what reason. If the status of all the major groups is solid, then concentrating on tactics which can gain a few points reliably

[computer-go] Re: self atari

It's easy to construct self-atari of unlimited size that both can occur and should be played, if the capturing move that follows the self-atari is then recaptured in a snapback. ___ computer-go mailing list computer-go@computer-go.org http://www.computer

[computer-go] Re: Rating variability on CGOS

In any rating scheme, who you play can be as important as how well. This is especially true for small groups. Suddenly adding or dropping a strong player will certainly cause all the other player's ratings to shift. ___ computer-go mailing list com

[computer-go] OT: AI article I found interesting

At 10:12 AM 10/24/2009, Joshua Shriver wrote: >Came across this today, and since this is also an AI oriented list thought >some of you might enjoy it too. > >http://www.techradar.com/news/world-of-tec

[computer-go] RE: other challenges

There's already a pretty satisfactory blokus server and a pretty active community of players, at blokus.com. If computer go people are looking for easier worlds to conquer (call it educational training for the real challenge) there is no shortage of candidate games. One that has an active commun

[computer-go] Re: MC thought

I wonder if MC programs shouldn't prune game branches when sufficiently large captures occur. The loss/win might not be strictly allocated to the right player, but it certainly means that the current game has entered sillyspace. ___ computer-go mailing

[computer-go] Re: MC thought

At 11:10 AM 1/15/2007, Magnus Persson wrote: >Quoting Dave Dyer <[EMAIL PROTECTED]>: > >>I wonder if MC programs shouldn't prune game branches when >>sufficiently large captures occur. The loss/win might not >>be strictly allocated to the right player, but it

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

Here's an idea for scaling up, which should result in "only" factor of 10 slower speed. To scale from 9x9 to 19x19, subdivide the board into four, overlapping 10x10 boards. Run a standard 9x9 monte carlo up to the 90% full stage on each of the four boards, then run a full board monte on the wh

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

At 02:59 PM 1/30/2007, [EMAIL PROTECTED] wrote: > I'm having difficulty picturing this, so I'll start with the most basic > questions. > >Do you mean Monte Carlo by itself or Monte Carlo combined with tree search >(e.g. UCT)? > The idea isn't more than lightly toasted (less than half baked),

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

> >Of course, everything depends on how you can deal with the boarders - how >about some monte-carlo-simulations over the possible boarder-configurations? My thought is that one thing you could easily get from the rollouts is a good estimate of the status of each string of stones currently on th

[computer-go] Re: documentation for the IGS protocol ?

The NNGS clone on boardspace.net is still running, but completely idle. It would be a suitable place to test clients. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/

[computer-go] Re: LISP question (littlle bit off topic)

> >I don't know, but from the description "list of atoms," perhaps >numbers were represented as linked lists of bits (using the facilities >built in to support linked lists of anything). I don't believe that any non-toy version of lisp ever used anything as ineffecient as representing numbers as

[computer-go] Re: Pondering

My theory on pondering is that it's not very productive to use it to just jump start the next global search. In my conceptual model for a playing program, there are a lot of "facts" that in fact are nothing of the kind - they're assertions that you are willing to assume are true. I'm thinking of

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

I suggest that it would be more convenient for everyone if various sizes of cgos all ran on the same server. If you want to donate horsepower to the project, a good use of the resource would be to run "anchorman" type clients. ___ computer-go mailing l

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

I figured that a credible anchor player for 19x19 might need a lot of cycles, and need to play a lot of games at first, so spreading the load would be a good idea. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailm

[computer-go] Re: Java hounds salivate over this:

> >So if there was any language which allows a programmer to port their code to >be compileable and executable on a wide variety of systems it is C. > Java and C support two fundamentally different approaches to portability. The approach that C supports is "chaos: deal with it". Figure out

[computer-go] Re: deep platform emulation

At 02:48 PM 6/15/2007, terry mcintyre wrote: >Now that takes me back to days of your. Can we run TECO on a PDP-10 emulator? >Early >versions of EMACS were actually written on top of TECO -- how's that for >layers upon layers >of emulation? The emulator runs the PDP10 processor, and emulators f

[computer-go] Re: Java hounds salivate over this:

At 03:12 PM 6/15/2007, steve uurtamo wrote: >my last $0.02 on this -- let me know when you've written a kernel in java, and >tell me how fast your operating system (written entirely in java) runs. I could point out that lisp machines had no other language at the core. The entire operating syste

[computer-go] Java hounds salivate over this:

>i did this for an IDEA (encryption) routine once, and >was heartbroken to discover that it was less than a >10% increase in speed over the optimized C routine. Very similarly for an encoder for JBIG image format. I wrote some very straightforward C code with some macros to unroll the loops, and

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

One of my favorite observations about Go is that expert play tends to be "on the edge of catastrophy". By playing better moves on the average, you become more vulnerable to the occasional misstep. If a program is not very good, random better or worse moves do not have much effect. If the prog

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

One of my favorite observations about Go is that expert play tends to be "on the edge of catastrophy". By playing better moves on the average, you become more vulnerable to the occasional misstep. If a program is not very good, random better or worse moves do not have much effect. If the prog

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

I think your table tennis analogy is not really applicable. The rule changes in table tennis were presumably motivated by the need to fix a real problem, and really changed the game. On the other hand, all the rules arguments in Go are really only applicable to incredibly marginal, bordering on

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

I think your table tennis analogy is not really applicable. The rule changes in table tennis were presumably motivated by the need to fix a real problem, and really changed the game. On the other hand, all the rules arguments in Go are really only applicable to incredibly marginal, bordering on

[computer-go] U. of Alberta bots vs. the Poker pros

>The only thing a computer can to is to model opponent's behavior, which may >deviate from the best play. What did I miss? No, you didn't miss a thing. I look forward to meeting you at a poker table, preferably with high stakes. ___ computer-go maili

[computer-go] Re: repeat postings

> >How does this foul spamming programs? Does it prevent a spammer from >sending out a lot of email or just delay the receiving of it? It doesn't delay per se, it rejects the incoming mail with a "try again later" tag. The theory is that spambots which act as their own mailers will not retry.

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

I built a similar database of 3x3 patterns found in professional games. The results looked interesting, but I never found a way to use it in a way that really contributed to the evaluation. ___ computer-go mailing list computer-go@computer-go.org http:

[computer-go] Re: Former Deep Blue Research working on Go

Considering how monte carlo actually works, I think it's plausible to argue that it works best where the distance to endgame is small. For a 19x19 board, the playing speed may be only a factor of 4 worse, but the effective learning speed for an opening position might be exponentially worse. In o

[computer-go] Re: XML alternatives to SGF

XML per se is not an improvement - it's just another way of wrapping data in a parseable package. XML says nothing about the structure, content, and semantics of the data. SGF does all that, it's very Go-friendly, and there are already many tools that use it for Go. ___

[computer-go] Re: XML alternatives to SGF

XML per se is not an improvement - it's just another way of wrapping data in a parseable package. XML says nothing about the structure, content, and semantics of the data. SGF does all that, it's very Go-friendly, and there are already many tools that use it for Go. ___

[computer-go] Re: alternatives to SGF

> >However, I am in favor of changing the SGF format to allow coordinate encoding >using the "standard" coordinates system rather than the one created just for >SGF; i.e., "a1" vs "aa". I routinely use sgf for non-go games and completely ignore the standard set of tag names and contents. This

[computer-go] Re: alternatives to SGF

> >However, I am in favor of changing the SGF format to allow coordinate encoding >using the "standard" coordinates system rather than the one created just for >SGF; i.e., "a1" vs "aa". I routinely use sgf for non-go games and completely ignore the standard set of tag names and contents. This

[computer-go] Re: XML alternatives to SGF

At 04:03 PM 10/22/2007, Markus Enzenberger wrote: >On Mon October 22 2007 10:15, Don Dailey wrote: >> almost impossible to write XML manually without bugs. > >it also seems to be hard to write an SGF file without bugs. >I recently run a test on a collection of about 5000 SGF files >from various sou

[computer-go] Re: use for Monte Carlo on 19X19?

> >the idea is: identify at least one stone from every unconditionally >living and every unconditionally dead group on the board, and >report them as dead or alive. It can be done very fast, but the problem is that in a typical endgame board under Japanese rules, the number of unconditionally a

[computer-go] Re: use for Monte Carlo on 19X19?

> >the idea is: identify at least one stone from every unconditionally >living and every unconditionally dead group on the board, and >report them as dead or alive. It can be done very fast, but the problem is that in a typical endgame board under Japanese rules, the number of unconditionally a

[computer-go] Re: use for Monte Carlo on 19X19?

At 05:22 PM 11/6/2007, Ray Tayek wrote: >At 03:50 PM 11/6/2007, you wrote: >>... in a typical >>endgame board under Japanese rules, the number of unconditionally >>alive stones is zero. > >maybe for pro games. for amatuer 1-kyu to 10-kyu games, i suspect that after >about 1/2 of the moves in the e

[computer-go] Re: use for Monte Carlo on 19X19?

At 05:22 PM 11/6/2007, Ray Tayek wrote: >At 03:50 PM 11/6/2007, you wrote: >>... in a typical >>endgame board under Japanese rules, the number of unconditionally >>alive stones is zero. > >maybe for pro games. for amatuer 1-kyu to 10-kyu games, i suspect that after >about 1/2 of the moves in the e

[computer-go] Re: randomness

>Am I making *any* sense? If so, you may need some sort of psychiatric help, >or alternatively, you could do me the favor of explaining how to ask for what >I want or even how to actually get it. :) Most computer applications use uniform randomness, but it sounds like what you want is normall

[computer-go] Re: Language

>It appears that the question of GC is not dependent on the problem >(eg. computer-Go) but on the language you use. This really gets back to the core of the language question. The kind of language you choose depends in part on the kind of program you intend to write. If you're writing a monte c

[computer-go] Re: Language

>It appears that the question of GC is not dependent on the problem >(eg. computer-Go) but on the language you use. This really gets back to the core of the language question. The kind of language you choose depends in part on the kind of program you intend to write. If you're writing a monte c

  1   2   >