My current plan is to tackle directly the power of x86-64bits architecture.
Because it's now quite well represented. And there is this "larrabee" project
that may get out in one or two years (48 x86-64bits processors). So my true
goal is to try and see what i can do with my quad Q9300 2.5Ghz
hi.
I have put a lot of though in that Hex bot stuff. I realize now how eager i am
to try my ideas with an Hex bot. It's been a long time since i first realize
how much more elegant it would be to try those ideas for the Hex game anyway.
Your site seems a great source of interest for that gam
At 01:52 AM 11/27/2008, Denis fidaali wrote:
...
> But what really lacks (or i wasn't able to find anyway) is a strong community
> like there is for go.
>
> A CGOS equivalent.
> A GTP equivalent.
> A Gogui equivalent.
> A Kgs equivalent.
I don't think there's a match between your goals and what
Hopefully you will be proved wrong by the end of January 2009.
I don't feel like i should involve anyone in this before a working prototype is
out. Your skepticism is probably statistically correct, so we'll resume this
conversation in two month. If my algorithm doesn't work indeed, i'll certa
Permit me to play the skeptic here; I think you're going about it absolutely
backwards - unless you already have a strong algorithm which depends on 128 bit
rotations, and only lack an efficient hardware engine to run it on.
If your idea of fun is to really feel the bits squishing between your
On Thu, 2008-11-27 at 02:05 -0800, Dave Dyer wrote:
> At 01:52 AM 11/27/2008, Denis fidaali wrote:
>
> ...
> > But what really lacks (or i wasn't able to find anyway) is a strong
> > community like there is for go.
> >
> > A CGOS equivalent.
> > A GTP equivalent.
> > A Gogui equivalent.
> > A Kgs
Denis,
A CGOS equivalent for Hex would probably be good to have. But since
the CGOS server software is open-source you can easily adapt it.
GTP you can simply use as-is, I don't see why that wouldn't work.
GoGui is also open-source and can possibly also be easily adapted to
Hex as well. But
Dave Dyer wrote:
At 01:52 AM 11/27/2008, Denis fidaali wrote:
...
But what really lacks (or i wasn't able to find anyway) is a strong community
like there is for go.
A CGOS equivalent.
A GTP equivalent.
A Gogui equivalent.
A Kgs equivalent.
I don't think there's a match between you
Thanks all for your support and suggestion.
I'll let you know if i happen to get any success.
> Date: Thu, 27 Nov 2008 16:08:24 +0100
> From: [EMAIL PROTECTED]
> To: computer-go@computer-go.org
> Subject: Re: [computer-go] Re: hex robot
>
> Dave Dyer wrote:
> > At 01:52 AM 11/27/2008, Denis
On Thu, 2008-11-27 at 13:03 -0200, Mark Boon wrote:
> You say you're going to try to make a prototype first and then when it
> shows promise, move to a more flexible language like Java. What
> language are you intending to use? It seems the wrong way around to
> me. Develop the prototype in a flexi
I have to agree with Don. This year I went from knowing nothing about Monte
Carlo and UCT to world champion. I tried more than 400 variations on the
basic UCT algorithm or playout strategy during 6 months of intensive
development. The engine is written in C and tuned from the start for
performan
don,
i agree, although i will point out one of C's biggest flaws, which
happens (conveniently for the sake of this argument) to be its
least important one for game programming:
string handling sucks
if i never have to handle a string, i'll choose C without question.
when i need to handle strings
Don,
I'm not going to argue about the merits of Java or C++ as it won't
change anyone's point of view anyway.
What you're arguing is you should use C/C++, period. Fine by me if
that's what you think is best.
But that's not what Denis was saying. He didn't specify he'd start
with C/C++,
On Thu, 2008-11-27 at 12:59 -0500, steve uurtamo wrote:
> don,
>
> i agree, although i will point out one of C's biggest flaws, which
> happens (conveniently for the sake of this argument) to be its
> least important one for game programming:
>
> string handling sucks
>
> if i never have to hand
On Thu, 2008-11-27 at 16:22 -0200, Mark Boon wrote:
> Don,
>
> I'm not going to argue about the merits of Java or C++ as it won't
> change anyone's point of view anyway.
>
> What you're arguing is you should use C/C++, period. Fine by me if
> that's what you think is best.
>
> But that's not
I have added a MCTS implementation to my reference-bot project. It
allows you to specify how many nodes to search, after how many nodes
to expand and whether to use AMAF or not. If you specify the number
of nodes before expansion to be the same as the total number of nodes
to search and set
So, you use AMAF for "simulating" the first UCT evaluations ?
I though the classical way to use AMAF, was to affect only the
win/lose ratio portion of the uct equation.
Obvioulsy it should be allowed to use an arbitrary
large number of AMAF simulation accumulating them longer
than what it take to
>The use of C is almost the only choice, but I'm on the lookout for the
>next wave of languages that will be:
> 1. Native code compiled - no external runtime required.
> 2. High level language features, but not imposed on you.
Have a look at Haskell (www.haskell.org). I don't want to get int
On 27-nov-08, at 19:50, Denis fidaali wrote:
So, you use AMAF for "simulating" the first UCT evaluations ?
I though the classical way to use AMAF, was to affect only the
win/lose ratio portion of the uct equation.
Obvioulsy it should be allowed to use an arbitrary
large number of AMAF simulatio
19 matches
Mail list logo
