Just FYI:
Bots: e.21a e.21b e.21c e.21d on CGOS
are identical and make 100k light playouts per move. And have MCTS+RAVE.
Regards,
Lukasz Lew
___
computer-go mailing list
computer-go@computer-go.org
Why linux mogo downloaded here:
http://www.lri.fr/~gelly/mogo/MoGo_release3.tar.gz
when faced with version GTP command, returns
= MoGo release 1. Please read http://www.lri.fr/~gelly/MoGo.htm for
more information. That is NOT an official developpement MoGo version,
but it is a public release. Its
Hi,
Is there a way to set up MoGo so it has the same playing strength
independently of the CPU and other factors?
For instance fixing number of playouts per move?
The same question to Fuego developers.
Will I achieve this effect with this command?
uct_param_player max_games 10
Thanks,
It's not available online, but I will send it if someone ask me to.
(in private e-mail)
Lukasz
2009/10/13 Petr Baudis pa...@ucw.cz:
On Fri, Sep 25, 2009 at 11:51:21AM +0200, Łukasz Lew wrote:
I tried CRAVE in my master thesis 4 years ago. The context was a
growing decision tree.
It didn't
I tried CRAVE in my master thesis 4 years ago. The context was a
growing decision tree.
It didn't work as well.
Lukasz
On Fri, Sep 25, 2009 at 06:19, David Fotland fotl...@smart-games.com wrote:
Tried CRAVE also, using 3x3 patterns as the context. It didn't work.
David
-Original
On Wed, Sep 2, 2009 at 19:45, Matthew Woodcraftmatt...@woodcraft.me.uk wrote:
Łukasz Lew wrote:
If the weight in RAVE formula is near 1 in one child of tree and near
0 in other then you basically compare RAVE value to regular average
value, which might be comparing apples to oranges.
Yes
If the weight in RAVE formula is near 1 in one child of tree and near
0 in other then you basically compare RAVE value to regular average
value,
which might be comparing apples to oranges.
Have you ever tried to use the same weight for every move considered
(every child in the tree)?
Lukasz Lew
2009/8/24 René van de Veerdonk rene.vandeveerd...@gmail.com:
David,
Confession: I have not tested 19x19. As you have noted, and others before
you over the years, a 19x19 board does not fit in one but three 128-bit
registers and there would be a rather big penalty as a result, perhaps
In Havannah, there are not many bots. And, in the meantime
the programmers have marked their profiles accordingly.
Profiles don't help. On LG you just click register and you are paired.
Can you post a link to computer Havannah forum/thread? I was looking
for it on LG few weeks ago and
Try this link
http://www.littlegolem.net/jsp/games/gamedetail.jsp?gtid=havannah
(not sure if it works if you don't have an account).
Personally I'm really annoyed by many of these bots, because they do
not resign and play all possible forcing moves so
the games can be really long which is an
Hi Don,
Will a webpage change?
In particular, will we get access to archived games?
Lukasz
2009/6/22 Don Dailey dailey@gmail.com:
The new cgos server is almost ready - but needs some more polishing up.
I have an instance of it running while testing 50 programs using 3 different
the programs are run in parallel.
Christian
p.s. remember also http://cgos-python.sourceforge.net/, which does not have
this feature (yet!), but has others :)
nice. Thanks
On 17/06/2009 00:29, Łukasz Lew wrote:
Hi,
I have a couple of question about cgos client programs.
Why
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 would be a problem only for hardcoded bots with no time control.
The advantage would be that
FYI it tests only the processor, not the memory and is optimized for core2.
Ah, I don't prefer two sockets SMP computers since we will have hexa
and octa core chips soon (next year? I don't remember).
I agree.
Hideki
Łukasz Lew: c55009e70906060527i424cd3d9h525e8f87ec165...@mail.gmail.com:
Hi
independent)
105316/94359 (black wins / white wins),
Average of the middle 10 of 12 runs is 41.82533 kpps/GHz.
Raw data: 41.9898, 42.0318, 42.0503, 41.947, 40.6079, 41.7033,
42.0283, 41.8386, 41.5187, 41.8013, 41.9114, 41.4831
Hideki
Łukasz Lew: c55009e70906070309q4d6224e1s509c2d858ff7e
Nice to hear that :)
2009/6/5 Michael Williams michaelwilliam...@gmail.com:
Ł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
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 between
- core i7 2.66 GHz
- some core2 quad
both subjected to over-clocking.
Have you observed that Monte-Carlo Go program is faster on core i7
than on core2 ?
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 / Visits)
to
Thanks.
Lukasz
On Tue, May 26, 2009 at 22:15, Martin Mueller mmuel...@cs.ualberta.ca wrote:
Hello all,
I have uploaded a technical report, mainly with commented Fuego games from
Pamplona. Lukasz, it has the config settings in an appendix.
Fuego at the Computer Olympiad in Pamplona 2009: a
Libego has similar goal as fuego - to become universal platform for
experimenting with MC GO.
For a few days there has been talk about merging libego (mostly fast
board implementation) with fuego.
But I can't do it on my own.
Is there anybody interested in helping?
Lukasz Lew
It beat mogo in playoff.
Gratulations!
As fuego is opensource, you might be interested in it's playout policy:
http://www.cs.ualberta.ca/~games/go/fuego/fuego-doc/gouct-doc/GoUctPlayoutPolicy_8h-source.html#l00489
Lukasz
___
computer-go mailing list
Just a reminder that epsilon trick (invented by Jakub Pawlewicz) can
be used to avoid excessive memory usage (reuse memory) without
significant performance loss. It has been tested for proof number
search, but there is no reason for it to behave differently in MCTS.
Lukasz Lew
On Tue, May 12,
2009/5/5 elife elife2...@gmail.com:
For particular game, you can access it from url like
http://cgos.boardspace.net/9x9/SGF/2009/05/05/752908.sgf
But how can I know what is the id of the game of a particular pair of engines?
On Tue, May 5, 2009 at 8:42 PM, Łukasz Lew lukasz@gmail.com
from my iPhone
On May 5, 2009, at 8:42 AM, Łukasz Lew lukasz@gmail.com wrote:
But not as old as January archive, but for example from yesterday.
Can I get games of a cgos login?
Lukasz
___
computer-go mailing list
computer-go@computer-go.org
:42 AM, Łukasz Lew lukasz@gmail.com wrote:
But not as old as January archive, but for example from yesterday.
Can I get games of a cgos login?
Lukasz
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman
Hi,
Have any one of you tried uct + capture heuristic?
Is it stronger? How much?
Any one tried a variant (let's say local capture heuristic) where only
chains put into atari by last move are considered?
Any one tried pseudo-atari capture heuristic? I.e. only chains with
exactly one
2009/4/28 Mark Boon tesujisoftw...@gmail.com:
On Sun, Apr 26, 2009 at 11:54 PM, Łukasz Lew lukasz@gmail.com wrote:
Hi,
Have any one of you tried uct + capture heuristic?
Is it stronger? How much?
From memory I'd say it was winning about 80% against plain UCT. But
only capture
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 on core2
I'm curious about 4.4 as well.
g++-4.4 45 kpps/GHz
package gcc-snapshot on ubuntu
$ /usr/lib/gcc-snapshot/bin
/ 45000= 22,222 cycles per playout
On Apr 24, 2009, at 12:22 PM, Michael Williams michaelwilliam...@gmail.com
wrote:
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
On Thu, Apr 23, 2009 at 01:25, elife elife2...@gmail.com wrote:
On my Intel(R) Core(TM)2 Duo CPU T7200 @ 2.00GHz, using linux and
the exact compiler libego was tuned for, I get 70 kpps/GHz.
= 20 playouts in 2.85618 seconds
70.0236 kpps
-154.124 kpps/GHz (clock independent)
I found
This is because there is no getrusage function on windows, so I just
return (and divide) by 0.
I will try to fix it in next week.
Lukasz
On Thu, Apr 23, 2009 at 07:28, Petri Pitkanen
petri.t.pitka...@gmail.com wrote:
Because your time measurement has gone wrong. You get 0 seconds in
time hence
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 on core2
I'm curious about 4.4 as well.
Lukasz
PS
On Fri, Apr 24, 2009 at 01:29, Adrian Grajdeanu adria...@cox.net wrote:
I have two benchmarks:
On an: Intel(R) Core(TM)2 CPU T7200
: error: bad value (native) for -mtune= switch
Sorry for my ignorance.
Łukasz Lew wrote:
2009/4/21 Łukasz Lew lukasz@gmail.com:
mingw rules!
I compiled libego with it and got a decent 32kpps / GHz ( native g++
was 44kpps / GHz)
I used wine to run resulting exe on linux:)
Lukasz
On Tue, Apr 21, 2009 at 11:23, elife elife2...@gmail.com wrote:
I forgot about cygwin indeed. It is a good idea.
But can you ran the binary on a system without cygwin?
We can run the binary on a system without cygwin if we provide cygwin1.dll.
That is great.
Another good idea is mingw.
BTW
I
I like the idea very much.
But the coding effort is mostly in the GUI so it depends whether
gogui's (or other GUIS's) author will like the idea.
It has great commercial/popularity potential.
But it is not so important for research.
Lukasz
On Tue, Apr 21, 2009 at 07:35, Ingo Althöfer
On Tue, Apr 21, 2009 at 04:59, Jason House jason.james.ho...@gmail.com wrote:
I always recommend cygwin. I'm a linux guy and can't live without all my
little tools and simple package installation. You should be able to get the
exact gcc libego was optimized for that way.
I forgot about cygwin
since it's
64 bit.
- Don
On Tue, Apr 21, 2009 at 5:33 AM, Łukasz Lew lukasz@gmail.com wrote:
On Tue, Apr 21, 2009 at 11:23, elife elife2...@gmail.com wrote:
I forgot about cygwin indeed. It is a good idea.
But can you ran the binary on a system without cygwin?
We can run the binary
2009/4/21 Łukasz Lew lukasz@gmail.com:
mingw rules!
I compiled libego with it and got a decent 32kpps / GHz ( native g++
was 44kpps / GHz)
I used wine to run resulting exe on linux:)
Lukasz
2009/4/21 Don Dailey dailey@gmail.com:
I use mingw to produce cros platform executables
their code anyway. Don't know about
you, but I was impressed by 20% gain.
If you already use g++ 4.3, pardon my interruption. But if you don't, you
will be pleasantly surprised once you upgrade to it.
Adrian
Łukasz Lew wrote:
mingw rules!
I compiled libego with it and got a decent 32kpps
Rated: 1713 as of 2007-12-29 09:28:46
http://cgos.boardspace.net/9x9/cross/libEGO-v0.115-100k.html
I am running exactly the same binary file to check it recent rating.
ego-v0.115-100k
Lukasz
On Mon, Apr 20, 2009 at 20:16, Christoph Birk b...@ociw.edu wrote:
On Mon, 20 Apr 2009, ?ukasz Lew
that is correct.
2009/4/20 Don Dailey dailey@gmail.com:
That should be interesting.
So we have
1. ego-v0.115-100k
2. libEGO-v0.115-100k
Is that correct? We can watch it's bayelo rating as well as it's
incremental rating.
- Don
On Mon, Apr 20, 2009 at 3:13 PM, Łukasz
. libEGO-v0.115-100k
Is that correct? We can watch it's bayelo rating as well as it's
incremental rating.
- Don
On Mon, Apr 20, 2009 at 3:13 PM, Łukasz Lew lukasz@gmail.com wrote:
Rated: 1713 as of 2007-12-29 09:28:46
http://cgos.boardspace.net/9x9/cross/libEGO-v0.115-100k.html
From my expirience on windows, the best results I had with Intel C++ compiler
http://software.intel.com/en-us/articles/intel-c-compiler-professional-edition-for-windows-evaluation/
It had around 70%-90% of g++.
Lukasz
On Tue, Apr 21, 2009 at 03:18, Michael Williams
michaelwilliam...@gmail.com
I think it would be useful to have a list of existing important
heuristics / algorithms / ideas that improve Monte-Carlo Go.
If you are aware of any that are not on this list please add them.
Lukasz Lew
- MCTS / UCT
- capture/atari heuristics in heavy playouts / mogo patterns
On Sun, Apr 19, 2009 at 01:49, Łukasz Lew lukasz@gmail.com wrote:
I think it would be useful to have a list of existing important
heuristics / algorithms / ideas that improve Monte-Carlo Go.
If you are aware of any that are not on this list please add them.
Lukasz Lew
- MCTS / UCT
I might have back to revert to make/cmake (from scons) after all.
There is some hope in google software construction toolkit and in
scons on google summer of code.
In libego a lot have changed. Now ego is truely a library and is
compiled separately.
ego/ego.cpp is enough to compile library. Then
about this
block:
uint64 FastTimer::get_cc_time () volatile {
uint64 ret;
__asm__ __volatile__(rdtsc : =A (ret) : :);
return ret;
}
Łukasz Lew wrote:
I might have back to revert to make/cmake (from scons) after all.
There is some hope in google software construction toolkit
Can you give some more info about experimental setup and the
algorithms you used?
On Thu, Apr 9, 2009 at 01:42, w...@swcp.com wrote:
Lukasz,
My performance test suite did 7 ways of tracking liberties:
* dense linked lists, (where 4 * number of positions are allocated)
I guess this is what
There is plenty of info in documentation
http://www.scons.org/doc/production/HTML/scons-user.html
just search for Visual. I don't have VC++ so i can't help you :(
A wild guess would be to remove CXX and CXXFLAGS from SConstruct ...
maybe defaults will be good enough :)
Let me know if you get
On Wed, Apr 8, 2009 at 01:13, Darren Cook dar...@dcook.org wrote:
Linked lists have a terrible cache behaviour: every pointer (or index)
dereference has a nearly 100% chance of causing a cache miss.
...
It's quite easy and efficient to put all lists (cyclic, linked in one
direction) of
On Tue, Apr 7, 2009 at 23:52, Claus Reinke claus.rei...@talk21.com wrote:
Last time I looked more closely at what my MC bot (simple, no tree)
was doing, I noticed that it has a tendency to try the impossible moves
(suicides) first, discarding them as impossible for every genmove.
Looking at
On Wed, Apr 8, 2009 at 09:12, Darren Cook dar...@dcook.org wrote:
Do you have some code demonstrating the above idea? It sounds
interesting, but I cannot grasp what the data and algorithm look like.
4*19*19*4 is around 5.5 kB
On 9x9 it will be less than 1.5 kB
Are you still interested?
My
I'm just digging through tons of posts I didn't have time to read.
This one is particularly interesting for me.
Thanks for sharing this idea.
I don't have slow tactical reader, but it helps me to understand why
heavy playouts work while
direct optimization of strength of the playout doesn't help.
...
For a reference you can take a look for a libego implementation:
Ah, so you already use this idea in libego?
libego uses this idea only for list of stones in chain.
list of liberties are not implemented.
but I guess I will implement it sometime soon.
That is all I need to know,
On Wed, Apr 8, 2009 at 10:46, Darren Cook dar...@dcook.org wrote:
End game is another issue. MC programs only aim on winning, so they
endgame is nor perfect in sense human would define it, but perfect
enough to win if the game is winnable.
You can modify komi to get the human expert and MC
On Wed, Apr 8, 2009 at 13:10, Isaac Deutsch i...@gmx.ch wrote:
Hi Lukasz,
I think I understand the way it is done for storing the stones; I do it
exactly the same way.
For the liberties: Does the index of the direction (NWSE) state where the
chain is in respect to the liberty? So if you
On Wed, Apr 8, 2009 at 14:41, Jason House jason.james.ho...@gmail.com wrote:
On Apr 8, 2009, at 3:15 AM, Łukasz Lew lukasz@gmail.com wrote:
On Tue, Apr 7, 2009 at 23:52, Claus Reinke claus.rei...@talk21.com
wrote:
Last time I looked more closely at what my MC bot (simple, no tree
Ah, that's what you mean. :)
Actually I don't care too much about superko. I just care about the
move the genmove returns.
It would be better If I check at least some part of MCTS tree.
I just replay the game to check whether there is a hash collision. (I
use 64 bits)
If I would wan't fast
2009/4/8 Gunnar Farnebäck gun...@lysator.liu.se:
Łukasz Lew wrote:
...
For a reference you can take a look for a libego implementation:
Ah, so you already use this idea in libego?
libego uses this idea only for list of stones in chain.
list of liberties are not implemented.
but I guess I
Thanks. What about linked lists?
They seem to be both compact and fast to merge and detect duplicates.
Why have you abandoned them?
Lukasz
On Tue, Apr 7, 2009 at 17:42, David Fotland fotl...@smart-games.com wrote:
Yes, I walk both chains looking for duplicates. This is quite fast if done
Hi,
I was wondering what are the good (fast/accurate) ways of evaluating
program strength.
The most accurate one is to play many games against gnugo or on KGS.
But it is quite slow as many games are needed.
Another one is to have set of labeled positions (win/loss) and make
your program predict
Another idea is to try to predict moves in a set of (pro) games.
Is the prediction rate well correlated with program strength?
No, very poorly correlated. I think that's well known.
It is well known that systems created for pro move prediction using no
search like MoyoGo, similat Microsoft's
What other methods have you tried?
Lukasz
On Thu, Apr 2, 2009 at 17:14, w...@swcp.com wrote:
Isaac,
I implemented about 6 way to track liberties,
a couple years ago, and measured the running
performance, and by far the best is also the
simplest: keep an array of liberties for each
chain,
mercy rule in libego:
http://github.com/lukaszlew/libego/blob/77b4dd4e035e4b44c17204557c9930a52e10e0c0/ego/playout.h
line 55.
Regards,
Łukasz Lew
On Fri, Feb 27, 2009 at 01:00, Seth Pellegrino se...@lclark.edu wrote:
Hello list,
I've managed to track the idea of a mercy rule in monte-carlo
There might be no need for heavier playouts to be slower.
Sometimes they are even faster. (maybe it was in case of Crazy Stone?)
On Fri, Sep 5, 2008 at 18:43, Michael Williams
[EMAIL PROTECTED] wrote:
Has anyone tried heavy, slow playouts near the tree and light, fast playouts
near the end of
On Sat, Aug 2, 2008 at 16:06, Álvaro Begué [EMAIL PROTECTED] wrote:
On Sat, Aug 2, 2008 at 9:43 AM, Jason House [EMAIL PROTECTED] wrote:
On Aug 2, 2008, at 4:31 AM, Gunnar Farnebäck [EMAIL PROTECTED] wrote:
It's often a good idea to bias capturing moves in the playouts,
regardless whether
Can you describe your algorithms?
Cheers,
Lukasz
On Sat, Aug 2, 2008 at 19:36, Hideki Kato [EMAIL PROTECTED] wrote:
David Fotland: [EMAIL PROTECTED]:
I keep liberty counts.
Me too. Also is Hiroshi.
-Hideki
David
-Original Message-
From: [EMAIL PROTECTED] [mailto:computer-go-
The code of any version is easy to get:
http://www.mimuw.edu.pl/~lew/hg/libego/?tags
The file you are talking about is here:
http://www.mimuw.edu.pl/~lew/hg/libego/?file/dfcd0a6db96e/uct.cpp
If you take a look at line 151 you see: (bias should be renamed to
number_of_visits)
explore_coeff
Hi
New version of libEGO is available at :
http://www.mimuw.edu.pl/~lew/hg/libego/
The main improvements are:
- experiment.cpp file introduced which can now display ALL-AS-FIRST
move values through GoGui
(just connect libEGO to GoGui)
- new + option for benchmark GTP command (i.e. benchmark
This is an artifact of using mercy rule.
You can change it in config.cpp
use_mercy_rule = true
Should I make it default?
Thanks,
Lukasz
On Dec 10, 2007 11:41 PM, Heikki Levanto [EMAIL PROTECTED] wrote:
On Mon, Dec 10, 2007 at 04:08:48PM -0500, Don Dailey wrote:
Would you rather be 95%
Absolutely the best book I've seen is:
Christopher M. Bishop
Pattern Recognition and Machine Learning
It's totally awesome!
Strong points:
- It have both Bayesian and non Bayesian ways explained
- the explanation is clear
- figures are so helpful (and aesthetic)
- it concentrates on prediction
On 7/3/07, chrilly [EMAIL PROTECTED] wrote:
We just presented our paper describing MoGo's improvements at ICML,
and we thought we would pass on some of the feedback and corrections
we have received.
(http://www.machinelearning.org/proceedings/icml2007/papers/387.pdf)
They are
This is my analysis. It may be flawed but I hope it has some value.
It would be very interesting to see what mogo thinks on those variations.
Best Regards,
Lukasz
On 6/14/07, Sylvain Gelly [EMAIL PROTECTED] wrote:
Hello Sanghyeon, thank you for your comments.
After white (mogo) H2, MoGo
Please notice that it is not my work.
All the experiments were performed by Filip Gruszczynski.
He corrected the webpage. (should be EGO_POWER)
Best Regards,
Lukasz
On 5/30/07, Rémi Coulom [EMAIL PROTECTED] wrote:
Łukasz Lew wrote:
I'm not sure whether You have noticed, but my student made
noted that more complicated versions of BAST were worse.
On Wednesday 30 May 2007 21:05:15 Łukasz Lew wrote:
I'm not sure whether You have noticed, but my student made an
empirical comparison
between BAST, UCT and other formulas.
It can be found here:
http://students.mimuw.edu.pl
I'm not sure whether You have noticed, but my student made an
empirical comparison
between BAST, UCT and other formulas.
It can be found here:
http://students.mimuw.edu.pl/~fg219435/Go/
Best Regards,
Lukasz Lew
On 5/30/07, Remi Munos [EMAIL PROTECTED] wrote:
I have updated the BAST paper,
Hi,
I've tested many approaches, and the one I implemented is clearly the best.
The bias that Peter Drake talks about is negligible and doesn't have a
noticeable impact
on playout results.
(and uniformity of playout isn't something to fight for in MC Go)
Jason, can You tell me why You don't
My student - Filip Gruszczynski, made extensive testing of alternative
formulas for UCT.
Over 30 000 games; ~10 different algorithms with various constants
(including BAST).
http://students.mimuw.edu.pl/~fg219435/Go/
From the article:
It seems, that the more simple approach we take, the
Libego played at old CGOS with name sth like UCT-107-???k
100k was about 1550k
200k about 1650k
I don't remember and I can't find the rating list anymore.
Łukasz
On 4/14/07, Darren Cook [EMAIL PROTECTED] wrote:
I've been trying the libego program out of the box, and am up to
200,000 UCT
You can get it from ego library - file utils.cpp
Łukasz
On 3/29/07, Chris Fant [EMAIL PROTECTED] wrote:
Can someone please re-send that list of fast/small random number
generators? I can't seem to find it. Thanks.
___
computer-go mailing list
Hi,
On 3/17/07, Peter Christopher [EMAIL PROTECTED] wrote:
Hi LL or any others who know,
I've been playing with libego. Nice work, thanks for distributing it.
I am working on understanding some of the details of uct.cpp, in
particular how it does playouts in life-death and ko situations. I
On 3/2/07, Markus Enzenberger [EMAIL PROTECTED] wrote:
On Thu March 1 2007 05:22, Łukasz Lew wrote:
The most important thing is controller - engine architecture.
There are situations that engine would like to have the control. For
these requests come up once in a while, but IMO the clear
Hi,
There are some issues that are not so well defined in GTP v2.
Maybe GTP v3 should be released to avoid too much legacy later?
1.
The most important thing is controller - engine architecture.
There are situations that engine would like to have the control. For instance
When he want to send
The number of liberties is not the same measure as dimensionality.
You need to look at a area/boundary ratio.
At some point I adapted libEGO to hexagonal topology, and the game -
Hex Go ( Ho? :-) )
was actually very interesting. Major features are:
- almost no capture tactics
- no ko
- a lot of
/local/lib
It's a desktop and I don't see any options for power management.
Maybe it's just a difference in processors? It's a two core chip but
perhaps not as fast at single-threaded apps. Adding multithreading
might help.
- Brian
On 2/21/07, Łukasz Lew [EMAIL PROTECTED] wrote:
On 2/21/07, Brian
possible reasons for this:
- You are using a laptop with power management
- You changed Makefile or some source files to make it compile on Mac?
Best Regards,
Łukasz Lew
- Brian
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer
On 2/17/07, Luke Gustafson [EMAIL PROTECTED] wrote:
Lukasz, any chance you can access the assembly to see how the compiler
optimized it differently? That is a strange result. All that I could think
of is, if you have several places where the function is called, and the
compiler used to be
The library is just a bunch of code and You can do whatever You want with it.
I'm realistic, what matters is: what You have learned, does Your program works.
So just get the code and hack it as fast as You can to get some effect
asap, to feed Your motivation, to get more effect fast, etc...
On 2/13/07, Heikki Levanto [EMAIL PROTECTED] wrote:
On Sun, Feb 04, 2007 at 02:13:33PM +0100, ?ukasz Lew wrote:
Optimizing and refactoring became my hobby, but it's too absorbing :)
It's time to add some features now.
Just one question: Is the gtp support sufficient to play against other
them).
Have You performed an empirical test for collisions?
Best,
Łukasz Lew
Antoine.
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go
.
- Original Message
From: Łukasz Lew [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Monday, February 5, 2007 2:41:23 AM
Subject: Re: [computer-go] Effective Go Library v0.101
Effective Go Library:
http://www.mimuw.edu.pl/~lew
Hi,
EGB 0.101 is the last performance release:
50 kpps on 1.4 GHz and
80 kpps on 2.2 GHz.
Optimizing and refactoring became my hobby, but it's too absorbing :)
It's time to add some features now.
I consider 3 things:
- liberties tracing
- UCT tree search
- pattern tracing
Which feature You
On 2/4/07, Hideki Kato [EMAIL PROTECTED] wrote:
Łukasz Lew: [EMAIL PROTECTED]:
50 kpps on 1.4 GHz and
80 kpps on 2.2 GHz.
I'd like to add a sample in hand (10^6 playouts):
115 kpps on 3.0 GHz Intel Core2Duo (E6700/Conroe).
A pleasant number to look at ;)
And I have a question. Why Komi
On 2/5/07, Hideki Kato [EMAIL PROTECTED] wrote:
Łukasz Lew: [EMAIL PROTECTED]:
On 2/4/07, Hideki Kato [EMAIL PROTECTED] wrote:
Łukasz Lew: [EMAIL PROTECTED]:
50 kpps on 1.4 GHz and
80 kpps on 2.2 GHz.
I'd like to add a sample in hand (10^6 playouts):
115 kpps on 3.0 GHz Intel
Effective Go Library:
http://www.mimuw.edu.pl/~lew/
On 2/4/07, David Doshay [EMAIL PROTECTED] wrote:
UCT.
Cheers,
David
On 4, Feb 2007, at 5:13 AM, Łukasz Lew wrote:
It's time to add some features now.
I consider 3 things:
- liberties tracing
- UCT tree search
- pattern tracing
-28 at 23:49 +0100, Łukasz Lew wrote:
Try simple MC with all as first :)
I guess it beat any UCT totally.
( one playout here will be as 200-300 in UCT)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman
Try simple MC with all as first :)
I guess it beat any UCT totally.
( one playout here will be as 200-300 in UCT)
On 1/27/07, Don Dailey [EMAIL PROTECTED] wrote:
Below is the current results (in progress) of my
UCT 19x19 GO scalability study.
This is going to take a lot of time, but the
that can be set either way.
Cheers,
David
You are right, I will do something like that in next release.
Thanks
Lukasz
On 22, Jan 2007, at 2:01 PM, Łukasz Lew wrote:
On Cygwin, the results are ok and always the same.
I will add randomization of seed
++ is extremely rusty, so I used
win_cnt[0]=0;
win_cnt[1]=0;
There is probably a c++ specific idiom which I am unaware of.
Terry McIntyre
- Original Message
From: Łukasz Lew [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Tuesday, January 23, 2007 8:17:40 AM
Subject
Direct link:
http://www.mimuw.edu.pl/~lew/download.php?file_no=8
Łukasz
On 1/22/07, Łukasz Lew [EMAIL PROTECTED] wrote:
Hi,
Few interesting things has happened so I decided to announce new version:
- bug-fix: komi was too big (1 point) so program as white tended to
loose by 0.5 point
1 - 100 of 122 matches
Mail list logo
