Even though KGS is not open, you can still reverse engineer it, right? Why
not create an accessible web interface to KGS?
terry mcintyre wrote:
If accessibility is the only criterion, a client would do the trick;
it would need an open protocol.
It's been a bit of an inconvenience that KGS
Your point is obvious but that's a horrible proof since there are usually more
than one legal moves from which to chose (that means it takes more time).
steve uurtamo wrote:
As for other things we'd like to see improved, we could build a list. My pet
peeve is the KGS score estimator, which is
I'd like to read it, but that link doesn't work for me. Is it correct?
Brian Sheppard wrote:
I recommend the paper
http://hal.inria.fr/docs/00/36/97/83/PDF/ouvertures9x9.pdf by the Mogo team,
which describes how to use a grid to compute Mogo's opening book using
coevolution.
Brian
Never mind, the problem was on my side.
Michael Williams wrote:
I'd like to read it, but that link doesn't work for me. Is it correct?
Brian Sheppard wrote:
I recommend the paper
http://hal.inria.fr/docs/00/36/97/83/PDF/ouvertures9x9.pdf by the Mogo
team,
which describes how to use a grid
Can you tell us English speakers anything about it?
幼儿围棋 wrote:
Hi All,
GoChild is designed for learning how to play Go efficiently.
Web App - http://gochild2009.appspot.com
Official site - http://www.gochildgame.com
Regards,
gosharplite
Darren Cook wrote:
GoChild is designed for learning how to play Go efficiently.
Here is the English link for Michael :-)
http://www.gochildgame.com/en/index.htm
Thanks! I know how his wife feels -- I'm also still trying to figure out what
to do after Ko is created :/
Jacques,
It has been some time since you made this. Did you have to make changes to any of the original Fuego files? I'm asking because I'm trying to figure out what
would go wrong if I dumped current Fuego files into the Windows-buildable source that you provided.
Jacques Basaldúa wrote:
Very nice. Do you (or anyone) have the details of (Boon, 2009) concerning
arbitrarily shaped patterns?
Petr Baudis wrote:
Hello!
Today I held a presentation on the complete state of art in
Computer Go, showing hopefully all the current widely applicable
results, most successful
If you thought finding Go(game)-related stuff on the web was hard before...
Ben Shoemaker wrote:
Has anyone tried programming Go in the Go Programming Language?
http://golang.org/
___
computer-go mailing list
computer-go@computer-go.org
the output actually changed, it
would still be nice to see a few more lines and see the trend.
Thanks for helping ... debugging for someone else must not be the best
use of your time,
René
On Tue, Aug 25, 2009 at 8:03 PM, Michael Williams
michaelwilliam...@gmail.com mailto:michaelwilliam...@gmail.com
(AMD Phenom CPU)
Michael Williams wrote:
It came through fine the first time. Gmail probably hid the duplicate
text from you for convenience since it saw that it was text that you
already sent out. Or something.
I can compile the original (9x9) bitmap Go files in Windows 7 x64, but
when I
;
_BitScanForward (n, board.m128i_u32[m/4]);
return 8*m + n;
}
René
PS. x64 ... new playground, you could use __lzcnt64 ... so many things
to try!
On Tue, Aug 25, 2009 at 5:43 PM, Michael Williams
michaelwilliam...@gmail.com mailto:michaelwilliam...@gmail.com wrote:
(AMD Phenom CPU
really appreciate your help !
René
On Tue, Aug 25, 2009 at 6:38 PM, Michael Williams
michaelwilliam...@gmail.com mailto:michaelwilliam...@gmail.com wrote:
That doesn't seem to have any effect on the results.
René van de Veerdonk wrote:
Hi Micheal,
Thanks
, but it breaks my local copy). So, now I am positively
baffled.
Help?
René
On Tue, Aug 25, 2009 at 7:25 PM, Michael Williams
michaelwilliam...@gmail.com mailto:michaelwilliam...@gmail.com wrote:
Debug build:
testing _BitScanForward (m, 0): 0 842032512
testing _BitScanForward (m
If an engine (or an engine's playout policy) needs to check the legality of
every move before making a selection, this could still be a benefit.
René van de Veerdonk wrote:
David,
Confession: I have not tested 19x19. As you have noted, and others
before you over the years, a 19x19 board does
For many people on this list, Computer Go is a hobby and that means that it is important to do whatever you find interesting and motivating, event if it may not
be the best or most promising direction in order to become the next world champion program. There is room for pushing limits in all
no chance on 19x19 to do so.
Am 13.08.2009 um 05:14 schrieb Michael Williams:
After about the 5th reading, I'm concluding that this is an excellent
paper. Is anyone (besides the authors) doing research based on this?
There is a lot to do
After about the 5th reading, I'm concluding that this is an excellent paper.
Is anyone (besides the authors) doing research based on this? There is a lot
to do.
David Silver wrote:
Hi everyone,
Please find attached my ICML paper with Gerry Tesauro on automatically
learning a simulation
Very nice! Thank you.
Jacques Basaldúa wrote:
I have made a native Windows Fuego build compiled with MS Visual Studio
2008.
Thanks to the Fuego team for making such a nice program free software !!
I will use it to measure some tree metrics to tune my own program and
for a validation
Unpack to C:\ETC\Fuego in order for it to compile. Or modify the list of
include folders in the project configuration.
Jacques Basaldúa wrote:
I have made a native Windows Fuego build compiled with MS Visual Studio
2008.
Thanks to the Fuego team for making such a nice program free
Although I've never done a RAVE implementation (soon, very soon), this is
related in the sense that AMAF is related to RAVE:
I have recently (yesterday, actually) done some experiments on AMAF with 5-vertex patterns (normal AMAF can be considered 1-vertex patterns). I was not able to
observe
You should set the limit to whatever yields the highest ELO in YOUR program.
Harry Fearnley wrote:
Darren Cook wrote:
The largest nakade shape is the rabbity six. My wild guess would be to
outlaw self-atari for groups of 7+ stones.
The fun thing about computer go is how hard it is to make
If your weights are all between 0 and 1:
do
double r = rand(0 to 1)
int i = rand(0 to weightCount - 1)
until weight[i] r
I think that's right.
Mark Boon wrote:
When using patterns during the playout I had improvised some code to
select patterns randomly, but favour those with higher
file showing the dominant variations
with the number of wins and losses? It'd be interesting to see what the
bot considers to be the best sequences are...
Sent from my iPhone
On Jul 10, 2009, at 10:10 PM, Michael Williams
michaelwilliam...@gmail.com wrote:
Now that I have this system
The CGOS page should have a list of the GTP commands required by CGOS.
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Now that I have this system of generating really big game trees, what sort of interesting things could I do with it? The exact number of nodes I can store is
not exact because I'm doing various things to reduce each node's footprint when it goes to disk. I'm currently building a tree that is
So far, E5 and E6 are neck-and-neck for the favored opening move (E5 was leading almost the whole time until recently). The deepest part of the tree is 35 ply.
About 18% of run time is spent swapping to disk. 40% is traversing the tree. 14% is Libego.
Michael Williams wrote:
Now that I have
Prediction:
First, developers and algorithm gurus will expend huge amounts of effort to
parallelize code to take advantage of multi-core chips.
Then, hardware engineers and physics gurus will give us light-based CPUs and
orders of magnitude improvement in single-core performance.
That's the beauty of MC! It really is a beautiful system. Initially, they were totally random playouts. But the more powerful MC Go engines do not do
completely random playouts; they do heavy playouts. But if you were to look at a heavy playout, it would still look like a very weak Go
words, I would perform a mark-and-sweep garbage
collection.
Peter Drake
http://www.lclark.edu/~drake/
On Jul 6, 2009, at 8:02 PM, Michael Williams wrote:
If you are talking about 128k nodes, I don't think traversing them
will take very long
Suicide? Do you mean self-atari? But there must be more to it than that
because you don't have a rule that prevents all self-atari, right?
David Fotland wrote:
X can't fill J6 because that would be suicide. For the moment, H5 is an
eye.
David
-Original Message-
From:
Turn off Windows update or put the CGOS connect script in the startup folder
and set an automatic login.
David Fotland wrote:
I can have a reduced version of Many Faces up all the time on an old
computer, but I don't monitor it, so someone would have to email and remind
me when it goes down
Fuego gets an advantage because when it plays the anchor, it is playing a version of itself. That's bad for the same reason that it's bad to test against a
version of your own program -- inflated results. But I don't think it's a big deal. What about using both Fuego and Mogo as anchors?
If it were me, I'd run all anchor candidates against the current CGOS to
determine the anchor value to use for that anchor candidate.
Hideki Kato wrote:
I'm running Fatman1, GNU Go and GNU Go MC version for 9x9 and two
instances of GNU Go for 13x13, five programs in total, on a dual-core
I had never considered using AMAF with larger pattern. That's an interesting idea. Perhaps a 5-vertex cross-shaped pattern or a 3x3 pattern. Has anyone tried
this?
Magnus Persson wrote:
Probably 1x1 patterns implies that different priorities are assigned to
the absolute position of empty
for that position at
that node.
- Dave Hillis
-Original Message-
From: Michael Williams michaelwilliam...@gmail.com
To: computer-go computer-go@computer-go.org
Sent: Mon, Jun 22, 2009 3:02 pm
Subject: Re: [computer-go] 1x1 patterns?!
I had never considered using AMAF with larger pattern. That's
Are the games archived? Does the public have access to those archives?
Ingo Althöfer wrote:
Hello,
some time ago I had asked if discussions on
computer Havannah were welcome here in the list.
The reactions were positive, but (by different
reasons) actors preferred not to use the
Section 3.2 describes a pair of tests that took about 4.2 minutes each (if my calculations are correct). Why not play more games and have each game contain
more simulations? Writing the code and the paper is the hard part, waiting for a computer to run your code is easy.
Peter Drake wrote:
I vote for 2 venues, each optional. Separate rating pools is a must.
Łukasz Lew wrote:
Maybe we could agree that 1 day out of 7 in a week would be played on
6 times faster time controls.
The same bots, connections, logins, the same number of games per week.
Different rating of course.
This
i always buy at the low end because you get so much better of a deal. But I'd
guess the i7 is as excellent at Go as it is at everything else.
Łukwasz Lew wrote:
Hi
I have few days to buy a computer for Monte-carlo Go program.
There is not enough money for a multi processor, so I have to decide
Another strategy to be considered is to not allow the thinking to cease until the maximum win rate and the maximum visit count agree on the same move.
Obviously this requires some extra code to make sure you don't lose on time, etc.
Brian Sheppard wrote:
When a UCT search is completed, the
Łukasz Lew wrote:
On Wed, Jun 3, 2009 at 00:56, Michael Williams
michaelwilliam...@gmail.com wrote:
Two things: Firstly, I'm storing (only in RAM) the precalculated Winrate
and InvSqrtVisits and keeping them updated.
So my UCT formula went from
Wins / Visits + sqrt(lnParentVisits
Update: After concentrating on tightening the UCT loop, I've optimized myself
back into needing the SDD :/
But now I should be able to get to 20B nodes in just one day.
(still only doing 7x7 Go)
Michael Williams wrote:
Yes, when memory is full, I save and free all leaf nodes (which
I mean SSD.
Michael Williams wrote:
Update: After concentrating on tightening the UCT loop, I've optimized
myself back into needing the SDD :/
But now I should be able to get to 20B nodes in just one day.
(still only doing 7x7 Go)
Michael Williams wrote:
Yes, when memory is full, I save
. Anytime a proper UCT loop occurs, the likely-best reference is updated (about
90% of the time there is no change, so I think it's safe).
Jason House wrote:
That sounds like a good optimization. What did you do?
Sent from my iPhone
On Jun 2, 2009, at 3:16 PM, Michael Williams
michaelwilliam
Jason House wrote:
On Jun 2, 2009, at 6:56 PM, Michael Williams
michaelwilliam...@gmail.com wrote:
Two things: Firstly, I'm storing (only in RAM) the precalculated
Winrate and InvSqrtVisits and keeping them updated.
So my UCT formula went from
Wins / Visits + sqrt(lnParentVisits
I've optimized my disk access to the point where I'm mostly CPU limited now, even when using a standard hard disk instead of an SSD. I can now create trees of
up to about 30 billion nodes, which would take about a week. The simulation rate is continuously going down because so much time is
Yes, when memory is full, I save and free all leaf nodes (which is the vast
majority). Nodes are loaded as needed.
Don Dailey wrote:
On Mon, Jun 1, 2009 at 4:57 PM, Michael Williams
michaelwilliam...@gmail.com mailto:michaelwilliam...@gmail.com wrote:
I've optimized my disk access
Back in the days of Don's reference bot, I made some similar modifications to
them and posted the results (slight improvement). The postings were around
10/28/08.
Ingo Althöfer wrote:
Hello,
maybe this is old stuff for the insiders.
In my lecture today a clever student (Hagen Riedel)
MoGo was inspired by Crazy Stone? I've never heard that before.
Ian Osgood wrote:
On May 23, 2009, at 3:17 AM, Joshua Shriver wrote:
I know with the Chess community, it's looked down upon to use others
code w/ respect to competing in tournaments. I'm curious, how is it
with Go?
Even more
Cool idea.
Magnus Persson wrote:
Valkyria computes AMAF win rates for all moves including those that are
pruned or illegal in the position. What I noticed is that in cases of
critical semeais the AMAF values of moves that are for example illegal
can get very high since they only get legal
What was the consensus on 7x7 komi? It was discussed back during Don's
scalability study, but I couldn't find the number itself. Was it 9.0?
___
computer-go mailing list
computer-go@computer-go.org
Michael Williams wrote:
Ben Shoemaker wrote:
Success! I was able to build on WinXP using Scons and minGW (with
gcc4.3.3). Here's what (finally) worked for me:
1. Install Python 2.6.2
http://www.python.org/ftp/python/2.6.2/python-2.6.2.msi
2. Install minGW (using TDM's installer on empty
Ben Shoemaker wrote:
Success! I was able to build on WinXP using Scons and minGW (with gcc4.3.3).
Here's what (finally) worked for me:
1. Install Python 2.6.2
http://www.python.org/ftp/python/2.6.2/python-2.6.2.msi
2. Install minGW (using TDM's installer on empty minGW directory)
C# does. It should only take 30 bytes per node to store the information I need to have. But somehow that turns into 50 bytes. Byte alignment plus class
overhead, I guess.
Matthew Woodcraft wrote:
Michael Williams wrote:
I want to correct that last statement. With about 350M nodes
It's on my list of things to improve.
Michael Williams wrote:
C# does. It should only take 30 bytes per node to store the information
I need to have. But somehow that turns into 50 bytes. Byte alignment
plus class overhead, I guess.
Matthew Woodcraft wrote:
Michael Williams wrote:
I
-go.org] On Behalf Of Michael Williams
Sent: Thursday, May 14, 2009 7:08 AM
To: computer-go@computer-go.org
Subject: Re: [computer-go] Implications of a CPU vs Memory trend on MCTS
C# does. It should only take 30 bytes per node to store the information I
need to have. But somehow that turns
Plus, they are both made out of the same stuff so one would expect them to
scale at about the same rate.
Mark Boon wrote:
I'm a bit late reading this thread and the discussion seems to have
veered from the original topic a bit.
As to the CPU vs. memory discussion, it's not so clear-cut to me
bigger, but
probably not much.
Michael Williams wrote:
Those numbers are the average after the tree has grown to 1B nodes. I'm
sure the cache hates me. Each tree traversal will likely make several
reads from random locations in a 50 GB file.
Don Dailey wrote:
So you are saying that use disk
The Projects link (http://fuego.sourceforge.net/projects.html) on the Fuego
site (http://fuego.sourceforge.net/) is broken.
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
I have a trick ;)
I am currently creating MCTS trees of over a billion nodes on my 4GB machine.
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Don Dailey wrote:
On Tue, May 12, 2009 at 12:16 PM, Michael Williams
michaelwilliam...@gmail.com mailto:michaelwilliam...@gmail.com wrote:
I have a trick ;)
I am currently creating MCTS trees of over a billion nodes on my 4GB
machine.
Ok, I'll bite.What is your solution
wrote:
is the ssd fast enough to be practical?
s.
On Tue, May 12, 2009 at 12:41 PM, Michael Williams
michaelwilliam...@gmail.com wrote:
Don Dailey wrote:
On Tue, May 12, 2009 at 12:16 PM, Michael Williams
michaelwilliam...@gmail.com mailto:michaelwilliam...@gmail.com wrote:
I have a trick
if most of your reads and writes are
cached.What happens when your tree gets much bigger than available
memory?
- Don
On Tue, May 12, 2009 at 1:18 PM, Michael Williams
michaelwilliam...@gmail.com mailto:michaelwilliam...@gmail.com wrote:
In my system, I can retrieve the children
Beverley Robinson, 1897
*From:* Michael Williams michaelwilliam...@gmail.com
*To:* computer-go computer-go@computer-go.org
*Sent:* Tuesday, May 12, 2009 10:18:28 AM
*Subject:* Re: [computer-go] Implications of a CPU vs Memory trend
*From:* Michael Williams michaelwilliam...@gmail.com
*To:* computer-go computer-go@computer-go.org
*Sent:* Tuesday, May 12, 2009 1:09:41 PM
*Subject:* Re: [computer-go] Implications of a CPU vs Memory trend on MCTS
That's basically what I'm doing. Except
Where does your 99% figure come from?
Dave Dyer wrote:
Storing an opening book for the first 10 moves requires
331477745148242200 nodes. Even with some reduction for symmetry,
I don't see that much memory becoming available anytime soon, and you still
have to evaluate them somehow.
more than it did
other moves. I'm not saying keeping the tree is a huge benefit. I'm just saying that I don't think your 99% number is fair.
Dave Dyer wrote:
At 02:13 PM 5/12/2009, Michael Williams wrote:
Where does your 99% figure come from?
1/361 1%
by endgame there are still easily 100
When Mogo runs on the supercomputer with long-ish time limits, how big does the
search tree get?
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Does anyone know how to interpret the data at each node of a SGF created by the
Fuego command uct_savetree?
It looks like this:
MoveCount 35955
PosCount 35963
Mean 0.50
Rave:
D4 0.50 (31635.70)
B2 0.50 (27049.71)
C2 0.50 (28288.84)
D2 0.50 (29368.09)
E2 0.50 (27690.41)
F2 0.50 (27246.91)
G2
The Fuego documentation doesn't seem to contain any information about
command-line options (if there are any).
Ian Osgood wrote:
On May 8, 2009, at 11:57 AM, Ech Naton wrote:
Hello
I made a binary of Fuego 0.3.2 for Intel Mac. It is build on OS X 10.4.
So I don't know if it runs also
What is the meaning of the value returned by uct_score?
Martin Mueller wrote:
How do you set the number of threads that you want Fuego to use?
E.g. for 4 threads
uct_param_search number_threads 4
This can go e.g. in a config file, or you can set it in GoGui in the Uct
Param Search dialog.
white stones adjacent. Komi
of board is taken into account.
Michael Williams wrote:
What is the meaning of the value returned by uct_score?
Martin Mueller wrote:
How do you set the number of threads that you want Fuego to use?
E.g. for 4 threads
uct_param_search number_threads 4
I found an error in the documentation:
===
void GoUctCommands::CmdParamPlayer ( GtpCommand cmd )
===
Get and set GoUctPlayer parameters.
This command is compatible with the GoGui
After starting Fuego and issuing these commands:
boardsize 4
komi 1.5
book_clear
go_param timelimit 600
uct_param_search number_threads 1
go_param_rules ko_rule pos_superko
uct_param_search max_nodes 3000
reg_genmove_toplay
I get this result:
SgRandom::SetSeed: 1241728335
How do you set the number of threads that you want Fuego to use? Does the
windows version support multiple threads?
Michael Williams wrote:
Very nice. I do have one suggestion for Fuego. Make use of the ability
to filter certain root moves out of the UCT tree to remove symmetrically
Thanks. Yes, it works in Windows.
Martin Mueller wrote:
How do you set the number of threads that you want Fuego to use?
E.g. for 4 threads
uct_param_search number_threads 4
This can go e.g. in a config file, or you can set it in GoGui in the Uct
Param Search dialog.
You could also play
Is there a way to get Fuego to do a certain number of playouts per turn?
uct_param_search number_playouts N looked promising, but that is something
different I think.
Martin Mueller wrote:
How do you set the number of threads that you want Fuego to use?
E.g. for 4 threads
I found it right after sending that (of course):
uct_param_player max_games N
Michael Williams wrote:
Is there a way to get Fuego to do a certain number of playouts per turn?
uct_param_search number_playouts N looked promising, but that is
something different I think.
Martin Mueller
Very nice. I do have one suggestion for Fuego. Make use of the ability to filter certain root moves out of the UCT tree to remove symmetrically equivalent
moves. Or if it is not cost-prohibitive, throughout the tree.
Martin Mueller wrote:
Our technical report describing the Fuego framework
Michael Williams wrote:
See the April 30 2009 posting: http://www.tobiaspreis.de/
The CUDA SDK also comes with a sample called Monte-Carlo Option Pricing
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman
See the April 30 2009 posting: http://www.tobiaspreis.de/
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
I wish I was smart :(
David Silver wrote:
Hi Remi,
I understood this. What I find strange is that using -1/1 should be
equivalent to using 0/1, but your algorithm behaves differently: it
ignores lost games with 0/1, and uses them with -1/1.
Imagine you add a big constant to z. One
David Silver wrote:
Hi Michael,
But one thing confuses me: You are using the value from Fuego's 10k
simulations as an approximation of the actual value of the position.
But isn't the actual
value of the position either a win or a loss? On such small boards,
can't you assume that Fuego is
I will ignore Magnus's comments about AMAF while I respond directly to your
comments.
If you do one or two simulations from a leaf node and they happen to result in losses, you would never simulate that node again? And never expand it into it's
child nodes? It is very possible that the
Finally! I guess you can add this technique to your list, Lukasz.
David Silver wrote:
Hi everyone,
Please find attached my ICML paper with Gerry Tesauro on automatically
learning a simulation policy for Monte-Carlo Go. Our preliminary results
show a 200+ Elo improvement over previous
My favorite part:
One natural idea is to use the learned simulation policy in Monte-Carlo search, and
generate new deep search values, in an iterative cycle.
But one thing confuses me: You are using the value from Fuego's 10k simulations as an approximation of the actual value of the position.
According to my math, that comes out to around 205 cycles per playout move.
Pretty damn good, I'd say.
Łukasz Lew wrote:
On Fri, Apr 24, 2009 at 01:52, Łukasz Lew lukasz@gmail.com wrote:
I get
g++-4.1 35 kpps/GHz
g++-4.2 45 kpps/GHz
g++-4.3 40 kpps/GHz
I'm happy it's quite consistent
= switch
When using i686, it did not complain, and I get these results:
23.0972 kpps/GHz
Łukasz Lew wrote:
2009/4/22 Michael Williams michaelwilliam...@gmail.com:
This worked for me:
C:\Libego\lukaszlew-libego-476a46885f80e1f4d83494bb632398b3974e901bg++ -o
engine.exe ego/ego.cpp example/main.cpp
Lew wrote:
2009/4/22 Michael Williams michaelwilliam...@gmail.com:
This worked for me:
C:\Libego\lukaszlew-libego-476a46885f80e1f4d83494bb632398b3974e901bg++ -o
engine.exe ego/ego.cpp example/main.cpp -O3 -Iego -fomit-frame-pointer
-ffast-math -frename-registers
(I removed the -march switch
Here is my full set of numbers. I wonder why the known kpps/GHz but unknown
kpps.
= Benchmarking, please wait ...
= 20 playouts in 0 seconds
1.#INF kpps
40.0245 kpps/GHz (clock independent)
105316/94359 (black wins / white wins)
= 20 playouts in 0 seconds
1.#INF kpps
40.0721
Mention the program so that the author can either refute your claim or fix the
bug.
terry mcintyre wrote:
Is it reasonable to expect pro players to use 6-dan programs as a tool
for analysis? The pro players are markedly better - at a rough guess, a
pro player could give a 6 dan amateur human
Ok, I have Mingw installed now. That sounds like the way to go. But I still
don't know how to compile it :/
According to the SConstruct file, I should be doing something like this to
build, but it complains:
C:\Libego g++ /Fobuild\ego\dbg\ego.obj /c ego\ego.cpp -DDEBUG -ggdb3 -Wall
I got Libego compiled to a Windows DLL using Visual Studio and was able to call it, but I was only getting around 5k pps on my Core2. So I wanted to try
another compiler. Has anyone used the Digital Mars C++ compiler? Or is there another compiler I should try?
You can change the value all you want. You just can't change the key.
Jason House wrote:
On Apr 14, 2009, at 7:57 PM, Rémi Coulom remi.cou...@univ-lille3.fr
wrote:
Jason House wrote:
Out of curiosity, how do you intelligently delete old nodes?
Reference counting won't always work due to
I think your hash value is your first-try index into the hash table. So a 32-bit hash would be a 4E9 sized table. Probably too big for Remi's computer. I'd
guess that he's using something between 16 and 32 bits in his hash hey.
Jason House wrote:
On Apr 15, 2009, at 6:50 PM, Michael
What tricks are people doing to minimize the performance degradation due to multiple threads contending for access to the tree (in MCTS)? Do you only lock a
portion of the tree? How would that work?
___
computer-go mailing list
details, I can try to get you sample code for Mac OS X or
Linux (both on x86).
Álvaro.
On Mon, Apr 13, 2009 at 6:08 PM, Rémi Coulom remi.cou...@univ-lille3.fr wrote:
Michael Williams wrote:
What tricks are people doing to minimize the performance degradation due
to multiple threads contending
no. just don't prune the tree. or allow unpruning.
compgo...@aol.com wrote:
Following is a description of the nature and process of the UCT-MC method.
For a given Go board position P, let Np denote the total number of all
possble end of game positions. Let Ei denote each of the end of game
If I have only that file in the project, and fix some header includes, I am
left with many errors still. The first few are complaining about this block:
uint64 FastTimer::get_cc_time () volatile {
uint64 ret;
__asm__ __volatile__(rdtsc : =A (ret) : :);
return ret;
}
Łukasz Lew wrote:
1 - 100 of 249 matches
Mail list logo
