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
I think this is a no-brainer... After 18 years with C/C++, I'd say use Java
(or some other interpreted language) so you can focus on interesting stuff,
and later perhaps you can come back to optimize some portion using a static
compiled language (ie C++)...
Cavest: 2x slower than C++ might be a
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
A few points about Java and speed etc.
Java can rival C for speed, depending what you
do with it.
Unfortunately, really 'nicely' designed code
can be significantly slower than code written
specifically with efficiency in mind.
I accept that in principle one should aim for clean
and
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
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 ...
...
I am certain it is for 19x19. Just look at the KGS games of Mogo on
19x19. I played one game against it, and won. I got the feeling it was
slightly easier to beat than
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
How does monte carlo go do with fights that are trivial to evaluate, but
hard to search?
The attached position (I think from Martin Mueller), has many such fights.
If your program can count liberties correctly, it is easy to evaluate and
choose the best move with 1 ply lookahead. If you try to
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 11/30/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
To give an idea of the scale (at least for MoGo), 70k simulations/move (with
the best parameters) against gnugo 3.6/level 8 gives 89% in 9x9, 68% in
13x13, 32% in 19x19.
This is still not assessment of scalability. Each of those 70k
It's easy to construct problems that any program cannot
handle including
yours.
Of course, but understanding fights like the attached ones is essential to
strong play on 19x19.
You have to understand that Monte Carlo is not great at
tactics,
I do understand this. That's my
Are there any details, or publications, on what Mogo is doing at 19x19?
I'd thought consensus opinion here was that monte carlo scaled to 19x19
badly.
Darren
A very stupid question: What is Mogo, who has it written?
Chrilly
___
computer-go
21 matches
Mail list logo
