Re: [computer-go] April KGS Computer Go tournament
Reminder - it's tomorrow. In message [EMAIL PROTECTED], Nick Wedd [EMAIL PROTECTED] writes The March 2007 KGS computer Go tournament will be next Sunday, April 8th, in the Asian evening, European morning and American night, starting at 09:00 UCT and ending at about 13:00 UCT. It will use small boards (9x9 for the Formal division, 13x13 for the Open), Chinese rules with 7.5 points komi, and fast time limits (13 minutes for the Formal division, 28m for the Open). The Formal division will be an eight-round Swiss, the Open, a four-round Swiss. There are details at http://www.gokgs.com/tournInfo.jsp?id=280 for the Formal division, and at http://www.gokgs.com/tournInfo.jsp?id=281 for the Open. Registration is now open. To enter, please read and follow, as usual, the instructions at http://www.weddslist.com/kgs/how/index.html. The rules are given at http://www.weddslist.com/kgs/rules.html. -- Nick Wedd[EMAIL PROTECTED] ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Simplified MC eva luator ¿explained?
Jacques Basaldúa wrote: 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 better name for that.) defined as: (# of subpaths ending in win)/(# of total subpaths) Let's call it W. (This winning rate can be a simplified version of what Erik calls underlying ground-truths.) Assuming two simplifying hypotheses: 1. The playouts are uniformly random. 2. Both players have the same number of legal moves (or any unbalanced numbers compensate in the long term). The unknown probability p of wining a random playout is a function of W. The _observed_ proportion after n random experiments, p-hat is an _unbiased_ estimator of p whose confidence intervals are the intervals for a binomial proportion as stated earlier in this list. Abusing of language, we can call p and estimator of W. (It is not really an estimator because it cannot be computed directly.) Now, the most interesting part: p is a _biased_ estimator of W and it is biased towards 1/2 as long as the expected value of the noise is zero (= playouts are not biased). The higher the noise (or _the longer the playout_) the more biased it is. In short: 1. We measure p-hat which is an unbiased estimator of p with known error distribution. 2. p is a biased towards 1/2 estimator of W. Knowing the variance (or replacing it by an estimator measured from experiments), we can model the bias. Simplifying to understand why it is biased toward 1/2 add random noise distributed as N(0, e) to p. With small noise: p + N(0, 0.01) gives very similar results to p With big noise: p + N(0, 100) gives very similar results to 1/2 for any p in [0,1] This is a rather theoretical post of small practical use, but it helps explaining the effect of the longer playouts = higher variance = more biass towards 1/2. Jacques. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ I don't understand your post. bias = E(p_hat) - p = E(p+N) - p = E(p)+E(N) - p = p + 0 - p = 0 I'm thinking that maybe you're clipping p+N to [0,1]? Maybe my biggest confusion is how you're actually arriving at p+N in a meaningful way. A single MC playout corresponds to a bernouli trial with probability p. Even with many trials, the noise becomes binomial, and asymptotically approaches the normal distribution. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Simplified MC evaluator ¿explained?
On 4/7/07, Jacques Basaldúa [EMAIL PROTECTED] wrote: Assuming two simplifying hypotheses: 1. The playouts are uniformly random. 2. Both players have the same number of legal moves (or any unbalanced numbers compensate in the long term). I did not understand your post either. Is #2 the same as neither player passes until the end of the game? Or do you intend to assume that at any given level of the game tree, all nodes have the same number of children? The latter assumption seems to be much stronger than what you intend, since it would imply that p=W exactly. Plus, it is obviously (and dramatically) false under any normal go rules where two passes end the game. Weston ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] neural net variant
Has anyone written anything reasonably accessible re designing a neural net where the pulses themselves carry information (ie a 32-bit piece of bitmap, perhaps) and/or that information itself is used in determining whether a cell fires? Forrest Curo - This email was sent using AIS WebMail. http://www.americanis.net/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] The dominance of search (Suzie v. GnuGo)
I have this idea that perhaps a good evaluation function could replace the play-out portion of the UCT programs. The evaluation function would return a value between 0 and 1 and would be an estimate of the odds of winning. I have tried this with an older and much weaker version of Suzie. It played positionally better than the Alpha-Beta version, but the rate of very strange moves also increased. UCT greates a more unbalanced tree than Alpha-Beta and the programm has therefore even more chances to cheat. For the same reason extensions do not work so far in Suzie. But I tried not with 0-1 but used the full eval. Maybe I should give it a second try. But as I work now 45 hours/week on Computer-Tomography (which is also quite interesting) and comute each weekend between Germany and Austria its difficult to do. Chrilly ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] The dominance of search (Suzie v. GnuGo)
To take a normal evaluation function and convert it to a probability of winning function is probably difficult to do well. You might have to map some sort of curve where a few stones ahead represent a near win. A simple approximation: - call the evaluation function - if it is less than zero, consider it one monte carlo run where white wins.If it's greater than zero, consider it a monte carlo run where black wins. It's probably better to use the curve - but my sense of it is that you need to map scores fairly accurately to odds of winning - to truly simulate a monte carlo run. How did you do this before? I think almost any reasonable idea is worth 2 or 3 tries - the devil is in the details. - Don On Sat, 2007-04-07 at 19:52 +0200, Chrilly wrote: I have this idea that perhaps a good evaluation function could replace the play-out portion of the UCT programs. The evaluation function would return a value between 0 and 1 and would be an estimate of the odds of winning. I have tried this with an older and much weaker version of Suzie. It played positionally better than the Alpha-Beta version, but the rate of very strange moves also increased. UCT greates a more unbalanced tree than Alpha-Beta and the programm has therefore even more chances to cheat. For the same reason extensions do not work so far in Suzie. But I tried not with 0-1 but used the full eval. Maybe I should give it a second try. But as I work now 45 hours/week on Computer-Tomography (which is also quite interesting) and comute each weekend between Germany and Austria its difficult to do. Chrilly ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] MoGo
Personally, I could care less - I guess because I am a chess player and I think it's weaker players who are impressed most by big wins. Very strong chess players tend to take the long way around - taking the sure win to the dramatic flashy quick but risky win. Weaker chess players tend to judge the skill of the player based on how many moves it takes to win a game but strong players know this is more a matter of playing style - not skill. It actually surpises me that go players care about this. I thought GO was more about the beauty of ommision and the unstated understanding of event that don't actually have to happen to be appreciated. - Don It depends on what your purpose is in playing the game in the first place. If you're simply aiming to create a program that is able to win against strong players, then it makes sense to simply play the move that it thinks is going to give it the greatest probability of a win. This makes sense for those developing cutting edge go playing programs and trying to achieve the highest rank possible. What I want from a commercial go playing program is one that I can use to learn to be a better go player. This brings up two important deficiencies in the win by 0.5 strategy. If I'm always loosing by half a point, It's difficult for me to see when I'm playing well and when I'm playing poorly. If the computer doesn't exploit my weaknesses because it knows that it will win anyway, then I won't learn to defend properly. I'll never know if I almost won or if the computer was just toying with me the whole way. The feedback from the computer just killed everything can help me play better. Secondly, we learn by emulating better players (though some may disparage blind emulation, it's easier to learn why a certain play is good if you're using it in your own games.) If the computer gets comfortably ahead then plays strange moves, it's difficult for me to learn normal proper endgame moves by watching the computer play. Maybe it will be better when a commercial version of MoGo is available and I can turn the difficulty settings way down so that I have a chance to actually win a game or two. Are there any plans for a commercial version of MoGo? - Ask a question on any topic and get answers from real people. Go to Yahoo! Answers. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] The dominance of search (Suzie v. GnuGo)
I don't understand your question. I don't claim non-determinism helps with alpha beta and I'm not recommending a fuzzy evaluation function, I'm just saying it still works. A deeper search will produce better moves in general. One has the randomness anyway. A heuristic evalution can be considered as the sum of a systematic term which is an estimator of the true evaluation and an error term (and a bias). One consequence of this model is, that the shape of the search tree has a significant influence on the evaluation. The programm will favour variations where it has a lot of good moves and the opponent has only a few. Because the more (good) moves the program has, the higher is the expected value of the error terms. The programm has more tickets in the error-term lottery. I have noticed this effect constantly. E.g. if one extends captures, the programm tends to favour lines with captures, if one extends checks stronger, the program likes to check... Chrilly ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] The dominance of search (Suzie v. GnuGo)
There is a chapter in Ulf Lorenz Dissertation about this topic. Ulf mentions this aspect also in the Hydra papers. E.g. the one for the XCell Journal. Search on the net for Lorenz, Donninger, Hydra and format pdf. But in this papers the concept is only mentioned without a detailed proof/explanation. This is only done in the Diss. The title of the Diss. is: Ulf Lorenz: Controlled Conspiracy Number Search, Paderborn 2000. But the work is in German. After the match Adams-Hydra Ulf wrote a longer article about his error-filter theory for the ICGA-journal. But the article was rejected. Ulf has used this model for a project to improve the robustness of airplane-schedules. The current algorithms just optimize the scheduling of airplanes (and the crew), but they have usually no notation of robustness. If there is a delay in London, then the flight Frankfurt Paris might be delayed too, because according the schedule the airplane is used after the return from London in Frankfurt for the Paris fligth. And this can in turn delay the flight from Paris to Madrid, because the crew has now - according the law - to take a rest in Paris, but the scheduling programm calculated that its optimal that they are also on board for Paris-Madrid and take the rest in Madrid One can consider the time according schedule as a noisy evaluation function and can try to find more robust solutions which is not much worse than the best solution. Its a conspiracy approach for scheduling problems. Chrilly - Original Message - From: Darren Cook [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Saturday, April 07, 2007 2:18 AM Subject: Re: [computer-go] The dominance of search (Suzie v. GnuGo) (R==1). An incorrect pruning decission is not taken forever. The general idea is to use information from the search tree to shape the search tree. Ulf Lorenz from the Univ. Paderborn considers the search tree as an adaptable error filter. ... UCT and Monte Carlo. It's not as much Monte Carlo any longer. Yes, ecaxtly. I also think that the difference is fuzzy. Both methods fit into the adaptable error filter model of Ulf. Hi Chrilly, Do you have a recommendation for a good paper to read on this? Ideally one that doesn't need specialized chess knowledge to appreciate, but I may not have a choice: google is giving me 0 hits on adaptable error filter. Darren -- Darren Cook http://dcook.org/mlsn/ (English-Japanese-German-Chinese free dictionary) http://dcook.org/work/ (About me and my work) http://dcook.org/work/charts/ (My flash charting demos) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] professional knowledge
At 06:17 AM 4/6/2007, you wrote: On Fri, 2007-04-06 at 13:48 +0100, Jacques Basaldúa wrote: 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. Doesn't that just imply the model is incorrect? If the model captures the true spirit of the game, it shouldn't matter. There may be some formal (but likely complex) way to describe a correct opening play strategy on any size board that is not board-size dependent. mr. yang uses the ideas of short and long extensions and high-low combinations in the beginning. (a short extension being 1 or spaces and a long being ideally 5 spaces). this tends to be eficient. I'll try to give an example: On small boards, it seems like it's correct to play to the center point on the first move? Why? The rule: always play to the center point might NOT be a board size independent strategy but might work well for boards smaller than say 11x11. But if you could capture the REASON for this, you might be able to formulate a better strategy for playing the first move that would work on all boards. playing in the center on a large board is reasonable. the trick is to make the stone useful. on a large board, this leads to an unusual style of play. black wins all ladders and has an advantage in all fights. many josekis are unfavorable for white. There are underlying reasons for everything and that is what must be captured to achieve a boardsize independent strategy. Of course I'm getting rather theoretical. I understand that you are looking for practical solutions and approximations. i suspect that the short/long and high/low heuristic would be useful during the fuseki stage. thanks --- vice-chair http://ocjug.org/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] LISP question (littlle bit off topic)
Up to my knowledge the first Lisp Versions had no number system. The number n was represented as the list of numbers from 1 to n (which is also the mathematical/axiomatic definition of the natural numbers). But its not very practical. Can anyone provide me with a link how this was done. I am speaking some computer languages, but Lisp is not among them. I want to present the code in an article for the Austrian AI-Journal (as an example that mathematical elegance and practically usefull are 2 different things). Chrilly ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] LISP question (littlle bit off topic)
I don't have a reference, but it's probably a variant of Church Numerals: http://en.wikipedia.org/wiki/Church_numeral On Apr 7, 2007, at 12:54 PM, Chrilly wrote: Up to my knowledge the first Lisp Versions had no number system. The number n was represented as the list of numbers from 1 to n (which is also the mathematical/axiomatic definition of the natural numbers). But its not very practical. Can anyone provide me with a link how this was done. I am speaking some computer languages, but Lisp is not among them. I want to present the code in an article for the Austrian AI- Journal (as an example that mathematical elegance and practically usefull are 2 different things). Chrilly ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] LISP question (littlle bit off topic)
On Sat, 2007-04-07 at 21:54 +0200, Chrilly wrote: Up to my knowledge the first Lisp Versions had no number system. The number n was represented as the list of numbers from 1 to n (which is also the mathematical/axiomatic definition of the natural numbers). But its not very practical. Can anyone provide me with a link how this was done. I am speaking some computer languages, but Lisp is not among them. I want to present the code in an article for the Austrian AI-Journal (as an example that mathematical elegance and practically usefull are 2 different things). There are also elegant (and minimal) computer languages that are turing complete, but nobody want to program with them - they are not practical. - Don Chrilly ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Ang: [computer-go] LISP question (littlle bit off topic)
You are looking for a formalization of natural numbers. The one you describe is probably a mangled description of the construction from set theory. AFAIK The natural Lisp construction is from the Peano axioms. A shallow discourse: http://en.wikipedia.org/wiki/Natural_number#Formal_definitions MvH Dan Andersson ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] professional knowledge
mr. yang uses the ideas of short and long extensions and high-low combinations in the beginning. (a short extension being 1 or spaces and a long being ideally 5 spaces). this tends to be eficient. There is the classic Chinese rule of thumb on how far one can comfortably extend along an edge: 2 spaces from one stone, 3 from a perpendicular pair of stones, etc--But then a high-rank professional published an English book some years back where one chapter dealt with what the optimal extension from one stone would be in practice. It turned out highly situation-dependent, from one to five spaces, with the 2 space rule applying only in isolation from other considerations. And probably this too is board size dependent: How much is there potentially to gain by abandoning the connection and running with one side of the position? Forrest - This email was sent using AIS WebMail. http://www.americanis.net/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [spam probable] [computer-go] MoGo
I can turn the difficulty settings way down so that I have a chance to actually win a game or two. You can always decrease the time per move and at some limit, you'll reach random play. Even if I can't win against MoGo with 300 playouts per move (I am so bad :-( ), but can I beat a random player? :-) Are there any plans for a commercial version of MoGo? No, at least in near future. Sylvain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] From Surreal Numbers to Games
fyi:
http://scienceblogs.com/goodmath/2007/04/post_3.php
Today we're going to take our first baby-step into the land of surreal games.
A surreal number is a pair of sets {L|R} where
every value in L is less than every value in R.
If we follow the rules of surreal construction,
so that the members of L sets are always strictly
less than members of R sets, we end up with a
totally ordered field (almost) - it gives us
something essentially equivalent to a superset of
the real numbers. (The reason for the almost is
that technically, the surreals form a class not a
set, and a field must be based on a set. But for
our purposes, we can treat them as a field without much trouble.)
But what happens if we take away the restriction
about the relationship between the L and R
sets? What we get is a set of things called
games. A game is a pair of sets L and R, where
each member of L and R is also a game. It should
be obvious that every surreal number is also a
game - but there are many more games than there
are surreal numbers, and most games are not surreal numbers.
Games lose some of the nice properties of the
surreal numbers. They are not a field. They are
not totally ordered. In fact, they're not even
all positive or negative. They're very strange things.
So why would we want to break the restriction on
the surreals that gives us games? Naturally,
because games have useful applications in
modeling many things - in particular, games (in
the non-mathematical sense - games like Go, Chess, Checkers, Poker, etc).
Let's take a bit more of a detailed look at games, and how they interact.
Game arithmetic is exactly the same as surreal
arithmetic: addition, subtraction,
multiplication, negation - even division (which
we haven't looked at yet) are all defined in the
same way of surreal numbers and games.
But: while surreal numbers are always either
positive, negative, or zero, games can also be
fuzzy. Remember, games are not fully ordered.
That means that there are pairs of games (a,b)
where ¬a b and ¬b a - that is, where the two
games cannot meaningfully be compared. Fuzzy
games are games that can't be compared to zero.
What does a fuzzy game look like? The simplest
example is: {1|-1}. Try to use the definition of
on that game with zero - it doesn't work.
Games also have some strange behaviors with
respect to multiplication. If a, b, and c are
games, then (as you would expect for numbers), if
x×z=y×z then x=y. But, with games, x=y doesn't
mean that x×z=y×z. Nasty, that, eh?
So what are these beasts useful for? Part of
Conway's motivation was trying to analyze the
game of Go (aka Wei-Chi). Go is one of the oldest
strategic games in the world; it's been played
for thousands of years in China, Japan, and
Korea. Go is the Japanese name, which is
generally used here in the US; Wei-Chi is the
chinese name for it. It's a thoroughly fascinating game.
Go is a two-player game where the players have a
17x17 grid. Each move, a player puts a piece of
their own color on one of the intersections on
the grid. The goal of the game is to surround
territory using your pieces. Whoever has the most
territory at the end wins. Mechanically, it's
about as simple as a game can get. Strategically,
it's unbelievably deep and complex. It's
frequently compared to Chess in terms of depth
and strategy. It's a wonderful game. ...
---
vice-chair http://ocjug.org/
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] MoGo
On Sat, 2007-04-07 at 14:36 -0400, Matt Kingston wrote: What I want from a commercial go playing program is one that I can use to learn to be a better go player. This brings up two important deficiencies in the win by 0.5 strategy. If I'm always loosing by half a point, It's difficult for me to see when I'm playing well and when I'm playing poorly. If the computer doesn't exploit my weaknesses because it knows that it will win anyway, then I won't learn to defend properly. I'll never know if I almost won or if the computer was just toying with me the whole way. The feedback from the computer just killed everything can help me play better. Hi Matt, I have heard this argument before, but I personally do not subscribe to it. Please let me explain why. Of what learning purpose is it if you are losing the game and the computer gets you to focus on a dramatic battle somewhere that is totally irelevant? What are you being taught? I think you would develop the wrong sense of the game. Instead of thinking and planning for a win, you would be thinking and planning for local battles - and as UCT and MC have shown us, this is the WRONG way to think about the game. In fact this is how beginners think about the game. It doesn't seem to me like a good learning aid to try to get the computers to emulate the losing strategy weaker players use. I don't think this is a theoretical discussion either, because when I'm testing and watching Lazarus play I learn already from watching this masterful strategy. In fact, I've come to prefer this style. It somehow makes the program seem more mature - less like a child. A mature adult does not find pleasure in the foolish things a child might - but instead gradually learns what is important. And go really is all about that - knowing what is really important and what is not and I would rather learn from a player who demonstrates that to me. - Don ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] The physics of Go playing strength.
A few weeks ago I announced that I was doing a long term scalability study with computer go on 9x9 boards. I have constructed a graph of the results so far: http://greencheeks.homelinux.org:8015/~drd/public/study.jpg Although I am still collecting data, I feel that I have enough samples to report some results - although I will continue to collect samples for a while. This study is designed to measure the improvement in strength that can be expected with each doubling of computer resources. I'm actually testing 2 programs - both of them UCT style go programs, but one of those programs does uniformly random play-outs and the other much stronger one is similar to Mogo, as documented in one of their papers. Dave Hillis coined the terminolgoy I will be using, light play-outs vs heavy play-outs. For the study I'm using 12 versions of each program. The weakest version starts with 1024 play-outs in order to produce a move. The next version doubles this to 2048 play-outs, and so on until the 12th version which does 2 million (2,097,152) playouts. This is a substantial study which has taken weeks so far to get to this point. Many of the faster programs have played close to 250 games, but the highest levels have only played about 80 games so far. The scheduling algorithm is very similar to the one used by CGOS. An attempt is made not to waste a lot of time playing seriously mis-matched opponents. The games were rated and the results graphed. You can see the result of the graph here (which I also included near the top of this message): http://greencheeks.homelinux.org:8015/~drd/public/study.jpg The x-axis is the number of doublings starting with 1024 play-outs and the y-axis is the ELO rating. The public domain program GnuGo version 3.7.9 was assigned the rating 2000 as a reference point. On CGOS, this program has acheived 1801, so in CGOS terms all the ratings are about 200 points optimistic. Feel free to interpret the data any way you please, but here are my own observations: 1. Scalability is almost linear with each doubling. 2. But there appears to be a very gradual fall-off with time - which is what one would expect (ELO improvements cannot be infinite so they must be approaching some limit.) 3. The heavy-playout version scales at least as well, if not better, than the light play-out version. (You can see the rating gap between them gradually increase with the number of play-outs.) 4. The curve is still steep at 2 million play-outs, this is convincing empirical evidence that there are a few hundred ELO points worth of improvement possible beyond this. 5. GnuGo 3.7.9 is not competive with the higher levels of Lazarus. However, what the study doesn't show is that Lazarus needs 2X more thinking time to play equal to GnuGo 3.7.9. This graph explains why I feel that absolute playing strength is a poor conceptual model of how humans or computers play go. If Lazarus was running on the old Z-80 processors of a few decades ago, it would be veiewed as an incredibly weak program, but running on a supercomputer it's a very strong program. But in either case it's the SAME program. The difference is NOT the amount of work each system is capable of, it's just that one takes longer to accomplish a given amount of work. It's much like the relationships between power, work, force, time etc. in physics. Based on this type of analysis and the physics analogy, GnuGo 3.7.9 is a stronger program than Lazarus (even at 9x9 go). Lazarus requires about 2X more time to equalize. So Lazarus plays with less force (if you use the physics analogy) and needs more TIME to get the same amount of work done. ELO is treated numerically as if it were work in physics because when it's measured by playing games, both players get the same amount of time. The time factor cancels out but it cause us to ignore that it's part of the equation. On CGOS, Lazarus and FatMan are the same program, but one does much more work and they have ELO ratings that differ by almost 300 ELO points. Even though they are the same program you will look on CGOS and believe Lazarus is much stronger because you have not considered the physics of Go playing strength. - Don ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
