I have a filter that tags messages from this list as "computer-go". That
prevents the messages from going to Spam. I actually get a yellow banner at
the top of the message that says "This message was not sent to Spam because
of a filter you created."
On Wed, Dec 3, 2014 at 6:12 PM, Erik van der
If you google for "computer go" and "beta distribution" you'll find several
relevant links, like this one:
https://webdisk.lclark.edu/drake/publications/BetaDistribution.pdf
On Thu, Sep 25, 2014 at 7:06 PM, Álvaro Begué
wrote:
> I believe this has been discussed in
I believe this has been discussed in the mailing list before: If your prior
distribution of the win rate of a move is uniform, after L losses and W
wins the posterior distribution will be a beta distribution with alpha=W+1
and beta=L+1. The expected value of this distribution is alpha/(alpha+beta)
Can you give us an idea of what types of games you are talking about? From
that email I can't tell if you are looking at Connect Four, Texas Hold'em,
Diplomacy, Puerto Rico or Imperium Romanum II. I am sure the your
observations don't apply to all those games.
Álvaro.
On Sat, Aug 30, 2014 at 4
"[Talking about how IBM tries to anthropomorphize Deep Blue and Watson to
capture the public's imagination.] Caught between atheism and a crippling
fear of death, Ray Kurzweil and other futurists feed this
mischaracterization by trumpeting the impending technological apotheosis of
humanity, their b
I believe you *have to* check for simple ko in playouts. Otherwise you'll
end up with infinite playouts quite easily.
On Wed, May 7, 2014 at 9:09 AM, Ben Ellis wrote:
> All,
>
> When playing random playouts, do you (anyone) bother checking for KO
> or super KO? Does this have a negative
I have a filter set up that labels all emails from this list as "computer
go", and I often see message from GMail explaining that that is the reason
it didn't classify it as spam. Give that a try.
Álvaro.
On Thursday, October 10, 2013, Petri Pitkanen wrote:
> Thats why Gmail has filters and you
The word "open" doesn't appear in the page you linked to. What does it mean?
On Wed, Jun 12, 2013 at 4:06 PM, Oleg Barmin wrote:
> Sure. It's open chinese poker:
> http://www.pokerlistings.com/poker-rules-chinese-poker
>
>
> Среда, 12 июня 2013, 20:57 +01:00 от Nick Wedd :
>
> On 12/06/2013 2
Can you point us to a description of the game? It would be easier to have
an intelligent discussion about the game if we knew the rules...
On Wed, Jun 12, 2013 at 3:33 PM, Oleg Barmin wrote:
> > For quality assessment, play many games against one or more reference
> opponents.
> It's difficul
Running `python -u' is another workaround.
On Mon, Apr 8, 2013 at 2:13 PM, Matthew Woodcraft
wrote:
> Sebastian Scheib wrote:
> > I am trying to send commands using GTP protocol in Python, but is not
> > working.
> >
> > In Java I used for example for Name:
> >
> > System.out.println("= Evil Te
Sorry, s/endlines/newlines/
Also, have you tried to run the program on the command line and pretend to
be the GUI?
On Mon, Apr 8, 2013 at 1:51 PM, Álvaro Begué wrote:
> The number of endlines shouldn't matter. GTP specifies that empty lines
> should be ignored both by the engine
The number of endlines shouldn't matter. GTP specifies that empty lines
should be ignored both by the engine and the GUI.
On Mon, Apr 8, 2013 at 1:50 PM, Sebastian Scheib
wrote:
> Well, it worked in Java, why not in Python. Is some old code I am
> "translating" to Python.
>
>
> 2013/4/8 John Tr
It's been a while for me too. What I remember is that one can equivalently
use scores that are the log of the gammas, and then the whole thing looks
just like a natural generalization of logistic regression, where you
basically have a bunch of features that you combine linearly, and then the
probab
difficult task in Go. How does he do this
> judge ? Which features does he analyze? And there are cases which "try" to
> mimic the biological solution is worth. See Neural Networks, Ant Colony
> Optimization Algorithm, Genetic Algorithm, etc.
>
> Santos, Gabriel.
>
>
>
On Mon, Apr 1, 2013 at 11:10 AM, Gabriel .Santos
wrote:
> I know that it is a lot of questions, but in order to get a computer go
> machine to outperform a human player I think that the machine should to
> ratiocinate like a human player.
Do you also think a machine that carries people very fas
On Mon, Jan 7, 2013 at 9:38 AM, David Ongaro wrote:
> Go really isn't "traditionally" played on 9x9 and 13x13. They where
> introduced in recent times to make teaching easier. The traditional board
> sizes are 17x17 and 19x19. The reason for odd sizes is simple: even sizes
> lag a tengen which is
There are many tests of normality that might be well suited. The
Kolmogorov-Smirnov test (
http://en.wikipedia.org/wiki/Kolmogorov%E2%80%93Smirnov_test) for instance
should be easy to compute in terms of the function erf().
On Mon, Dec 10, 2012 at 7:07 PM, Darren Cook wrote:
> > How much [eff
If you use bitboards, you can generate all the moves without making an
explicit list of them: You simply have four 64-bit numbers that
indicate the pieces that can be moved in each direction. Population
count is very fast, so you can figure out how many moves you have,
then you pick a random index
On Thu, Aug 9, 2012 at 7:24 AM, Don Dailey wrote:
> If you look at actors and actresses they are able to master accents.
> Often some actor will play some role and you will believe they are native
> speaking U.S. Citizens. But then you see them interviewed only to find out
> they have a heavy fo
On Wed, Aug 8, 2012 at 8:12 AM, Darren Cook wrote:
> Something I suspect a lot of people on this list might have tried is
> learning Japanese kanji. I meet a lot of Japanese learners (even as
> young as in their early twenties) who throw their hands up and say they
> are too old to learn kanji. Th
On Tue, Aug 7, 2012 at 10:18 PM, Darren Cook wrote:
>> An interesting line from this article on pattern matching, including
>> computer Go:
>> ...
>> http://news.csu.edu.au//director/latestnews.cfm?itemID=C712563AEEA8398B7655D520C442F510&printtemplate=release
>
> A nice article; curiously the issu
> for is something that is a more logical means to an ends - and the cap is
> not nearly as good as the log or the square root.
>
> Don
>
>
>
> On Thu, Jul 12, 2012 at 9:25 AM, Álvaro Begué
> wrote:
>>
>> The square root is just as arbitrary as capping at 50. T
The square root is just as arbitrary as capping at 50. The only
function I really like is capping at 0.5.
Álvaro.
On Thu, Jul 12, 2012 at 9:16 AM, Don Dailey wrote:
> Truncating to [-50 .. 50] seems rather arbitrary to me too.There should
> either be no truncation at all, or if the concep
So there was an unreasonable security feature in the software, some of us
complained and now it's gone. How beautifully civilized! I will buy a copy
right now.
Álvaro.
On Wed, May 30, 2012 at 2:04 PM, "Ingo Althöfer" <3-hirn-ver...@gmx.de>wrote:
> Hello everybody,
>
> good news on commercial Cr
On Mon, May 21, 2012 at 10:49 AM, terry mcintyre
wrote:
> "Every time you start Crazy Stone 2012, your PC must be connected
> to the internet for activation by serial number,"
>
> This is a very annoying "feature." Perhaps the authors have not considered
> the existence of mobile laptops, which ar
On Thu, May 10, 2012 at 1:51 PM, folkert wrote:
> Yes indeed.
>
> It has been a couple of years since I worked on stop so I've got a fresh
> look at it.
> Some code is really interesting.
>
> It seems there's already some code in it doing this check.
>
> Not entirely sure if it is correct:
> - if
On Thu, May 10, 2012 at 1:32 PM, folkert wrote:
> What I mean is: say you've got a piece of board with a circle of stones
> on it. Now what I've read is that one should not place stones in such a
> circle. So the question is: how do you guys detect this?
> Also see my question on
> http://stackove
What do you mean by "cross"?
On Thu, May 10, 2012 at 12:11 PM, folkert wrote:
> Hi,
>
> How do you detect that a cross is inside an eye? (eye? - circle,
> connected chain of pieces is what i mean)
>
>
> Folkert van Heusden
>
> --
> Multitail es una herramienta flexible que permite visualizar los
I could have saved some money possibly by ordering online. However I'd
> also have to pay shipping costs on each item and wait.
> Don't mind spending a little more to save time and support a local business.
>
> -Josh
>
>
> On Mon, Apr 23, 2012 at 2:28 PM, Álvaro Begué
&
I just checked newegg.com for similar components, and the price I got
was $464.95. For another $110 or so you can add a 1TB HD.
Álvaro.
On Mon, Apr 23, 2012 at 2:08 PM, Joshua Shriver wrote:
> Bought the pieces from a local mom-pop shop that has great pricing.
>
> AMD Phenom II x6 core 179
> A
I think the solution is the introduction of some flavor of minimax
into the tree search. For instance, once a node has been visited more
than a certain number of times, the score that we'll back out from it
is just the score of the best child, instead of an average that might
be polluted by bad mov
On Wed, Dec 14, 2011 at 4:35 PM, Robert Jasiek wrote:
> For infinite ko rules, all games "ending in" the same cycle can be put into
> the same equivalent class. Thereby one gets a finite number of different
> classes of games (i.e. symbolic move-sequences).
This doesn't seem right. Why should an
On Wed, Dec 14, 2011 at 2:37 PM, Michael Williams
wrote:
> Without the 50-move rule, a single game can be arbitrarily long, right? And
> so the game space is infinite.
No: The number of positions is finite, so three-time repetition will
make games finite.
Semi-obvious theorem: If all games are
done smarter and
>> thus counting liberties would require less iterations, but I have no
>> idea how to do that. (Hmm... perhaps there is one idea that I might
>> try.)
>>
>> That time tagging sound's good idea. The length of playouts is perhaps
>> in averag
I can't possibly imagine what the CPU is doing for a whole second in a
single playout. PHP is slow, but not *that* slow. I bet you can get
around 1000 "light" playouts per second even in PHP. Perhaps you can
add some timers to your code and see where the time is going.
How long are your playouts?
On Mon, Oct 24, 2011 at 1:45 PM, Dave Dyer wrote:
>
> I've been working with UCT search for other games than Go, and one
> interesting thing I"ve learned is that the results can change dramatically
> depending on how the UCT values are manipulated as the tree grows.
>
> Consider the root node; a
I haven't used it myself, but perhaps this would do?
http://www.lifein19x19.com/forum/viewtopic.php?f=49&t=1651
On Mon, Sep 19, 2011 at 5:35 PM, Peter Drake wrote:
> The KGS android app does a wonderful job if I want to play an entire game in
> one sitting. Is there one that allows play at a slow
Ingo is right. But I interpret "weakly solved" the same way Erik does:
Not only do you have to provide a program that always obtains the best
result in practice, but you need to be able to prove that this is
always the case.
On Wed, Jul 13, 2011 at 11:29 AM, "Ingo Althöfer" <3-hirn-ver...@gmx.de>
On Tue, Jul 12, 2011 at 10:05 PM, Aja wrote:
> For Zen and CrazyStone, they might not be interested on 9x9, because 19x19
> is their arena. Mogo is maybe the best candidate. In the TAAI
> conference last year in Taiwan, Olivier stated that Mogo will solve (or
> weakly solve?) 9x9 by winning 4 out
On Tue, Jul 5, 2011 at 1:48 AM, Leon Matoh wrote:
>
> I know that MCTS winrate does not give any usufull information about quality
> of the move except winning chance
>
> I said that normalized winrates with random komi window give much more
> information.
>
> So to show the concept I played two g
On Sun, Jul 3, 2011 at 10:14 PM, terry mcintyre wrote:
> From: Jean-loup Gailly
> To: computer-go@dvandva.org
> Sent: Sun, July 3, 2011 9:12:59 AM
> Subject: Re: [Computer-go] MCTS and perfect endgame
>
> Leon,
>> One of problems (which I tested with gogui, thankyou very much)
>> was losing point
On Sun, Jul 3, 2011 at 8:36 AM, Leon Matoh wrote:
> [...]
> One of problems (which I tested with gogui, thankyou very much)
> was losing points in endgame when program is winning.
Are you talking about positions where the program losses a won game by
not playing the endgame correctly, or situatio
On Fri, Jun 24, 2011 at 8:27 AM, Don Dailey wrote:
>
> On Fri, Jun 24, 2011 at 1:40 AM, Darren Cook wrote:
>>
>> On 2011-06-21 02:53, Álvaro Begué wrote:
>> > I think when you have explored a node enough times, there is no point
>> > in considering the score
On Mon, Jun 20, 2011 at 6:00 PM, Nick Wedd wrote:
> On 20/06/2011 21:03, Richard B Segal wrote:
>>
>> Hi All,
>>
>> As my scalability paper has come up several times in the last few weeks
>> I thought it would be useful to give a brief overview of the results
>> relevant to the current conversatio
I don't have any quantitative data to show, but at some point I tried
to see what dimwit would do if I let it think for an hour on an
early-game 9x9 position. The result was that the search was
ridiculously narrow, with exceedingly long lines whose moves weren't
particularly good, and it would just
Don, I assume you mean "with high handicap games...". The problem is
that dynamic komi assumes there will be points to be gained later in
the game, and the program might be happy to get into a situation where
the opponent has a lot of safe territory, and then there are no
opportunities to recover f
> A commandline GTP interface is my otherwishlist item, but I do realize
that one is just wishful thinking in a commercial product :-)
Why? There are commercial chess programs that are sold as a UCI engine
(e.g., Rybka). I would buy a GTP-speaking Linux go engine.
Alvaro.
On May 30, 2011 7:18 PM,
You can set up a filter to detect computer-go messages and assign it
the action "Never send it to Spam".
Álvaro.
On Thu, May 26, 2011 at 10:40 PM, Peter Drake wrote:
> Is there a workaround for gmail?
>
> Peter Drake
> http://www.lclark.edu/~drake/
>
>
>
> On May 26, 2011, at 6:52 PM, Michael W
We had some moderate success with a dynamic playout policy in dimwit.
We had a real number associated with each (side, point, 3x3 pattern).
At the end of a playout we looked at the difference between the score
and the sum of these numbers, and we changed the numbers slightly to
try to make the diff
sum_{i=1}^j p_i) in an array, and then to do a binary search for R.
> This
> can be done in two phases (row and then column) if you're considering all the
> moves on the board, but then you're searching through 19 values each time, so
> the linear
> search suggested below
John Tromp and I initially implemented this using a binary tree
(efficiently implemented in an array, the way heaps are often
implemented), but then someone (I believe it was Rémi) gave us a more
efficient method, which is keeping track of the sum of probabilities
for each row. You can then roll a
e
>> the analysis a bit more complex. Rinse and repeat.
>>
>> Terry McIntyre
>>
>> Unix/Linux Systems Administration
>> Taking time to do it right saves having to do it twice.
>>
>>
>> From: Don Dailey
>>
Hi,
I haven't spent any time in go programming recently, but a few months
ago I thought of a method to evaluate proposed improvements that might
be much better than playing a gazillion games. A search results in two
things: A move and a probability of winning (or a score that can be
mapped into a
On Thu, Jan 27, 2011 at 4:12 PM, Don Dailey wrote:
>
>
> On Thu, Jan 27, 2011 at 9:31 AM, Jonathan Chetwynd
> wrote:
>>
>> Could a 'doubling dice'** encourage early resignation by programs?
>>
>> each program would have to forfeit a double game, if it played on and lost
>> the game,
>> but could
On Mon, Jan 3, 2011 at 1:47 PM, Joona Kiiski wrote:
> Question 1: How does one playout go? Are you using completely
> random moves or something smarter?
The typical names are "light" (almost totally random, fast to
generate) and "heavy" (smarter and slower) playouts. Currently all
strong programs
On Sat, Jan 1, 2011 at 10:01 AM, Robert Jasiek wrote:
> On 01.01.2011 15:08, Álvaro Begué wrote:
>> If you don't trust John's numbers
>
> It is not about trust but about taking time for understanding his proofs.
But you certainly can take the time to writ
The people that think the number is low or high have bad intuitions,
that's all. Writing a program that generates random configurations and
checks whether they are valid is fairly trivial. If you don't trust
John's numbers, that's what you can do.
Alvaro.
On Saturday, January 1, 2011, Kahn Jonas
If you don't implement virtual loss, all threads will follow the same
path in the UCT part of the playout, which is a huge departure from
what the sequential algorithm would have done. Adding one loss
temporarily when a thread picks the move discourages other threads
from picking it, but it can be
On Sat, Oct 30, 2010 at 6:56 PM, Jacques Basaldúa wrote:
> About the convergence proof to go:
>
> As far as I can understand Álvaro's proof sounds correct,
> but that possibly applies to most games, but not go as
> humans play it. Because what we play is "MCTS go" an almost
> identical game where
On Sat, Oct 30, 2010 at 6:58 PM, Willemien wrote:
> On Sat, Oct 30, 2010 at 11:24 PM, Álvaro Begué wrote:
>> On Sat, Oct 30, 2010 at 12:26 PM, Willemien wrote:
>>> On Sat, Oct 30, 2010 at 5:00 PM, Álvaro Begué
>>> wrote:
>>>> On Sat, Oct 30, 2010 at 11
On Sat, Oct 30, 2010 at 12:26 PM, Willemien wrote:
> On Sat, Oct 30, 2010 at 5:00 PM, Álvaro Begué wrote:
>> On Sat, Oct 30, 2010 at 11:35 AM, Willemien wrote:
>>> On life in 19x 19
>>> http://www.lifein19x19.com/forum/viewtopic.php?p=37588#p37588
>>>
>
On Sat, Oct 30, 2010 at 11:35 AM, Willemien wrote:
> On life in 19x 19
> http://www.lifein19x19.com/forum/viewtopic.php?p=37588#p37588
>
> i found the statement
> .
> " I think there exists a proof that MCTS gives the same results as
> normal minimax search when the number of playouts goes to inf
On Tue, Oct 26, 2010 at 11:34 AM, Don Dailey wrote:
>
> On Tue, Oct 26, 2010 at 11:07 AM, Álvaro Begué
> wrote:
>>
>> A few years ago I had a conversation with John Tromp about this
>> measure of depth, and he pointed out that "who has bigger feet" has as
>
A few years ago I had a conversation with John Tromp about this
measure of depth, and he pointed out that "who has bigger feet" has as
many levels as there are players, but doesn't make for a very
interesting game.
Álvaro.
On Tue, Oct 26, 2010 at 2:52 AM, Olivier Teytaud wrote:
> Dear all,
>
>
On Fri, Oct 22, 2010 at 9:10 AM, Don Dailey wrote:
>
>
> On Thu, Oct 21, 2010 at 11:22 PM, Michael Williams
> wrote:
>>
>> Don asked if he could fork() on iPhone. I Googled it, responded and
>> cited. But the cite might be refering to only to non-jailbroken
>> functionallity.
>
> Since the phon
On Wed, Oct 6, 2010 at 5:00 AM, Heikki Levanto wrote:
> On Tue, Oct 05, 2010 at 04:28:40PM -0400, Álvaro Begué wrote:
>>
>> The correct way to evaluate an action is the expected value (yet
>> another name for the mean) of the utility function (there is a theorem
>> by
The correct way to evaluate an action is the expected value (yet
another name for the mean) of the utility function (there is a theorem
by Von Neumannand Morgenstern about this
http://en.wikipedia.org/wiki/Von_Neumann%E2%80%93Morgenstern_utility_theorem
). Since we want to win the game, it makes se
On Tue, Sep 7, 2010 at 6:03 PM, Dave Dyer wrote:
>
>>I may agree, but otherwise I think you misunderstand completely
>>what people are doing to improve their programs.
>
> A program developed by playing against itself, or any fixed reference point,
> can get stronger against that opponent while ge
On Tue, Aug 24, 2010 at 12:56 PM, Brian Sheppard wrote:
>>I ran Many Faces for 90 seconds and it likes D3 for X with 75% win rate, 21
>
>>ply PV, 1.3M playouts.
>
>
>
>>Indeed. I ran Valkyria for 95 seconds. It used about 400k playouts
>
>>with a 31 ply PV but with an unusual amount of junk moves.
On Wed, Aug 11, 2010 at 12:22 PM, David Fotland wrote:
> Yes, that's why the option is there. By default, MF uses all cores. If
> someone wants long think times while they are using the computer for
> something else they can reduce the maximum threads allowed.
Couldn't one just lower the priori
On Tue, Aug 10, 2010 at 8:34 AM, Alain Baeckeroot
wrote:
> I know MC i used in physics.
> The indicators (winning probalitly and score) lack confidence interval
Well, in situations where MC is sampling from the same distribution
over and over again (as it probably was in whatever you did in
Physi
2010/6/27 Petr Baudis
> On Sun, Jun 27, 2010 at 12:23:08PM -0400, Álvaro Begué wrote:
> > Precision is a tricky issue to deal with when implementing this. John
> Tromp
> > and I resorted to using integers as probabilities to avoid precision
> > problems.
>
> Yes,
On Sun, Jun 27, 2010 at 9:26 AM, Petr Baudis wrote:
> On Sun, Jun 27, 2010 at 08:49:57PM +0900, Darren Cook wrote:
> > >> I guess moving to whole board patterns doesn't actually add much CPU,
> > >> because they are only 3x3: a list of matching patterns can be
> > >> maintained, and after each mo
0-0 is a tie, not losing. And the playout policies in Fuego and Mogo
are probabilistic, even if there are circumstances under which they
react deterministically. You seem a bit imprecise today. :)
To Q1., I believe there are programs where every move has a non-zero
probability of being picked (exc
On Wed, Jun 16, 2010 at 5:42 PM, April Hersey wrote:
> Hello,
>
> I'm a student working with Peter Drake on Orego, and I'm curious about what
> uses
> other fields of study might have for various aspects of computer Go research.
> For example, Peter has heard of applications in connecting mass tr
On Tue, Jun 15, 2010 at 4:02 PM, Petr Baudis wrote:
> On Sun, Jun 13, 2010 at 08:55:16PM -0500, Daniel Liu wrote:
>> This post is to propose a metric that measures the effectiveness of a
>> playout policy
>> in a MC tree search. It could give some idea as how the playing strength
>> varies with
>>
On Mon, Jun 14, 2010 at 5:40 PM, Richard Brown wrote:
> On Mon, Jun 14, 2010 at 3:59 PM, Mark Boon wrote:
>
>> But I'm not sure how the method you're describing is any different
>> from what old programs like Goliath used to do.
>
> There's a step in pattern recognition called "feature extraction
On Sun, Jun 13, 2010 at 5:31 PM, Mark Boon wrote:
> So far all numbers seem to confirm my initial statement that CPUs
> didn't get all that much faster during recent years. The focus is more
> on getting more cores working together faster.
>
> I think a lot could be gained if multi-threading could
On Wed, Jun 2, 2010 at 5:25 PM, Jeff Nowakowski wrote:
> On 06/02/2010 01:14 PM, Don Dailey wrote:
>>
>> Why are you comparing humans to computers? It's ridiculous to measure
>> progress by comparing to the top human players. What we care about is
>> how
>> much progress we can make from yea
On Wed, Jun 2, 2010 at 1:40 PM, Eric Baum wrote:
> Don Dailey wrote:
>>
>> There have been several amazing breakthroughs in computer chess over the
>> years, so you don't know what you are talking about. You don't really
>> believe we achieved several hundred ELO with only incremental refineme
On Thu, May 20, 2010 at 7:57 AM, Isaac Deutsch wrote:
> [...]
>
> All clear up to here. :) I guess the "P(raise | two_aces)" bit could be
> extracted from professional games, for example?
That would be a very good way to do it, yes. But this is part of how
you create the quick mapping from game s
On Fri, May 14, 2010 at 7:45 PM, Isaac Deutsch wrote:
>
>>> In Tichu, there seem to be bids ( Tichu and Grand Tichu ) which also reveal
>>> something about the bidder's hands.
>
> Yes, from these bids you are able to tell that a player's hand is good. I can
> see it being helpful to give these p
On Fri, May 14, 2010 at 10:33 PM, Álvaro Begué wrote:
> Notice that P(raise) = Sum_over_all_possible_hands ( P(raise | hand) ).
Ooops! I meant to say
P(raise) = Sum_over_all_possible_hands ( P(hand) * P(raise | hand) )
___
Computer-go mailing l
On Fri, May 14, 2010 at 4:34 PM, terry mcintyre wrote:
> I don't really play Bridge, but I've observed that the bidding process
> reveals considerable information about what is in each player's hands. A MC
> program for bridge would tailor distributions to incorporate this
> information. Bridge
84 matches
Mail list logo
