A good way to structure 7x7 matches, is that you forget komi, and just
play 1 game as white and 1 games as black, adding up the territory in
both games.Then you don't have to worry about which komi is correct.
- Don
On Tue, 2006-10-10 at 13:02 -0400, House, Jason J. wrote:
> I think Crazy S
On Tue, 2006-10-10 at 10:17 +0200, [EMAIL PROTECTED] wrote:
> So indeed choosing the move with highest number of simulations seem a
> little
> better, whereas it is not statistically very significant (I could try
> with
> more games, but 800 is already quite a lot :-)).
Usually, a high scoring m
terrirory over win
> ratio.
>
>
> On 10/10/06, Don Dailey <[EMAIL PROTECTED]> wrote:
> > A good way to structure 7x7 matches, is that you forget komi, and just
> > play 1 game as white and 1 games as black, adding up the territory in
> > both games.Th
The stat's may change significantly even if I
give white the best 2nd move.
- Don
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of Don Dailey
> > Sent: Tuesday, October 10, 2006 10:49 AM
> >
On Wed, 2006-10-11 at 13:02 +0100, Nick Wedd wrote:
> Congratulations to MoGo, which as MoGoBot won the Formal division of
> last Saturday's KGS tournament with 8/10, and as MoGoBot13 won the Open
> division with 6/6. My report is at
> http://www.weddslist.com/kgs/past/19/index.html
>
> I have,
player is
getting a more realistic score, although still far from correct.
How clear is it that the correct Komi is 9 and not another value? Has
it been proved, or is just strongly believed? And how strongly?
- Don
On Wed, 2006-10-11 at 08:14 -0400, Don Dailey wrote:
> On Tue, 2006-10-10 a
I want to build a 7x7 omniscience database so I can "solve" 7x7 GO. I
did some calculations and come up with the following:
There are 239299329230617529590083 possible board states which is
calculated as 3^49. You can eliminate a large fraction of them by
considering a canonical representation o
were playing perfectly it should be zero percent for white
if 9 is the correct komi.
- Don
On Thu, 2006-10-12 at 17:26 +0200, Magnus Persson wrote:
> Quoting Don Dailey <[EMAIL PROTECTED]>:
> > How clear is it that the correct Komi is 9 and not another value? Has
> >
On Thu, 2006-10-12 at 11:51 -0700, Christoph Birk wrote:
> > The current result is 52.5 percent for white. Of course if the
> > programs were playing perfectly it should be zero percent for white
> > if 9 is the correct komi.
>
> Why are you not using komi=9 ?
Because Lazarus can't handle inte
he correct answer
but doesn't have to be perfect - a bloom filter will veto the few
incorrect answers.
- Don
> Cheers,
> David
>
>
>
> On 12, Oct 2006, at 11:38 AM, Don Dailey wrote:
>
> > 1 canonical position per 16
> > equivalent states. The actual number
I'm not against any size, but I would like to have a temporary 7x7
server to start with.
One idea is to run only one server at a time (perhaps keeping 9x9 always
active too.)We could even run each a month at a time and rotate
through them.
I would suggest we leave the 9x9 server alone -
On Sat, 2006-10-14 at 20:33 +, Vlad Dumitrescu wrote:
> The actual number of states that represent legal go position is
> smaller than that. Even more, I think there are legal positions that
> can be reached only by passing - these could also be skipped in a
> database, I think.
I don't see ho
On Sat, 2006-10-14 at 14:21 -0700, Dave Dyer wrote:
> 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.
Hi Dave,
I want the hybrid system to be able to evaluate
There is another technique that may be more effective that the one I
have been considering for building a hybrid search/database solver.
Suppose we used the same basic idea of building a function that can be
given the veto by a bloom filter, but the function in question returns
a best MOVE instead
On Sun, 2006-10-15 at 12:40 +0100, Jacques Basaldúa wrote:
> >Another question is how many illegal board configurations are
> there ...
> >by assigning each point on the board a random state of
> (white,black,empty)
>
> That does not represent real game positions. All positions have about
> 7x7x
> When I have some free time and if Don is interested, I may run some
> simulations for the method I proposed and post some results. Don,
> please let me know whether your mind is made up already.
I am pretty sure I will stick with my original idea now of just choosing
the best of N random sele
I have a little 7x7 go server up and running. I'm currently getting a
few player seeded - it will take quite a while to get established
ratings for players when only AnchorMan is established.
I am also working out a few web server issues. There is no way to see
the results until this is figure
I have a temporary server up for 7x7 CGOS thanks to Thomas Wolf who
procured a machine for me to use.
The following URL gives the status of the games:
http://139.57.131.70:8015/7x7.html
And you must fix up the client program to point to the correct server.
A client that is ready to go is here
On Tue, 2006-10-17 at 14:35 -0400, Don Dailey wrote:
> I have a temporary server up for 7x7 CGOS thanks to Thomas Wolf who
> procured a machine for me to use.
>
> The following URL gives the status of the games:
>
> http://139.57.131.70:8015/7x7.html
>
>
> And you m
percent of the games at that komi.
- Don
On Tue, 2006-10-17 at 14:13 -0700, Christoph Birk wrote:
> On Tue, 17 Oct 2006, Don Dailey wrote:
> > It's interesting that (relatively) strong players are still losing games
> > with both colors, despite the 8.5 komi.
>
> I am no
On Wed, 2006-10-18 at 09:16 +0200, Rémi Coulom wrote:
> Thanks to you and Thomas for setting this up.
>
> Last night Crazy Stone lost one game on time. Probably my ISP cut the
> connection for a while in the middle of the night (it has not been
> very
> reliable lately). The error message that I
On Wed, 2006-10-18 at 12:19 -0700, David Doshay wrote:
> Are the elo ratings integer or floats?
>
> I am just wondering if partial (less than one) ratings build up or
> are truncated.
CGOS tracks the ratings as floating point numbers but rounds the results
for display.
If you see two identical
In Game 334564, it's also not a server error - but it's an amazing
superko.
If 101. B g5 were allowed, then it would exactly match the position
after 71. B e6.
After 71. B e6 was played a huge black group was captured, then a huge
white group was captured and yet history repeated itself.
You
CGOS uses positional superko.
if 97. B A5 is played, the board configuration would match
the position immediately after 89. B H5 was played.
- Don
On Sun, 2006-10-22 at 03:48 +0200, Heiner Spies wrote:
> Hi all,
>
> who would be so kind as to tell me what's wrong
> with the attempted moves
There is no bug, the server was apparently rebooted last night.
It's up and running now.
- Don
On Sun, 2006-10-22 at 12:14 +0200, [EMAIL PROTECTED] wrote:
> Hello,
>
> I have failed connecting a bot to cgos. The error message is:
>
> server startup return code: 1 msg: couldn't open soc
How would it affect the game if KO's were handled like in chess? In
other words, you may repeat the position in situational superko style,
but you have achieved a draw if you do.
It seems like it would be an interesting go variant. Presumably one
side would always feel compelled to avoid KO (
I'm in a similar situation, I'm trying to identify classes of moves
that I can eliminate in an admissible way - which means the move I am
throwing out is either not the best move, or there are other equally
good moves.
I know that pass moves can be the best move in seki situations - and
it's non-
On Mon, 2006-10-23 at 11:25 +0200, Erik van der Werf wrote:
> On 10/23/06, Don Dailey <[EMAIL PROTECTED]> wrote:
> > ... A region of 7 inside a benson
> > group cannot possibly support enemy life. So moves inside
> them
> > by either col
When someone mentioned a position where a pass-alive group should be
sacrificed - I wondered if it was also due to PSK issues.
I want to clarify something I said about PSK. I don't think the rule is
"wrong" in any sense - after all you can make up any rules you want as
long as they are internally
ng computer GO today.
- Don
On Mon, 2006-10-23 at 09:41 -0400, Don Dailey wrote:
> When someone mentioned a position where a pass-alive group should be
> sacrificed - I wondered if it was also due to PSK issues.
>
> I want to clarify something I said about PSK. I don't
N be 2 * boardsize. On 9x9 a game is over after 162
plays. It would be 722 for 19x19.
Ok, let me change CGOS to do it this way now just kidding.
- Don
On Mon, 2006-10-23 at 16:44 +0200, John Tromp wrote:
> On 10/23/06, Don Dailey <[EMAIL PROTECTED]> wrote:
Let me address some of your points directly:
> ...
>
> In Go, the forbidden ko point is another piece of information you could
> add, being similar to en-passent capture possibilities in that it is only
> about what happened in the last move.
>
> You may well say "2 identical configuration - on
On Mon, 2006-10-23 at 16:01 -0200, Mark Boon wrote:
>
> On 23-okt-06, at 14:23, Don Dailey wrote:
>
> > Then all the nonsense goes away. It then comes down to each player
> >
> > having his fate in his own hands.If you want to win, you will
> > avoid
&g
wrote:
> On 10/23/06, Don Dailey <[EMAIL PROTECTED]> wrote:
>
> > I'm not very good at GO, but I would assume that it would change the
> > game some. But it would be a change that was adjusted to. Knowing how
> > to avoid these situations would be part of a
On Mon, 2006-10-30 at 19:34 -0800, Peter Drake wrote:
> I'm running into a problem where my Monte Carlo program is very slow
> to acknowledge that its favorite move has a strong counter.
> Part of the problem is that the value of a move is based on how many
> of the runs through that move have
Start with the "low hanging fruit".You haven't implemented
alpha-beta pruning yet, but you should, that is an enormous speedup.
After implementing alpha beta pruning you should spend a lot of time on
move ordering - doing a lot of experiments to see what is best as this
will give you additiona
I think it's all in the presentation. Even if they are not even
beginners, with skill you can help them appreciate how some basic
concepts are difficult for a computer.
For instance, I think that you can teach the principle of 2 eyes with a
very simple example perhaps involving just 1 point e
Sylvain,
The improvement over a given opponent should be measured by ELO points,
not win percentage unless you do the extra math. I cannot quite tell if
you were considering that or not - if so then ignore this. Going from
50% wins to 60% with is a modest improvement, but going from 80% to 90%
Sylvain,
Yes, I meant UCT, I have been working on converting my chess program to
use the UCI protocol and so it was on my mind! (Incidentally, I think
this is a better protocol that GTP, but I don't want to start a war
here!)
I can't help but feel we are missing something. With UCT we miss t
On Fri, 2006-11-24 at 10:47 +, Jacques Basaldúa wrote:
> Chrilly wrote: (thread was "Positions illustrative of computer stupidity")
>
> > With an infinite fast chip chess programs would be "infinite"
> > strong. Most current Go programs would only play infinite fast.
> > Its an interesting q
Richard,
The key word is not "infinite", it's the word "if"
The statement was "IF we had an infinite computer "
It doesn't matter one bit whether such a device is possible - it's a
perfectly valid "thought device" for thought experiments.It's easy
to imagine what we would do with such
On Fri, 2006-11-24 at 13:38 -0800, steve uurtamo wrote:
> on a practical note, i think that MC is a great
> idea for 9x9, and might even be a great idea as
> a subset of a larger piece of code that employs
> human knowledge, but that MC will never beat a
> decent human at 19x19. the time/space lim
> > We can also imagine the moon being made of green cheese without this
> > actually being the case. I don't see any problem with considering the
> > behavior of a machine with certain characteristics just because we can't
> > produce one.
>
> Of course we can imagine the moon being made of gre
Yes, I agree with the point you are making. Random play is a relatively
good evaluator, but it is not a great evaluator. And it's very weak at
tactics. Letting it do a lot of simulations does not cause it converge
to the correct value.
But the current breed of MC computer players do not have
I would not trust this. Usually, masters cannot be objective and fair
when they are referring to their own playing ability.
- Don
On Mon, 2006-11-27 at 19:35 +0900, igo wrote:
> >> I assume in Go the difference is also a very large handicap.
> > in any case, i think that the difference is prob
And just to add to this, I'm sure their tune would change if the bet
was really for their life.
- Don
On Mon, 2006-11-27 at 07:23 -0500, Don Dailey wrote:
> I would not trust this. Usually, masters cannot be objective and fair
> when they are referring to their own playing ability.
A good point to consider - is "God" actively trying to confuse his
opponent and complicate things, or is he simply playing objectively best
moves?
- Don
On Mon, 2006-11-27 at 07:39 -0800, steve uurtamo wrote:
> > >wow. i thought that there were at least two
> > >stones worth of slack in the open
I've often wondered how I would program a computer to play a game, chess
or go,
if I had perfect information about the game.How do you make it more
difficult
to win against a fallible opponent?
I assume that in many positions there are more than 1 maximizing move.
I would of
course restrict th
A good "devil" tries to win by MORE than he deserves and will
try to win in a losing position.
I have heard this terminology before and my understanding was
that a devil still plays a perfect game, he just tries to be
deceptive about it.
I don't see any point in not playing perfect if you can u
e number of moves from start to finish. Give He is
> timeless, the length of game, hence the value of n, is not meaningful.
>
> Now, if God had a younger brother who liked to play Go...none of what
> I said above means anythingwhich is still true even if He doesn't.
> (a n
I have heard this many times - but it doesn't always apply. In fact I
have heard that IMPROVEMENTS always look better against your
twin-brother but if that were true, I would always want to test against
my twin since it makes improvements stand out. It's hard to measure
small improvements so thi
eeing a problem with
transitivity.
- Don
On Wed, 2006-11-29 at 15:15 +0100, alain Baeckeroot wrote:
> Le mercredi 29 novembre 2006 14:21, Don Dailey a écrit :
> > I have heard this many times - but it doesn't always apply. In fact I
> > have heard that IMPROVEMENTS always look
The thing about java is that it seems to be a big memory pig.
I can't have multiple java processes running without suddenly
getting a lot of memory thrashing.
If I do things in C, everything screams.I always figured
this is a problem with java that will be solved - but to this
day it hasn
It's been my experience that the bigger the project, the less difference
it
makes if you use a high level language.
There are some awesome high level languages that are very good for quick
and
dirty programming tasks. But the advantage seems to go away as soon as
you have
a substantially larg
Hi Jim,
I feel similarly to you.
I have to take exception to what someone posted earlier - Java keeps
getting presented as some kind of high level language than enables a
natural expression of ideas. This is total garbage. Java is a low
level language and very much a C dialect. I don't under
On Thu, 2006-11-30 at 21:26 +0100, Chrilly wrote:
> >
> > I believe that MC will be the only way to write a GO program in the
> > near future leaving the other stuff in the dust (like Mogo has with 9x9
> > Monte Carlo Go.)This happened in computer chess several times,
> > someone came up with
No, you can't test it that way. The thing with monte carlo is the
discovery and then very rapid progress of it. Even 2 years ago they
were not very good compared to what they are now.I haven't seen that
in
My statement was about a way forward - I'm not saying they are currently
much bette
On Thu, 2006-11-30 at 18:40 -0800, David Fotland wrote:
> How does monte carlo go do with fights that are trivial to evaluate, but
> hard to search?
It's easy to construct problems that any program cannot handle including
yours.
You have to understand that Monte Carlo is not great at tactics,
On Fri, 2006-12-01 at 08:39 -0800, David Fotland wrote:
> What's included in an evaluation? Is each evaluation one random game, or a
> set of random games that gives good enough statistics about the value of a
> position?
When you say "random" it conjures up images of aimless wandering - but
the m
Hi David,
Since I made my last post to you, several people have responded. They
have made my point and I agree with your point.
It's foolish not to take advantage of domain specific information and
nothing prevents a monte carlo program from doing that as you can see.
Having said that, I ha
Since we have been talking about programming language recently, I was
curious as to whether anyone on this group has experimented with the
digital mars D programming language?
>From the hype on the web page, it looks an extremely capable programming
language that is supposed to be fast native code
deed admirable.
> I would be grateful to see direct performance comparison on MC Go program
> (or on anything else)
>
> http://www.agner.org/
>
> BTW
> Does anybody know what is the performance of the native compiled C# ?
>
> Best Regards,
> Lukasz
>
> On 12/4
> 3) Algorithmic improvements are always more important that
fine-tuning.
It depends on what you mean by algorithmic improvements. Do you mean
performance improvements or do you mean conceptually cleaner code?
Sometimes you get both, but other times you have to write difficult to
understand code
On Mon, 2006-12-04 at 17:37 -0200, Mark Boon wrote:
>
> On 4-dec-06, at 15:23, Don Dailey wrote:
>
> > But it seems like more of a travesty in Java.
> >
>
>
> Well, this may be subjective. What may seem like travesty to one may
> appear completely normal to
On Mon, 2006-12-04 at 12:15 -0800, Dave Dyer wrote:
> 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)
On Mon, 2006-12-04 at 19:30 -0200, Mark Boon wrote:
> The object pooling is the only thing I'd rather do without. But for
> speed that's not possible, unfortunately. However it hardly affects
> cleanliness or readability as there's not such a big difference
> between a constructor call and a
On Tue, 2006-12-05 at 15:10 +0100, Chrilly wrote:
> Sylvain Gelly wrote:
> You are totally right. For Yizao (one of the author of MoGo), who is a
> good Go player, this gives a bad "style" to MoGo. As I don't know how to
> play Go (beyond the rules :)), I don't see any style and I don't care :).
>
On Tue, 2006-12-05 at 06:11 -0800, steve uurtamo wrote:
> > Give me a program that beats a dan level taking less
> > than a week to process.
I'll bet Mogo would give a dan level player fits at 9x9 if 1 week of
thinking time per move could be compressed enough to play a 30 minute
game.
- Don
>
On Tue, 2006-12-05 at 09:51 -0800, steve uurtamo wrote:
> > I'll bet Mogo would give a dan level player fits at
> > 9x9 if 1 week of
> > thinking time per move could be compressed enough to
> > play a 30 minute
> > game.
>
> you could always get a dan player to volunteer for
> such a game. he wo
On Tue, 2006-12-05 at 13:57 -0500, Don Dailey wrote:
> In fact, in honor of Chrilly's laws I will call this "Don's law".
> "What really counts is how bad your bad moves are."
By the way, this principle is true in just about every aspect of life.
A few yea
On Tue, 2006-12-05 at 20:40 +0100, [EMAIL PROTECTED] wrote:
> > On Tue, 2006-12-05 at 09:51 -0800, steve uurtamo wrote:
> > > > I'll bet Mogo would give a dan level player fits at
> > > > 9x9 if 1 week of
> > > > thinking time per move could be compressed enough to
> > > > play a 30 minute
> > > >
On Tue, 2006-12-05 at 12:09 -0800, steve uurtamo wrote:
> an i think that if you were to perform these
> experiments one at a time (i.e. give yourself
> 10x more time, and see if you can beat an 6kyu,
> then 100x more time and see if you can beat a 4kyu,
> etc.), many of which are reasonable (we al
On Tue, 2006-12-05 at 21:15 +0100, John Tromp wrote:
> On 12/5/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> > How long would it take Mogo to fill up 16GB of memory on a
> quad core
> > opteron machine?
>
> It depends on the speed of your op
Nick,
I would love to see such a tournament, but the UCT programs could not
take full advantage of the extra time. As you see, we run out of
memory after a minute or two!
- Don
On Tue, 2006-12-05 at 20:48 +, Nick Wedd wrote:
> Jason:
> Thank you for pointing out these errors. I have fi
Sylvain,
You can extend this pretty easily by doing 2 or more simulations at a
time.
The trade-off is very good for doing this although not 100%.I HAVE
to do this for Lazarus because I have very little memory in my machine.
I believe I'm doing 8 simulations at a time in order to use about 1
On Wed, 2006-12-06 at 00:04 +0100, [EMAIL PROTECTED] wrote:
> > > So that I can follow this discussion, how would be the "kgs level" of
> > > this player (it is the only level I have access to when looking at the
> > > results of game)?
> >
> > Wouldn't it be 1 dan on KGS?
> I don't know because so
Hi John,
Why can't you just play it live on KGS? This is much more exciting.
We would have no way to know if you were taking back moves or anything.
(Although I believe you to be an honest person I still like to see for
myself :-)
- Don
On Wed, 2006-12-06 at 00:37 +0100, John Tromp wrote:
>
On Wed, 2006-12-06 at 02:24 +0100, Andrés Domínguez wrote:
> 2006/12/5, Don Dailey <[EMAIL PROTECTED]>:
> >
> > I speak from experience. I know exactly how these things work. The
> > match would begin, the human would probably be outplaying the computer
> >
On Mon, 2006-12-04 at 18:32 +0100, Łukasz Lew wrote:
> I deal with eyes by randomizing list of empty intersections before the
> playout, and while searching non-eye I go through them in circular
> manner.
What do you mean by circular and what does this have to do with eyes?
I'm looking to speed m
On Sun, 2006-12-03 at 19:53 -0800, Peter Drake wrote:
> A note: we're working on converting Orego back from C++ to Java, and
> we're getting 5,000 (totally random at this point) simulated games
> per second. We'll probably continue in this direction.
Hi Peter,
Which hardware is this on and
stant Professor of Computer Science
> Lewis & Clark College
> http://www.lclark.edu/~drake/
>
>
>
>
> On Dec 6, 2006, at 2:59 PM, Don Dailey wrote:
>
> >
> > On Sun, 2006-12-03 at 19:53 -0800, Peter Drake wrote:
> >> A note: we're working on con
Ok, I found the bug and I have basically ported just enough of the
program over to D to run my performance benchmark - 1000,000 random
games from opening position.
Since D is a cleaned up version of C++, it's easy to port and I'm
trying to write it in pretty much exactly the same style - cutti
s that Lazarus running at this
1.47 handicap would be noticeably weaker on CGOS. I might accept the
slowdown if it were more like 1.25, for the extra convenience. This
language is very good at helping you with bugs - checking array bounds
problems etc.
- Don
On Wed, 2006-12-06 at 22:1
:
http://www.tiobe.com/tpci.htm
- Don
> BTW
> D is geting more popular recently.
> http://www.tiobe.com/tpci.htm
>
> Lukasz
>
> On 12/7/06, Don Dailey <[EMAIL PROTECTED]> wrote:
> > Ok, here is my report on the D language for Go:
> >
> > The gdc
t take next empty intersection.
>
> "Circular" reduces frequency of such wasteful events.
> It means that I check next empty intersection in the vector starting
> from the place I finished last time.
>
> I hope this is clear now. If not, just ask :)
>
> Lukasz
of C APIs available. How much easier
it is to just call them directly."
- Don
> BTW
> D is geting more popular recently.
> http://www.tiobe.com/tpci.htm
>
> Lukasz
>
> On 12/7/06, Don Dailey <[EMAIL PROTECTED]> wrote:
> > Ok, here is my repor
On Thu, 2006-12-07 at 08:15 -0800, Peter Drake wrote:
> On Dec 6, 2006, at 9:36 PM, Don Dailey wrote:
>
> > The equivalent C version (after I took out some optimizations) is
> > doing 13,745.70 games per second on an old pentium 4.
>
> I'd really love to know what
On Thu, 2006-12-07 at 16:05 +0100, Łukasz Lew wrote:
> ii = pm::rand () % empty_v_cnt; // TODO improve speed "%"
Try this, I think it could be faster, not sure, but has the advantage
that it's slightly more correct.
// returns an integer between 0 and n-1 inclusive
//
unsigned lon
s well fix this.
- Don
On Thu, 2006-12-07 at 12:12 -0500, Don Dailey wrote:
> On Thu, 2006-12-07 at 16:05 +0100, Łukasz Lew wrote:
> > ii = pm::rand () % empty_v_cnt; // TODO improve speed "%"
>
>
> Try this, I think it could be faster, not sure, but
(and how I found a
previous bug.)
So it appears that D is perfectly usable as a very fast compiled
programming language, at least as compared to gcc with all the
optimizations I know to do.
- Don
On Thu, 2006-12-07 at 12:28 -0500, Don Dailey wrote:
> In fact, I just wrapped this up int
On Thu, 2006-12-07 at 10:24 -0800, Peter Drake wrote:
> Got it -- now I'm getting just under 10,000 games per second! Whee!
Hold on, I thought the non-threaded version was doing 5,000? What
exactly did you change? Or are you just using 2 processors more
efficiently to get 10,000 games?
- Don
On Thu, 2006-12-07 at 09:17 -0800, Peter Drake wrote:
> I do have the undo ability, but I think it's done in (I think) a
> very
> efficient way. For example, when I want to undo a bunch of move at
> once (e.g., after a MC run) I just reduce a stack pointer.
BINGO! I'm pretty sure that is yo
I'm pretty sure the time of this function is dominated by the call to
rand(), but it never occurred to do a table lookup for the mask,
interesting idea.
- Don
On Thu, 2006-12-07 at 22:36 +0100, Antoine de Maricourt wrote:
> If this randint routine is critical, you can save some calls to rand()
On Thu, 2006-12-07 at 14:09 -0800, Peter Drake wrote:
> > In the search tree part of the game, (not the random simulation
> > part) I
> > make state copies, do Zobrist hashing and full repetition checks and
> > other stuff - the tree part is cheap.
>
> Agreed -- the playing of moves is the expe
7;s too expensive even to
maintain the incremental hash key - so I have 2 move make routines, one
that maintains it and one that doesn't.
- Don
On Thu, 2006-12-07 at 18:13 -0500, Don Dailey wrote:
> On Thu, 2006-12-07 at 14:09 -0800, Peter Drake wrote:
> > > In the search tree par
I will test it with a table derived mask and see what happens. I would
like the table to be large enough to encompass 19x19 GO too, but I'll
test it with a small table first.
- Don
On Fri, 2006-12-08 at 00:39 +0100, Antoine de Maricourt wrote:
> Last time I checked MT was under 20cc per call (I
By the way,
I'm amazed that the code for playing random games is fast enough that
getting random numbers is actually a bottleneck and it's worthy of a
discussion on optimization.
One of the fastest chess programs a few years ago in terms of nodes per
second was Fritz. It heavily used a common te
Yes, there are fast little generators that would probably serve our
purposes, however I don't want to have to spend too much time checking
them out so I found one that was known to be quite fast, the Mersenne
Twister.
But what you say is now a consideration based on what I've learned about
the spe
112 moves on average in a 9x9 game? You are doing something a little
different than I am and others have reported the same number I get,
about 107.3 - 107.4
What is your eye avoid rule?
- Don
P.S. 30K on 1.4 Celeron is almost too good to be true. If this is
correct that's very impressive a
eck next empty intersection in the vector starting
> from the place I finished last time.
>
> I hope this is clear now. If not, just ask :)
>
> Lukasz Lew
>
> On 12/6/06, Don Dailey <[EMAIL PROTECTED]> wrote:
> > On Mon, 2006-12-04 at 18:32 +0100, Łukasz Lew wrote
1 - 100 of 2315 matches
Mail list logo
