On Tue, 2007-12-11 at 21:17 -0500, Don Dailey wrote:
But what does this have to do with anything? What we are arguing
about is whether it's good to try to estimate probabilities. That's
what you have been critical of. Adding ladder code will improve any
evaluation function if done
Raymond Wold wrote:
I can code an algorithm that evaluates simple ladders correctly.
I'll repeat that. I can code a program that reads ladders better than a
pure MC program without knowledge of ladders. I can beat it. Human
knowledge programmed into a computer that does that one thing, that
I've been (and still am) a die hard supporter of C++, but since I program in
C++ for work (we develop gamelike software) I get tired of C++ day in and
out. I'd also like to push myself to learn some new things.
Lisp seems to me like a language I could really come to respect. I run
linux (no
Le mercredi 12 décembre 2007, Ben Lambrechts a écrit :
How do AGA ratings compare to KGS?
Sensei's Library is your friend ;o)
http://senseis.xmp.net/?RankWorldwideComparison
I believe this page has not been updated since last year change
on kgs ranking scale.
Kgs have the big advantage
Hi,
Thank you all who answered my question. I think I understand better
what each of you talks about. I still have the feeling that at some
level different people think about different things when referring to
some notion, but it's probably just me.
On Dec 10, 2007 11:26 PM, Don Dailey [EMAIL
On Dec 11, 2007 3:34 AM, terry mcintyre [EMAIL PROTECTED] wrote:
But what about doing a top-level analysis of the board just before starting
playouts, offering some hints
to the more interesting moves? During the middle game, and especially during
the endgame, top-level
analysis can provide
On Dec 12, 2007, at 10:09 , Nick Apperson wrote:
I've been (and still am) a die hard supporter of C++, but since I
program in C++ for work (we develop gamelike software) I get tired
of C++ day in and out. I'd also like to push myself to learn some
new things.
Lisp seems to me like a
Thank you, Harri.
It sounds promising. I will have a look at that.
Jacques.
I coded algorithm based for that representation, it really looks another
awesome thing worth of investigating.
Planning to use that for at least small board search investigations as it has
quite much power.
That
In message [EMAIL PROTECTED], Matthew
Woodcraft [EMAIL PROTECTED] writes
Don Dailey wrote:
Ok, let's get into semantics. Is superko an illegal move? Is it
simply forbidden or is it part of the rules that you lose immediately if
you play it? In card games that is called an irregularity
Vlad Dumitrescu wrote:
Hi,
Thank you all who answered my question. I think I understand better
what each of you talks about. I still have the feeling that at some
level different people think about different things when referring to
some notion, but it's probably just me.
On Dec 10, 2007
David Fotland wrote:
I don't think traditional go programs tally features and weights. They
estimate the final score.
When I say tally features and weights I really mean that they estimate
the final score. They basically tally the number of intersections
expected to be won, although I'm
Russ Williams wrote:
On Dec 11, 2007 8:53 PM, Don Dailey [EMAIL PROTECTED] wrote:
The play-out portion is a crude approximation for imagination. We
basically look at a board and imagine the final position.The MC
play-outs kill the dead groups in a reasonably accurate (but fuzzy)
I've looked into this a bit. My preference would be scheme and it's
my understanding that it may be a bit more efficient.
- Don
Urban Hafner wrote:
On Dec 12, 2007, at 10:09 , Nick Apperson wrote:
I've been (and still am) a die hard supporter of C++, but since I
program in C++ for work
Why does anybody care about how human-like our go programs' playing style
is? When we design airplanes we don't care about how bird-like their flying
style is; we care about objective measures like speed, acceleration, energy
efficiency... The merits of go programs should be based basically on
Take this with a grain of salt, since I am a novice, but my understanding
of the distinction is this: violating the ko rule flows from an incorrect
decision made by the player; playing a stone of the wrong color from external
mishap - the stone should not have been in the player's bowl. Usually
Álvaro Begué wrote:
Why does anybody care about how human-like our go programs' playing
style is? When we design airplanes we don't care about how bird-like
their flying style is; we care about objective measures like speed,
acceleration, energy efficiency... The merits of go programs should
Hear, hear! The question is not one of abandonment of the recognition of
uncertainty. Like Don Dailey, I think it's brilliant that UCT programs
explicitly manage uncertainty and winning probabilities. My concern is that
existing implementations have some serious but possibly fixable flaws in
I've not used scheme recently, but I certainly recall it fondly.
When I we were taught it, the language definition was famously shorter
than the index to the definition of the Common LISP.
cheers
stuart
On 12/12/2007, Peter Drake [EMAIL PROTECTED] wrote:
Chez Scheme is a good choice. For a
I have played 10 9x9, 6.5 komi, 5 min. games against MoGo release 3
using GoGui's command line path\GoGui\MoGo\mogo.exe under Vista
Ultimate 32b on a Core2Duo E6600. The typical mogo.exe's usage of both
processors is ca. 48.5% - 50.5%, i.e., one core is used fully while
Windows' system
Heikki Levanto wrote:
I was thinking that it could be quicker to do prototyping in something
like python, while having fast low-level functions in C. Since we
already have Lukasz Lew's ego library, I wonder if anyone has written
a wrapper around it to call it from python (or ruby, perl, or
My program was written in lisp, so naturally I concur. I'm not
actively using lisp any more, but I will offer various dialects
of common lisp as the consensus choice of dialect.
My favorite implementation is lispworks. The personal edition is
free and ought to be adequate for research.
The
On Wed, 2007-12-12 at 17:24 +0100, Robert Jasiek wrote:
I have played 10 9x9, 6.5 komi, 5 min. games against MoGo release 3
using GoGui's command line path\GoGui\MoGo\mogo.exe under Vista
Ultimate 32b on a Core2Duo E6600. The typical mogo.exe's usage of both
processors is ca. 48.5% - 50.5%,
At 05:24 AM 12/12/2007, Don Dailey wrote:
I've looked into this a bit. My preference would be scheme and it's
my understanding that it may be a bit more efficient.
If you're worried about efficient use of the machine, stay away from lisp
and scheme. Despite the claims of it can be as fast as
Terry,
Yes, I agree with everything here I think.Nobody ever suggested that
we should not improve the accuracy of the probability estimator.
In fact almost all the progress so far has been based on doing exactly
that. The programs are getting slower but smarter.
- Don
terry mcintyre
At 05:24 AM 12/12/2007, Don Dailey wrote:
I've looked into this a bit. My preference would be scheme and it's
my understanding that it may be a bit more efficient.
If you're worried about efficient use of the machine, stay away from lisp
and scheme. Despite the claims of it can be as fast as
Dave Dyer wrote:
At 05:24 AM 12/12/2007, Don Dailey wrote:
I've looked into this a bit. My preference would be scheme and it's
my understanding that it may be a bit more efficient.
If you're worried about efficient use of the machine, stay away from lisp
and scheme. Despite
These are true, but not the underlying problem.
The biggest underlying reason is the multiple constraints on
memory management;
a) since the data is typed rather than the pointers, every chunk of memory
has to be self identifying, not just for the garbage collector, but also so
(plus a
Any of those with recent Lisp experience have any opinions about multicore
capabilities?
What I've googled so far looks a bit rudimentary - mostly based on unix fork
semantics. I'm looking for something much lighter-weight, Erlang-style, which
could support thousands of cheap concurrent
Dave Dyer [EMAIL PROTECTED] writes:
The biggest underlying reason is the multiple constraints on
memory management;
But these constraints are not absolute truths. At least not in Common
Lisp: The language spec is not as constrained as described here and
the compilers add some additional
On Dec 12, 2007 2:32 PM, Stefan Nobis [EMAIL PROTECTED] wrote:
[...] and sometime it's even possible to outperform C code.
I just don't believe this. I propose a simple experiment to see who is
right. You pick a simple algorithm which you claim Lisp can run faster, you
propose the fastest Lisp
Jason House wrote:
On Dec 6, 2007 11:38 AM, Rémi Coulom [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Jason House wrote:
This may serve as a good test of if there is enough data to assign
values to the patterns.
I did not mention this in my paper, but you can
On Dec 6, 2007 11:38 AM, Rémi Coulom [EMAIL PROTECTED] wrote:
Jason House wrote:
This may serve as a good test of if there is enough data to assign
values to the patterns.
I did not mention this in my paper, but you can rather easily estimate
uncertainty margins around Elo values. This
On Dec 12, 2007 2:59 PM, Rémi Coulom [EMAIL PROTECTED] wrote:
Do you mean a plot of the prediction rate with only the
gamma of interest varying?
No the prediction rate, but the probability of the training data. More
precisely, the logarithm of that probability.
I still don't know what
On Dec 12, 2007 3:05 PM, Jason House [EMAIL PROTECTED] wrote:
On Dec 12, 2007 2:59 PM, Rémi Coulom [EMAIL PROTECTED] wrote:
Do you mean a plot of the prediction rate with only the
gamma of interest varying?
No the prediction rate, but the probability of the training data. More
I saw this on the Gambit-C web page:
With appropriate declarations in the source code the executable
programs generated by the compiler run roughly as fast as equivalent C
programs.
This is another way of saying it run pretty fast but not as fast as C.
- Don
Urban Hafner wrote:
On Dec 12,
On Dec 12, 2007 7:28 PM, terry mcintyre [EMAIL PROTECTED] wrote:
What I've googled so far looks a bit rudimentary - mostly based on unix fork
semantics. I'm looking for something much lighter-weight, Erlang-style,
which could support thousands of cheap concurrent threads. In Erlang, the
cost
terry mcintyre [EMAIL PROTECTED] writes:
Any of those with recent Lisp experience have any opinions about
multicore capabilities?
Multithreading is not available in ANSI CL, but most implementations
support multithreading in some ways. AFAIK SBCL, Corman Lisp, OpenMCL
and some more have true
On Dec 12, 2007 3:09 PM, Álvaro Begué [EMAIL PROTECTED] wrote:
On Dec 12, 2007 3:05 PM, Jason House [EMAIL PROTECTED] wrote:
On Dec 12, 2007 2:59 PM, Rémi Coulom [EMAIL PROTECTED] wrote:
Do you mean a plot of the prediction rate with only the
gamma of interest varying?
On Dec 12, 2007, at 20:28 , terry mcintyre wrote:
Any of those with recent Lisp experience have any opinions about
multicore capabilities?
What I've googled so far looks a bit rudimentary - mostly based on
unix fork semantics. I'm looking for something much lighter-weight,
Erlang-style,
On Tue, 11 Dec 2007, Don Dailey wrote:
Christoph,
Let me know when you are finished, what name you are playing under and
I will do the bayeselo thing to get a better figure.
I am playing using the 'tast-3k' account. Right, now I have 71 games
and a rating of 1979 ELO.
Also, I can
throw
I thinks it's very difficult to outperform C since C really is just
about at the level of assembly language.
To beat C I think you would have to write a better compiler.It
wouldn't be about the language but about the compiler.I'm sure a
really good language compiler can already beat a
Heikki Levanto wrote:
On Mon, Dec 10, 2007 at 04:08:48PM -0500, Don Dailey wrote:
Would you rather be 95% confident of a win or 90% confident?There is
only 1 correct answer to that question.
Yes, if you can offer me reliable confidence numbers. We all (should)
know
that MC evaluations
On Dec 12, 2007 3:31 PM, Jason House [EMAIL PROTECTED] wrote:
On Dec 12, 2007 3:09 PM, Álvaro Begué [EMAIL PROTECTED] wrote:
On Dec 12, 2007 3:05 PM, Jason House [EMAIL PROTECTED]
wrote:
On Dec 12, 2007 2:59 PM, Rémi Coulom [EMAIL PROTECTED]
wrote:
Do you mean a
Jason House wrote:
On Dec 12, 2007 3:09 PM, Álvaro Begué [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
On Dec 12, 2007 3:05 PM, Jason House [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
On Dec 12, 2007 2:59 PM, Rémi Coulom
[EMAIL PROTECTED]
On Dec 12, 2007 4:27 PM, Álvaro Begué [EMAIL PROTECTED] wrote:
Clearly I'm missing something, because I still don't understand. Let's
take a simple example of a move is on the 3rd line and has a gamma value of
1.75. What is the equation or sequence of discrete values that I can
take the
From: Stefan Nobis [EMAIL PROTECTED]
terry mcintyre [EMAIL PROTECTED] writes:
Any of those with recent Lisp experience have any opinions about
multicore capabilities?
Multithreading is not available in ANSI CL, but most implementations
support multithreading in some ways. AFAIK SBCL, Corman
Le mercredi 12 décembre 2007, Harri Salakoski a écrit :
Such comment just take my word back little it is maybe awesome but I can't
say is it or not, as have still bugs left.
E E E
E E E
BEE
WWWEBEE
E E EWBEE
E E WEBEE
ABCDEFG
For example current version(not released) goes
Hi Gunnar,
Gunnar Farnebäck: [EMAIL PROTECTED]:
Heikki Levanto wrote:
On Mon, Dec 10, 2007 at 04:08:48PM -0500, Don Dailey wrote:
Would you rather be 95% confident of a win or 90% confident?There is
only 1 correct answer to that question.
Yes, if you can offer me reliable confidence
On Dec 12, 2007 7:44 PM, Álvaro Begué [EMAIL PROTECTED] wrote:
Maybe I did something wrong, but dimwit aces this one:
10k 100k1M
dimwit-0.48r 1.000 1.000 1.000
This is the output at the end of those searches:
score=1 thr=5
How much nodes does it uses for this ?
B B B B B B B
B B B B . B B
B B B B B . B
w w w . B B B
. . . w B B B
. . w . B B B
A B C D E F G
Its same, I define area for movegenerator allowed points are same in both
cases.
It lets white play after whole first group is killed at least that increases
Actually adding lines for second player that if it has zero stones it is win
for first player.
Thats true at least normal life-dead problems :|, not maybe some seki kind
of things but for this it changed node count for 2282 nodes.
with 7 empty places, should'nt it be less than 7**3 = 2187 ?
This is awful for such a simple problem. Many Faces' static evaluation
function sees that the white group is unsettled, and
the life/death search finds the B2 killing move in one node (since after B2
the group is dead with no further search, and the move generator returns B2
as the first
Many Faces' life and death search is best first and probability based, but I
don't use UCT to select moves. I select the move that has the highest
probability of changing the value of the root (from success to fail or vice
versa). I don't use MC to evaluate the endpoints. I look forward down
Now it is only 2282 nodes, and it still has maybe bugs. It returns
immediately which is good, I have hopes for that it comes better even it has
no bugs because it lacs move ordering logic,
If I only find couple bugs its start to be what I expected. Then need to
make desision is it good enough
My tsumego applet determines without a search that black can kill,
and white might live if he moves first.
http://www.andromeda.com/people/ddyer/go/shape/ShapeApplet.html
A table lookup is a little better than searching 162438 nodes :)
For example current version(not released) goes trought
I am sure that it is good, can't compare node counts for anything which uses
any static knowledge.
2282 is current count and you can increase or decrease those
proofCounter/disProofCounter limits and it still
works but don't know exactly when it is doing it right.
t. hArri
- Original
5 ...
4 WW.
3 BBB..W.
2 ...B.W.
1 ..B..W.
ABCDEFG
Ha, I give blacks more room to play, and shape database did not find it, or
maybe I used it wrong :).
But this search find B2 now in 1258437 nodes :| which is quite much and
takes couple seconds.
Don't know but really hope it goes
Because I am just starting with Lisp, I find this an easy place to
start:
http://gigamonkeys.com/book/index.html
In the intro is the line:
For example, one vacation, having a week or so to hack Lisp, I
decided to try writing a version of a program--a system for breeding
genetic
Wed, 12 Dec 2007 07:14:48 -0800 (PST) terry mcintyre wrote:
Heading back to the central idea, of tuning the predicted winning
rates and evaluations: it might be useful to examine lost games, look
for divergence between expectations and reality, repair the predictor,
and test the new predictor
59 matches
Mail list logo
