On 1, Dec 2006, at 6:15 AM, Wodzu wrote:
- Original Message - From: David Doshay [EMAIL PROTECTED]
Also, my data shows that if I doubled the time allowed for
playing, thus
using the time gained from faster execution for doing deeper
lookahead,
the results did not improve, but
C++ should be good. But take it with double care. I
would code a lot of unit tests. If test driven
development is followed, I suppose it will be a good
piece of software, and, at the end of the day, a pro
product.
Test Driven Development, regression tests, profilling,
code coverage, I would
Huh, why not use Pascal? It has speed of C and
simplicity of Java :)
heck, you could use perl. plenty of packages
available (it can even be made multithreaded!),
shared memory packages, etc.
i mean, if speed isn't your top concern...
i think speed is one of most important things
Wodzu,
There are roughly two types of approaches to bettering the skill of
computer go solutions; incremental and breakthrough. I think for
incremental solutions, ones where lots of work results in small shifts
in better go playing performance, you are correct. Any optimizations
around
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
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 some breakthrough idea, proved it with actual
results and everyone
-greenberg.com
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Peter Drake
Sent: Wednesday, November 29, 2006 9:01 AM
To: computer-go
Subject: Re: [computer-go] Making Java much faster
This is something we hope to do once we have Orego multithreaded
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 some
I have been *so* tempted to either ignore this thread or rename it ...
On 30, Nov 2006, at 10:36 AM, Wodzu wrote:
i think speed is one of most important things beacuse it affects
strength of the program ;) (if the time for move is restricted)
anyway, chosing a proper (fastest) algorithm has
://www.inventivity.com
http://www.jeffrey-greenberg.com
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Peter Drake
Sent: Wednesday, November 29, 2006 9:01 AM
To: computer-go
Subject: Re: [computer-go] Making Java much faster
This is something we hope to do once we
Perhaps your comment is related to something i write
before.
I was not talking about the expressiveness of java
language. In that sense, Ocaml, Lisp, SmallTalk are
far, far away from Java.
Java is a C (almost C++) with garbage collection,
bound checking and variable initialisation. (its a lot
Also, my data shows that if I doubled the time
allowed for playing,
thus using the time gained from faster execution
for doing deeper
lookahead, the results did not improve, but actually
got worse.
Sorry for not adding nothing to usefull to the thread.
But I found this comment very
On 30, Nov 2006, at 3:46 PM, Eduardo Sabbatella wrote:
David Doshay wrote:
Also, my data shows that if I doubled the time
allowed for playing,
thus using the time gained from faster execution
for doing deeper
lookahead, the results did not improve, but actually
got worse.
Sorry for not
On Thu, 2006-11-30 at 14:44 -0800, David Doshay wrote:
This is not my experience at all.
SlugGo was first written by a graduate student with data structures
that made sense to them, but not to me. I rewrote it to use
completely different data structures but with exactly the same
On 30, Nov 2006, at 4:47 PM, Unknown wrote:
On Thu, 2006-11-30 at 14:44 -0800, David Doshay wrote:
Also, my data shows that if I doubled the time allowed for playing,
thus using the time gained from faster execution for doing deeper
lookahead, the results did not improve, but actually got
On 29-nov-06, at 08:43, Stuart A. Yeates wrote:
Other tricks for faster java include ensuring that, wherever
possible, you use the final, static and private keywords. This
enables the compiler to apply more compilation tricks in more places.
More and more I find that using 'final' or
difficult to talk about memory management between Java and
C++/C because their memory models are different.
- Original Message
From: Mark Boon [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Wednesday, November 29, 2006 9:22:14 AM
Subject: Re: [computer-go] Making Java
I'm a full time worker. Before starting my engine (a
couple of months ago) by 3rd or 4th try. I concluded
this:
It will be impossible for me to do anything in C, C++
because I will have to focus on not having memory
leaks, range errors, etc.
My engine nowadays is winning agains gnugo on lower
On Nov 29, 2006, at 9:26 AM, Eduardo Sabbatella wrote:
I'm a full time worker. Before starting my engine (a
couple of months ago) by 3rd or 4th try. I concluded
this:
It will be impossible for me to do anything in C, C++
because I will have to focus on not having memory
leaks, range errors,
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
However, we are finding C++ an exceedingly frustrating language to work
in. I won't go into the details here -- we don't need another language
war -- but suffice it to say that it seems like we're spending a lot of
time messing with details that aren't of interest for the research. Now
C and Java are in my opinion almost the same
languages. I think the error
rate and nowadays also the speed is very close.
i might agree about the error rate, but speed
isn't even close, in my limited experience.
if you statically allocate all of your ram usage,
this *might* be closer to
22 matches
Mail list logo
