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

2007-04-25 Thread Jason House
On 4/25/07, Remi Munos [EMAIL PROTECTED] wrote: When I did sit down and read the paper for real, I saw that both of those things were just building up the support for the BAST algorithm. (a) is to justify accepting a higher regret (in exchange for better worst case performance). well,

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

2007-04-24 Thread Jason House
I haven't gotten to read through your paper as carefully as I'd like yet, but I do have a few observations that may be of benefit to other readers on the list... Mostly observation of assumptions used in the paper. 1. A max tree is used instead of minimax 2. Rewards can be more than just 1 or 0

Re: [computer-go] Computer tournament at next US Go Congress?

2007-04-13 Thread Jason House
On 4/12/07, Peter Drake [EMAIL PROTECTED] wrote: The next US Go Congress will be held July 28 - August 4, 2007, in Lancaster, Pennsylvania: http://congress.usgo.org/ Is anyone else planning to attend? I would, at the very least, like to gather a casual meeting of Go programmers. I would

Re: [computer-go] Computer match time

2007-04-12 Thread Jason House
Not having byo yomi because it's tough to code isn't really a good argument. If we want (non-computer-go) people to take the results seriously, the game timing should be the same as what people naturally do. I personally am hesitant to play games with fixed time limits because I don't trust

Re: [computer-go] Computer match time

2007-04-12 Thread Jason House
wrote: On Thu, 2007-04-12 at 11:18 -0400, Jason House wrote: Not having byo yomi because it's tough to code isn't really a good argument. If we want (non-computer-go) people to take the results seriously, the game timing should be the same as what people naturally do. I personally am

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

2007-04-11 Thread Jason House
As with anything, an efficient serial algorithm (alpha-beta, UCT, etc...) becomes less efficient when made parallel. I think you can see some significant improvement with parallel machines, but it may be that you'll get diminishing returns. I can think of two parallel approaches: 1. Instruct

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

2007-04-07 Thread Jason House
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

[computer-go] Taking the D plunge

2007-03-31 Thread Jason House
I'm doing a redesign of HouseBot and rewriting it in D instead of C++. Since there was past interest in the D language on this list, I figured I'd advertise the switch-over. I'm not at the code writing stage yet because I'm trying to do a proper (re)design. If the move to D is enough to

Re: [computer-go] Taking the D plunge

2007-03-31 Thread Jason House
I definitely have a number of gripes with the language, but it's not enough to stop me from trying it out. I didn't realize changes occurred so quickly, but I don't think they break old code very frequently. Most changes appear to be bug fixes or additions to the language. Here's my list of

Re: [computer-go] Thank you for the help testing

2007-03-29 Thread Jason House
What is your policy for receiving/handling feature requests? Is there a tracker (e.g. sourceforge) or a wiki page (e.g. senseis)? Or do we just e-mail you directly? On 3/29/07, Don Dailey [EMAIL PROTECTED] wrote: I aslo recieved many useful suggestions about feature improvements or additions

Re: [computer-go] Re: pseudoliberties

2007-03-29 Thread Jason House
After some trial and error, I got 90 * * * * * * * * * * * * *** * * * *** * * * * * * * * * * * * On 3/29/07, John Tromp [EMAIL PROTECTED] wrote: On 3/29/07, John Tromp [EMAIL PROTECTED] wrote: Is 88 the maximum number of pseuoliberties a string can have on 9x9? Make

Re: [computer-go] Re: pseudoliberties

2007-03-29 Thread Jason House
Arthur W Cater wrote: It's really a way to incrementally update liberties in a fast way - each stone keeps it's own count of liberties and it is summed - but of course it doesn't represent the true number of liberties since a point can get counted 2 or more times.However, if the count goes

Re: [computer-go] Re: pseudoliberties

2007-03-29 Thread Jason House
Chris Fant wrote: Once upon a time, I did analysis of the inaccuracy of pseudo liberties. Searching quickly, I found: http://computer-go.org/pipermail/computer-go/2005-October/003839.html For any interested, I did come up with a variant of pseudo liberties that was a lot closer to real

Re: [computer-go] Help me test CGOS

2007-03-26 Thread Jason House
I don't see any games that have an outcome other than winning by points or resignation. Any forfeits or games that are on hold? Don Dailey wrote: I have a prototype of the new CGOS server up and running. Please help me test it. I have set up a 2 MINUTE SERVER, i.e. 2 minutes per side for

Re: [computer-go] Suppose we had a go problem server?

2007-03-25 Thread Jason House
There are some freely available regression test suites. Two come to mind: * computer go test collection 2.0 * The regression suite available in gnu go Also, go gui has a program called gtpregress that can handle both of those out of the box (I think) Brian Slesinsky wrote: I've been lurking

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

2007-03-03 Thread Jason House
Jacques Basaldúa wrote: 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.

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

2007-03-01 Thread Jason House
alain Baeckeroot wrote: (I propose to ban the term temperature from CGT, and replace it by value, unless someone can explain the link with temperature in physics, and shows some identical properties ;-) While I bet most of us dislike the term, it seems to express an inherent concept.

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

2007-03-01 Thread Jason House
I respond to various items below. Sections of the original e-mail that I'm not responding to were completely deleted. Jacques Basaldúa wrote: Hello Jason I think what you are trying to do can be done more easily. I guess the key question is what am I trying to do?. In UCT, the next move

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

2007-02-28 Thread Jason House
Based on my analysis, estimating a moves probability of winning by taking the number of winning simulations (w) and dividing it by the total number of simulations (n) is actually biased. I tried to break this e-mail up into sections for easy digestion by the various people who might read

Re: [computer-go] Effective Go Library v0.101

2007-02-15 Thread Jason House
Heikki Levanto wrote: To get down to earth, I would like to look at the board at the end of each playout, calculate something more than just win/loss, and pass that info back to who ever called playout. One way to do that would be to pass a function pointer and a (void?) pointer to playout, and

Re: [computer-go] Effective Go Library v0.101

2007-02-14 Thread Jason House
?ukasz Lew wrote: Generally http://en.wikipedia.org/wiki/Disjoint-set_data_structure In my program it's a tree for each group of stones. In the root is number of pseudoliberties. Joining is cheap and checking group membership is cheap. Look at chain_t class. in board.cpp Best, ?ukasz Lew I

Re: [computer-go] Why not forums?

2007-02-11 Thread Jason House
Dmitry Kamenetsky wrote: I have been reading this list for nearly a year now and it is very discouraging to receive so much criticism for my first post. Sadly, you chose a topic that is close to the hearts of many. I like the style of this follow up post much more than the original in

<    1   2   3   4   5   6