At 07:53 PM 12/3/2006, you wrote:
A note: we're working on converting Orego back from C++ to Java, ...
this is probably a silly idea, but i was recalling how you defined
location in some of your previous code. also, you had arrays of
boards and neighbors. something like board[], north[], sou
mputer-go
> Subject: Re: [computer-go] language choices
>
>
> On 12/6/06, Magnus Persson <[EMAIL PROTECTED]> wrote:
> > Note that to get these data I deleted all games where
> Valkyria lost on
> > points, because close to 100% of those games were not scored
> &
I'm getting about 98.2 for purely random games, but Orego has a turn
limit that prevents a game from taking more than 162 moves on 9x9.
Peter Drake
Assistant Professor of Computer Science
Lewis & Clark College
http://www.lclark.edu/~drake/
On Dec 6, 2006, at 3:48 PM, Don Dailey wrote:
Wh
When playing 9x9 games from the opening position, what is the average
number of moves
per game?
Lazaurs reports about 107.3 but I'm porting over to the D programming
language and I'm getting about 101.4. I think there is a bug.
What are others getting here? I think most of us use the same eye
9x9, 2 GHz Intel Core Duo iMac.
Peter Drake
Assistant 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 converting Orego back from C
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
>> reserve(). But if you are allocating same-size blocks then there is a
>> quality memory pool in boost. It is hidden in one of the "details"
>> directories, but I've been using it for a long time for my Chain class.
>
> Here's a link to the documentation of that library:
> http://boost.org/libs/
At 07:53 PM 12/3/2006, you wrote:
A note: we're working on converting Orego back from C++ to Java,
great!
and
we're getting 5,000 (totally random at this point) simulated games
per second. We'll probably continue in this direction.
please keep us posted.
thanks
---
vice-chair http://ocju
On 12/5/2006, "Darren Cook" <[EMAIL PROTECTED]> wrote:
>> I think stl vector implementation on my linux box takes much more memory than
>> necessary (I mean using a memory pool, and a big time against memory
>> tradeoff), so perhaps being carefull, with 16 GB we could reach 20 minutes.
>
>The STL
that's truly bizarre. i've never been cheated on
kgs, and in fact think that with the right ruleset
it would be very difficult to be cheated. anything
about which there is any confusion can easily be
settled by playing it out.
One example: The other player made very strange moves building a pe
> I think that humans tend to cheat also against other
> humans. When I started
> on KGS I was cheated several times very badly and I
> have stopped to play. I
> thought Go players have better manners than chess
> players. This is probably
> true in real-live, but on an unpersonal environment
>
On 12/6/06, Magnus Persson <[EMAIL PROTECTED]> wrote:
Note that to get these data I deleted all games where Valkyria lost on
points,
because close to 100% of those games were not scored correctly. I do not
know
if it is incompetence or outright cheating, but it happens a lot.
Fortunately
Val
On 12/6/06, Magnus Persson <[EMAIL PROTECTED]> wrote:
Note that to get these data I deleted all games where Valkyria lost on points,
because close to 100% of those games were not scored correctly. I do not know
if it is incompetence or outright cheating, but it happens a lot. Fortunately
Valkyria
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.
It is not twice as fast, if you write the critical parts
in asm its more like 10 times.
like assembly language (or C) is almost completely a
Quoting [EMAIL PROTECTED]:
> 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 some seem to say that the KGS level is not the "true
hi Don,
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 :-)
If Sylvain provides me with a Mogo version that can connect t
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
> > and then make some error. The comput
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:
>
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
and then make some error. The computer would win and everyone would
cry it shouldn't have happened.The com
Le mercredi 6 décembre 2006 00:04, [EMAIL PROTECTED] a écrit :
> > > 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
> The machine is a central component of the Linux supercomputer cluster at
> CWI,
> where I used to work. Access is limited to CWI users I'm afraid:-(
Ok I understand.
> Can you compile it on any other Linux machine with an up to date gcc -O3
> -static -m64 ?
I will try and send it to you. We'll
On Tue December 5 2006 13:31, Don Dailey wrote:
> On CGOS, gnugu_3.7.4 is rated 1720. MoGo is is in the 2100-2200,
> presumably it's save to assume it is significantly stronger.
>
> But if we can assign an ELO rating to Gnugo 3.7.4, then we can add 300
> or 400 to get Mogo's current ELO rating.
> I think stl vector implementation on my linux box takes much more memory than
> necessary (I mean using a memory pool, and a big time against memory
> tradeoff), so perhaps being carefull, with 16 GB we could reach 20 minutes.
The STL vector is fairly efficient, especially if you are using
res
hi Sylvain,
This could be very interesting!
If by anyway I can have an user account on this machine, I can try to
compile
MoGo and launch it on KGS so that you can easily play, and everyone can
watch
the games.
What do you think?
The machine is a central component of the Linux supercomputer
Le Mardi 5 Décembre 2006 21:15, John Tromp a écrit :
> 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 opteron :). Perhaps something like 10
> > minutes
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
> > 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 some seem to say that the KGS level is not the "true"
level? If so, MoGo
Le Mardi 5 Décembre 2006 22:03, Don Dailey a écrit :
> 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
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 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
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 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 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 opteron :). Perhaps something like 10
minutes.
I think stl vector implementation on my linux box takes much more me
not to be overly critical here, but...
> Mogo would also have a memory problem.
then the proposed gendankenexperiment (if it could
run for a week in only a few minutes' time) doesn't
even make sense -- if it couldn't make use of all
of the extra time (compressed or otherwise), then
it can't make
Le Mardi 5 Décembre 2006 20:50, John Tromp a écrit :
> On 12/5/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > > Mogo would also have a memory problem. The UCT programs build trees
> > > in memory. My own program cannot think more than a few minutes
> > > without running out of memory - so
On 12/5/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Mogo would also have a memory problem. The UCT programs build trees in
> memory. My own program cannot think more than a few minutes without
> running out of memory - so even the experiment you propose cannot be
> done.
Yes you are r
> 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
> > suc
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 years ago I lived in Florida and played tenni
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
> 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 would promise not to spend more
than 1/2 hour on the game, and mogo would
> 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.
If you think so, go and try it! Its quite important to
know that.
You can play a game with some dan level at
http://itsyourturn.com/
__
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
>
> Give me a program that beats a dan level taking less
> than a week to process.
>
> I will code it in assembler if necesary to make it
> efficient for a competition. (parallel if necesary)
>
> The first part difficult.
> The second one is just engineering.
>
> 20 minutes or 20 hours is the same
Give me a program that beats a dan level taking less
than a week to process.
I will code it in assembler if necesary to make it
efficient for a competition. (parallel if necesary)
The first part difficult.
The second one is just engineering.
20 minutes or 20 hours is the same in this problem.
h
To me, computer go programming means basic research for now, as I don't
believe the existing algorithms get you very far (I may be too
ambitious, but I cant help it..).
Thus, I would program in a way that let's me explore everything very
fast, without caring too much about performance. This is w
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
> I don't see the
> logic why you
> can't do in Java something that performance gurus do
> in C. Just
> because it's Java? Because it makes sense?
the garbage collector might make you a little
bit more afraid of churning through objects,
and the difference between a new() and a malloc()
is sig
Don,
I disagree rather strongly with some of your statements.
On 4-dec-06, at 18:35, Don Dailey wrote:
This isn't a Java issue, it's most if not all computer languages - if
you really go all out to optimize your code for performance, you will
sacrifice readability, clarity, etc.
In princ
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 someone else.
>
>
> I'm curious
On 12/4/06, Peter Drake <[EMAIL PROTECTED]> wrote:
The three most important things seem to be:
1) Run java in -server mode. This appears to double speed for no effort
I understand this is largely the old optimize for processing or optimize for
interactivity trade off. It's almost as old as m
uter-go
Sent: Sunday, December 3, 2006 7:53:15 PM
Subject: Re: [computer-go] language choices
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 directi
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 someone else.
I'm curious though. If you have the time, could you point out in the
code in my public p
> "avoiding object creation" in a object oriented
Only at inner cycles / loops.
Of course you have to create a lot of objects and
complex structures / object relationships.
But on inner cycles / loops, just modify pre-created
ones, do not create new ones. That is idea of my
posting.
Creating
> 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
> Similarly,
> instead of
>
> Foo x = y.clone();
>
> do something like
>
> x.copyDataFrom(y);
>
> where of course you have to write copyDataFrom().
in C you can do something like:
(toward the beginning of your code)
CovZ= (double *)calloc(p*p*K,sizeof(double));
(and then inside so
The three most important things seem to be:
1) Run java in -server mode. This appears to double speed for no effort.
2) As you say, avoid creating objects. For example, instead of
creating a new array each time a method is invoked, make the array a
field and just clear it out when you need a
I would forgive weak optimization if the actual performance difference
was small and it wasn't painful to get close, like it is in java.
But from what I've read, you can interface C code directly, no special
gymnastics. In fact any external libraries are supposed to work as is,
just link them in.
I've debating trying to switch over to D with my project, but have not
yet done it. I use http://www.boost.org for a number of missing
features of C++ and worry about simply not having such things available
if I did switch over. I also worry that using D would scare away
developers.
-Origin
Would you like to share some experiences on tunning up
Java code ?
Yesterday I left my machine profilling the code.
(takes ages with TPTP).
I didn't research too much the results, but as far I
could see, creating objects is almost FORBIDDEN.
The "clone" method on game class which is used for
cre
Agner Fog, in his well known optimization guide, claims that Digital
Mars compilers are rather weak optimizers. But the features of D
language are indeed admirable.
I would be grateful to see direct performance comparison on MC Go program
(or on anything else)
http://www.agner.org/
BTW
Does any
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.
Peter Drake
Assistant Professor of Computer Science
Lewis & Clark College
http://www.lclark.edu/~drak
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.
Peter Drake
Assistant Professor of Computer Science
Lewis & Clark College
http://www.lclark.edu/~drake
62 matches
Mail list logo
