Hi
Le 11/02/2010 à 10:32, Le Hir Matthieu a écrit :
Hi,
From what I think I understood, dynamic komi is supposed to try to keep the
game more even.
The dynamic komi is a bias in the evaluation in order to inform the bot
that the game is balanced, and prevent it beeing blinded by the
Le 18/01/2010 à 10:54, Petr Baudis a écrit :
it would be great to share other information like LD
and semeai critical moves; perhaps GNUGo even provides interface to get
these as well.
yes, via gtp
you can easyly see in gogui :-), and maybe more with gnugo tool (regress.pike ?)
Alain
Le 18/01/2010 à 18:37, terry mcintyre a écrit :
My pet peeve is the KGS score estimator, which is often wildly wrong.
The best thing to do would be to remove the score estimator which
prevent people from thinking.
I bet there would be much less stupid chat during games whithout it :)
Alain.
Le 04/01/2010 à 14:19, Nick Wedd a écrit :
I have discussed these extra events in the past, and received feedback
here; which, unfortunately, I have forgotten. So please, anyone who is
interested, make your suggestions now.
As a spectator i would like an Hanh tournament on 19x19, not too
Le 04/01/2010 à 18:09, Petr Baudis a écrit :
I don't think Hahn tournament would be that interesting,
As a physicist i like to experiment first, and think later,
to understand what happened, which obviously was not foreseen ;-)
I believe it will reveal some hidden aspect of the stronger engines,
Le 06/12/2009 à 01:05, Darren Cook a écrit :
You also need to set max_nodes quite high or Fuego will keep stopping to
clear out its tree. I'm setting it to max_games*50, so for 8000:
uct_param_search max_nodes 40
According to my notes fuego uses 75M + (65M per million max_nodes). So
Le 26/11/2009 à 10:08, Vlad Dumitrescu a écrit :
On Thu, Nov 26, 2009 at 00:43, Darren Cook dar...@dcook.org wrote:
When I read this it reminded me of experiments I tried before to pass
more than one piece of information up from the leaf nodes of a (min-max)
tree. E.g. a territory
Le 25/11/2009 à 12:39, Vlad Dumitrescu a écrit :
On Wed, Nov 25, 2009 at 12:04, Nick Wedd n...@maproom.co.uk wrote:
A program to play Hahn Go has no
reason to calculate probabilities, it should just make the biggest move it
can.
Ah, okay, now I understand your point of view. Thanks for
Le 25/11/2009 à 15:11, Vlad Dumitrescu a écrit :
What I am considering is a way to analyze a list of moves, each having
in turn a value that is a list of expected outcomes and their
respective estimated probabilities, and to sort the moves by the
expected outcome in the context of a given risk
Le 24/11/2009 à 00:24, dhillism...@netscape.net a écrit :
For my fast/dumb neural net engine, Antbot9x9, I coevolved the weights using
a similar tournament system. Each individual played a number of games against
all the others, round robin, and the score was the sum of points for all of
A Go tounrmaent with Hahn system has been retransmeted on kgs/eurogo TV
With these rules, the actual count makes a difference (as opposed to just
win/lose)
Winning by 40.5gets 100 points
......
Losing by 40.5gets 0 point
Le 19/11/2009 à 09:35, Seth Pellegrino a écrit :
Hello all,
I'm working on an implementation of Rémi Coulom's Elo-based move
prediction algorithm[1], and I seem to be running into efficiency
issues.
Very simple question to start:
What is the programmation language ?
Do you use 1d
Le 19/11/2009 à 13:10, Mark Boon a écrit :
On Nov 19, 2009, at 1:24 AM, Nick Wedd wrote:
So a bot which appears on KGS, gets rated as 25k, plays hundreds of
games, and then improves to 15k, is going to do a lot of damage to
the rating system.
What happens when all those beginners
Le 10/11/2009 à 15:56, Stefan Kaitschick a écrit :
Ofcourse I can't say what a correct opening is.
What I can say though, is that if bots are onto something with their strange
openings, at this point it's by accident.
It is not by accident, it is consistent with what the bot can read.
They
Le 09/11/2009 à 08:04, Jessica Mullins a écrit :
Hi,
I am wondering what is the best way to build a Joseki Book? I am a student at
Lewis Clark College and am working with Professor Peter Drake to build a
Joseki Book for the program Orego.
Right now I am extracting moves from professor
Le 23/07/2009 à 09:21, Ingo Althöfer a écrit :
.../...
Therefore I really like the test series by Yamato (with 30 out of
100 wins for Zen against mirror strategy)
Can we assume that both programs are approximately equal or is MFGO
clearly stronger (or visa versa?)
In normal go (on
Le 20/07/2009 à 15:34, Don Dailey a écrit :
Again, I don't understand go so well, but how do you win against mirror
go?
It seems you must either take advantage somehow of the non-symmetry of the
center point OR take advantage of the fact that a capture could break the
symmetry. Is that
Le 20/07/2009 à 16:01, Don Dailey a écrit :
Ok, so I am right about this, you take advantage of the asymmetry of
captures.
But go programs do not KNOW they are playing mirror go
GNU Go knows if the game is mirror-go or not, and decide to break
it when a sufficent number of moves is reached
Le 16/07/2009 à 22:28, Peter Drake a écrit :
I've recently been getting an odd distorted buzzing with every sound
played by CGoban3, the KGS client. This doesn't happen with other
applications, so I don't think it's a hardware or driver problem.
Has anyone else encountered this?
Peter
Le 08/04/2009 à 07:28, Petri Pitkanen a écrit :
This is nice idea and this is to a degree what GnuGo regression test
does.
afaik, gnugo testsuite (based on a previous one) is not totally suitable
for MC programs, as some position are dead lost / clear win but shows
gg misbehavior.
Some
Le jeudi 8 janvier 2009, Nuno Milheiro a écrit :
It seems normal to me, Blac is only one play ahead, which value is several
points (probably 7,5 hence the komi value) given intelligent play, given
random play the value of one more move may be only one point.
You should try with more komi
Le samedi 2 août 2008, Christoph Birk a écrit :
On Aug 2, 2008, at 10:34 AM, Don Dailey wrote:
Does it make sense to use a komi of 7.5 for 13x13 and 19x19 under CGOS
rules?
I don't know about 13x13, but for 19x19 you should use 6.5.
Is'nt the komi 6.5 with japanese rules = 7.5 with
Le mardi 8 avril 2008, Dave Dyer a écrit :
By the way, has anyone seen the Philip Morris commercials?
I believe they were forced into this as part of the extortion
by the state attorneys general. It's Penance for illegally
targeting young non-smokers with Joe Camel, and promoting
Le vendredi 1 février 2008, David Doshay a écrit :
This is the direction in which we are moving with SlugGo. We also
expect it to be difficult to integrate different approaches, but this
has always been our research direction: when there are multiple
codes which will each give an evaluation of
Le vendredi 7 mars 2008, Petr Baudis a écrit :
This has nothing to do with black/white distinction. The idea is to
dynamically adjust the komi to make UCT to aim at higher and potentially
less sure win or lower and potentially more sure loss. Of course,
depending on whether it takes black or
Hi
On http://cgos.boardspace.net/study/13/index.html we read :
a reference point, a popular program in the public domain called Gnugo
It is open source and libre program GPL, but not public domain.
Alain
___
computer-go mailing list
Le jeudi 21 février 2008, Don Dailey a écrit :
If you look at the table you will notice that going from level 4 to
level 11 (which is 7 doublings and should take 128X longer) only takes
59.43 X longer.
So if we plot 9X9 rank vs time, maybe we have a straight line :)
ELO vs size of the tree
Le vendredi 22 février 2008, Sylvain Gelly a écrit :
2008/2/22, Alain Baeckeroot [EMAIL PROTECTED]:
Le jeudi 21 février 2008, Don Dailey a écrit :
If you look at the table you will notice that going from level 4 to
level 11 (which is 7 doublings and should take 128X longer) only takes
Le jeudi 21 février 2008, Don Dailey a écrit :
The study is running very well. We have 32 computers being used so
far, some participants are providing 2 (or even more) computers.
It would be great to get even more as we get into higher levels, as it
will take a LOT of power to get a
Le lundi 18 février 2008, Michael Williams a écrit :
But as was pointed out before, these high levels of MoGo are probably still
not pro level, right?
On 9x9 Big_slow_Mogo is near pro level, maybe more.
6 monthes ago or so it was able to regurlarly beat pro without komi on 9x9.
Alain
Le mercredi 13 février 2008, Florian Erhardt a écrit :
If anyone knows where I could get SIMPLE docs explaining optimizations
for vector cpus, that would be great.
Some basic advices and links.
Read Linux Coding Style, especially section concerning indentation and
functions.
Draw the flow
Le mardi 12 février 2008, David Schneider-Joseph a écrit :
On Feb 11, 2008, at 8:42 PM, Don Dailey wrote:
David Schneider-Joseph wrote:
By definition,
komi is proportional to the value of moving first. Likewise, by
definition, your skill is the amount of value you get out of a move.
Le vendredi 8 février 2008, terry mcintyre a écrit :
Probably true, but I am already running into RAM
limits with big_Mogo18 - had to halve the number of
instances of the autotest program, and am installing
RAM in the next few days to alleviate this problem.
There is also the time-per-game,
Le samedi 2 février 2008, terry mcintyre a écrit :
Apologies for not quoting Don Dailey's text on Borda voting --
yahoo is doing something truly awful with quoted text, for some reason.
It also break mail-thread, putting your post in uncorelated thread.
Maybe switch to another mail ? ;-)
Le samedi 2 février 2008, Christoph Birk a écrit :
On Sat, 2 Feb 2008, Alain Baeckeroot wrote:
1800 is gnugo, so this puts top programs near 1k (2d for extreme
mogo_18) this seems reasonable to me.
Are you confusing 19x19 and 9x9?
The ELO/KGS table is for 19x19, while mogo_18 plays 9x9
Le vendredi 1 février 2008, David Doshay a écrit :
This is the direction in which we are moving with SlugGo. We also
expect it to be difficult to integrate different approaches, but this
has always been our research direction: when there are multiple
codes which will each give an evaluation of
Le vendredi 1 février 2008, Andy a écrit :
See below I created a table that shows the transformation from KGS ratings
to the Elo that CGOS uses. I set 6k=1800 because I believe that is what GNU
3.7.10 is under both systems. Does anyone have more data points for bots
that play on both
Le vendredi 1 février 2008, terry mcintyre a écrit :
Regarding the scalability study,
...
I'm very curious about that flat spot for
Mogo-16, 17, and 18. ( http://cgos.boardspace.net/study/index.html )
I think its just lack of data
Mogo_16 = 2958+47 / -45
Le mercredi 30 janvier 2008, David Fotland a écrit :
3 kyu at this level is a lot for a person. I've know club players who never
got better than 9k, and people who study and play may still take a year or
more to make this much improvement.
Many club players stall somewhere between 7k and 4k
Le mercredi 30 janvier 2008, Don Dailey a écrit :
I must not understand the problem. My program has no trouble with
nakade unless you are talking about some special case position.My
program immediately places the stone on the magic square to protect it's
2 eyes.I can't believe mogo
Le jeudi 24 janvier 2008, Don Dailey a écrit :
Hi Hideki,
No need to stop any of the weaker games since 99% of the compute time is
consumed by the strongest half.
Also, only the new mogo's will be scheduled to play until they catch up
- however their opponent will almost always be the
Hello
http://www.theregister.co.uk/2008/01/18/fischer_dead/
Alain.
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Le mercredi 23 janvier 2008, ivan dubois a écrit :
Hi Alain,
Sorry for being so insistant :
You should browse the archive of the list, nearly the same discussion about
infinite and scalability happenned in 2007.
No i just said that, unless i really understood nothing, i read here from
Le mardi 22 janvier 2008, Olivier Teytaud a écrit :
Have you selected the room with bot's name as a member?
Yes. Seemingly only public rooms are possible for bots.
I'm interested in if someone has a solution for private rooms.
I know that Aloril is running one mogobot clone in my go
Le mardi 22 janvier 2008, Michael Williams a écrit :
... perhaps only uniformly random playouts
will scale to perfection.
The reason that MC/UCT scales to perfection is because of the UCT part,
not the MC (playout) part. People seems to forget this a lot.
I agree on this _only_ if the
Le mardi 22 janvier 2008, David Fotland a écrit :
The UCT-MC programs do particularly well against traditional programs
because they expose the brittleness inherent in the pattern databases they
use. Strong humans are not so easily beaten by playing unconventional and
somewhat inferior
Le mardi 22 janvier 2008, Mark Boon a écrit :
On 22-jan-08, at 11:33, Magnus Persson wrote:
So feel free to argue that 19x19 has properties that are unique,
but in doing so please *specify* exactly what this means and why a
computer program has to deal with it to play really strong.
Le mardi 22 janvier 2008, Peter Drake a écrit :
The license for Orego is GPL: basically, you can do whatever you want
with it, but don't sell it, claim our stuff is your invention, or try
to prevent anyone else from using it.
You can sell GPL, but you can't prevent the owner to
Le mardi 22 janvier 2008, [EMAIL PROTECTED] a écrit :
Infinite scalability is a theoricaly proved property, so please
don't feed the troll :-)
Are you saying that the scalability is linear between number of playouts and
ranking?
No i just said that, unless i really understood nothing, i
Le lundi 21 janvier 2008, Olivier Teytaud a écrit :
I am trying to connect a bot to a KGS private room.
If we set computer-go as the room, the bot comes and plays against
its opponents.
But if we set the name of the room, the bot comes and can be seen in the
room, but does not play.
Le samedi 19 janvier 2008, Don Dailey a écrit :
The new scalability study is in progress. It will be very slow going,
only a few games a day can be played but we are trying to get more
computers utilized.
I will update the data a few times a day for all to see. This includes
a
Le jeudi 17 janvier 2008, Don Dailey a écrit :
Perfect! I will adjust the level so that it plays as strong as
possible on CGOS without taking a risk of getting into time trouble on
modest hardware. Then I can make Mogo the anchor player.
Even if i love Mogo, and i am very impressed,
Le dimanche 13 janvier 2008, terry mcintyre a écrit :
From: Rémi Coulom [EMAIL PROTECTED]
Sylvain Gelly wrote:
Yes I did! :).It is not on my website, but will (soon?).
However, you should not be so eager to read it :)
Cheers,
Sylvain
Google finds it:
Le jeudi 10 janvier 2008, Olivier Teytaud a écrit :
They announce that a match will be organized between MoGo and a
professional
player in March, during the Paris Go Tournament.
It will be the
MPI version of mogo, and
in various board-sizes.
What will be the hardware for Mogo ?
Le mardi 8 janvier 2008, terry mcintyre a écrit :
- Original Message
From: Stuart A. Yeates [EMAIL PROTECTED]
I recommend Mathematical Go: Chilling Gets the Last Point by Elwyn
Berlekamp and David Wolfe. The book contains a number of such
positions, as well as an approach that
Le mardi 8 janvier 2008, Don Dailey a écrit :
...
On 19x19 it might be 30 minutes per side like we have now, with 5
minute games for the fast time control.We would probably have to
work it out so that program like gnugo would be able to handle the fast
time control at their standard
Le mardi 18 décembre 2007, Harald Korneliussen a écrit :
Some thinking out loud here on the topic of languages and efficiency:
I'd like to know how well MoGo would have played if you let it think
for a week for every move. Only it seems to me that is not possible,
because I don't think MoGo
Le mercredi 12 décembre 2007, Ben Lambrechts a écrit :
How do AGA ratings compare to KGS?
Sensei's Library is your friend ;o)
http://senseis.xmp.net/?RankWorldwideComparison
I believe this page has not been updated since last year change
on kgs ranking scale.
Kgs have the big advantage
Le mercredi 12 décembre 2007, Harri Salakoski a écrit :
Such comment just take my word back little it is maybe awesome but I can't
say is it or not, as have still bugs left.
E E E
E E E
BEE
WWWEBEE
E E EWBEE
E E WEBEE
ABCDEFG
For example current version(not released) goes
Le jeudi 6 décembre 2007, Don Dailey a écrit :
Lavergne Thomas wrote:
If some bot can be setup to play on kgs for enough time to get a solid
rank and then put on cgos to get an elo rating with the same
configuration we could find a formula to convert elo to kgs ranks.
For sure, this is
/ with and interesting observation
in the end.
Alain.
However, this data should still be quite useful.
- Don
Alain Baeckeroot wrote:
Le mardi 4 décembre 2007, Don Dailey a écrit :
For 9x9 ELO works better. For 19x19 it's less clear cut.The
handicap system appears to be a good system
Le mardi 4 décembre 2007, Christoph Birk a écrit :
On Tue, 4 Dec 2007, Alain Baeckeroot wrote:
For 9x9 ELO works better. For 19x19 it's less clear cut.The
handicap system appears to be a good system at 19x19 and has the very
nice merit of allowing grossly mismatched players
Le dimanche 11 novembre 2007, Stuart A. Yeates a écrit :
On 10/11/2007, Nick Wedd [EMAIL PROTECTED] wrote:
In message [EMAIL PROTECTED],
Chris Fant [EMAIL PROTECTED] writes
A beginner could easily run gnugo for a day or two, get a 7k rank for
the
gnugo account, then replace gnugo
Le lundi 5 novembre 2007, Don Dailey a écrit :
I noticed there are various Gnugo with Monte Carlo enhancements. Will
any of these be integrated into the the Gnugo releases? It seems like a
logical move.
As far as i know MonteGNU is more or less:
http://trac.gnugo.org/gnugo/ticket/150
and
Le lundi 29 octobre 2007, Don Dailey a écrit :
I don't see Mogo on the server?Where is Mogo?
However CrazyStone is there to represent the Monte Carlo programs and
seems to be doing a very good job indeed!
CS-8-26-2CPU http://www.lri.fr/%7Eteytaud/cross/CS-8-26-2CPU.html is
doing
Le lundi 29 octobre 2007, Don Dailey a écrit :
I don't see Mogo on the server?Where is Mogo?
However CrazyStone is there to represent the Monte Carlo programs and
seems to be doing a very good job indeed!
CS-8-26-2CPU http://www.lri.fr/%7Eteytaud/cross/CS-8-26-2CPU.html is
doing
Le jeudi 11 octobre 2007 22:31, Christoph Birk a écrit :
On Thu, 11 Oct 2007, Don Dailey wrote:
But we had a 19x19 server and it WAS NOT interesting. Nobody seemed
willing to play on it.
Maybe that has changed now.
It was not interesting because there was only one competitive
program on
Le vendredi 12 octobre 2007 06:10, Dave Dyer a écrit :
Considering how monte carlo actually works, I think it's plausible
to argue that it works best where the distance to endgame is small.
And for a player against Mogo this is very un-human feature on 19x19.
- Fuseki is done agaisnt a 10k
Le mardi 2 octobre 2007 16:46, Ian Osgood a écrit :
Greetings,
I noticed that the following link was recently added to the Computer
Go Wikipedia article.
http://www.spectrum.ieee.org/oct07/5552 Cracking Go, by Feng-hsiung
Hsu, IEEE Spectrum magazine, October 2007.
He claims it should be
Le vendredi 21 septembre 2007 21:35, [EMAIL PROTECTED] a écrit :
If the 19x19 CGOS is going to be retired due to lack of interest,
I wonder if there would be interest in trying out an ultra-blitz
version for a while: games as fast as the com. links would permit.?
(Game storage would be an
On Monday 10 September 2007 10:37:17 Sylvain Gelly wrote:
Is there a option like gnugo's --capture-all-dead?
In my test(./mogo --9 --time 1), seems mogo passed when not capture
alldead stones.
As this release is mainly for humans to play, it is set to play
against humans, so passing as
Le lundi 9 juillet 2007 18:46, Joshua Shriver a écrit :
Ok found some KGS games, and they make a lot more sense. With the
specification I can see what all of the OT, AP, TM, FF, etc commads
are. However I don't understand the way it sets the location, so far
nothing I've seen describes it.
Le dimanche 8 juillet 2007 11:51, chrilly a écrit :
If it would be really a big challenge, there would be some money.
There was a computer challenge with 1 million dollar prize during
many years, for a program abble to beat one professional choosen by the
sponsor. I don't know if it is still
Hi everybody
Guojuan (5p) has played some games agaisnt mogobot on kgs.
Worth to look at, and mogobot 3.0 won some on 9x9
Congrats to mogobot team, and thanks to Guo Juan for the games :)
Alain
___
computer-go mailing list
Le mardi 22 mai 2007 01:52, Dave Dyer a écrit :
I figured that a credible anchor player for 19x19 might
need a lot of cycles, and need to play a lot of games
at first, so spreading the load would be a good idea.
Maybe GNU Go 3.7.10 is _the_ good anchor player for 19x19:
- everybody use it at
Le dimanche 22 avril 2007 22:26, Sylvain Gelly a écrit :
Hello Daniel,
Le dimanche 22 avril 2007 21:26, [EMAIL PROTECTED] a écrit :
For human players a difference of 2 kyu means that the winning ratio of the
stronger player is almost 100%.
Is it? Do you have some statistics? If so, that
Le lundi 9 avril 2007 14:06, Don Dailey a écrit :
But the point is that
as long as you can provide time and memory you will get improvement
until perfect play is reached.
Is there any proof that heavy player converge toward the same solution as
the pure random playout ?
With infinite
Le dimanche 8 avril 2007 03:05, Don Dailey a écrit :
A few weeks ago I announced that I was doing a long term
scalability study with computer go on 9x9 boards.
I have constructed a graph of the results so far:
http://greencheeks.homelinux.org:8015/~drd/public/study.jpg
Thanks for this
Le vendredi 2 mars 2007 12:55, Jacques Basaldúa a écrit :
In CGT the temperature is the difference between the value if you play
and the value if you pass.
Thanks for your lights :)
Ok i better understand my confusion. In Go CGT-temperature applied to yose
strongly looks like ordinary points
Physics temperature is a macroscopic description (global) of the underlying
(un)-stability, so it comes to mind very quickly :)
Unfortunately the term temperature used in Computer Game theory is misleading
for physicists. CGT-temperature = value of the best move in go, this has
very little
Le jeudi 1 mars 2007 11:51, Jason House a écrit :
alain Baeckeroot wrote:
(I propose to ban the term temperature from CGT, and replace it by
value,
unless someone can explain the link with temperature in physics, and shows
some identical properties ;-)
While I bet most of us
Le jeudi 1 mars 2007 12:36, Nick Wedd a écrit :
[EMAIL PROTECTED] writes
(I propose to ban the term temperature from CGT, and replace it by value,
unless someone can explain the link with temperature in physics, and shows
some identical properties ;-)
This would be confusing. A position in
Le mercredi 28 février 2007 16:49, Oliver Lewis a écrit :
On 2/23/07, David Doshay [EMAIL PROTECTED] wrote:
On 22, Feb 2007, at 9:03 PM, alain Baeckeroot wrote:
... I made very slow progress to formalize this ...
But the whole stuff is rather coherent in my mind.
Then I envy you
Le jeudi 22 février 2007 17:00, Don Dailey a écrit :
It appears that at 9x9 Lazarus needs more play-outs to equalize with
gnugo. However, it also appears that at higher levels the superiority
is even greater than in the 7x7 games. This is non-intuitive and
probably not really the case - I
Le vendredi 23 février 2007 01:19, Matt Gokey a écrit :
Here is a thought experiment to test: define the board only logically
using a graph (nodes and neighbor nodes). No topological shape and no
mesh layout over any shape is needed. If all nodes have exactly four
neighbors, there is no
Le jeudi 22 février 2007 01:16, David Doshay a écrit :
It is pretty clear to me that, if the analogy to MC simulations in
magnets
is of any value, the temperature of the Go game you show is hotter than
optimal.
If the temperature were at the transition temperature, then each of the
Le mercredi 21 février 2007 02:10, Antonin Lucas a écrit :
No need for those difficulties, you can play along this board :
http://www.youdzone.com/go.html
I think this is not a torus, even if each vertice has 4 neighbours.
I can easily mentally transform this into a cylinder, with an
Le mardi 20 février 2007 13:10, Heikki Levanto a écrit :
P.S. Was there a good description of what a bot should do to finish a
game earlier - my current ones play to the bitter end, with only 1-point
eyes left. Might as well quit earlier if I can.
Don't play moves which would be self-atari
Le jeudi 8 février 2007 22:09, Sylvain Gelly a écrit :
It seems i was ambiguous: I was speaking of the simulation player too.
What i meant is a random simulation player is not biased, whereas a better
simulation player is biased by its knowledge, and thus can give wrong
evaluation of a
Le samedi 27 janvier 2007 14:07, Don Dailey a écrit :
On Fri, 2007-01-26 at 20:18 -0800, David Doshay wrote:
I would highly recommend that you do your testing against
a different Go engine. Self-play is a weak indicator.
Cheers,
David
I agree that there is a pretty good amount of
Le samedi 27 janvier 2007 14:58, alain Baeckeroot a écrit :
Le samedi 27 janvier 2007 14:07, Don Dailey a écrit :
I agree that there is a pretty good amount of in-transitivity
with self-play.
You can use the furiously fast and weak following programs:
gnugo-1.2 (604 ELO on cgos 9X9
Le mercredi 24 janvier 2007 19:56, Stuart A. Yeates a écrit :
Since no one has mentioned bounding memory, a complete lookup table (a
complete table of correct moves, perfect-hashed by board state) should do
the trick.
With 10^170 legal position for 19x19 what would be the size of this table ?
Le mercredi 24 janvier 2007 23:06, Jim O'Flaherty, Jr. a écrit :
You can if you use some sort of compression scheme...involving
multiple values per quanta. I bet there's more than enough
room...in the universe...probably just in your eyelash.
True i forgot about fantastic
Le jeudi 25 janvier 2007 02:16, Lars Nilsson a écrit :
On 1/24/07, alain Baeckeroot [EMAIL PROTECTED] wrote:
True i forgot about fantastic quantum-computer, which so far solved only
very specific and tiny problems or quantum mechanics.
In the spirit of this, lets bring the quantum computer
Le jeudi 25 janvier 2007 02:16, Lars Nilsson a écrit :
In the spirit of this, lets bring the quantum computer built at U of
Illinois that computers its answer without actually running..
By placing our photon in a quantum superposition of running and not
running the search algorithm, we
Le dimanche 21 janvier 2007 19:02, Don Dailey a écrit :
On Sun, 2007-01-21 at 13:34 -0200, Mark Boon wrote:
To move
up 200 ELO points in Go is usually not achieved by looking at more
positions but by acquiring new concepts. To acquire a new concept in
just a few hours is a rare
Le dimanche 21 janvier 2007 01:23, Don Dailey a écrit :
On Sat, 2007-01-20 at 15:34 -0700, Arend Bayer wrote:
Hi Don,
To put another perspective on it: If I had an hour for every move in a
tournament game, I might play good EGF 5d level instead of average EGF
4d. That's a big difference
Le vendredi 12 janvier 2007 23:45, Chrilly a écrit :
It would be interesting if the empirical Komi depends on the playing
strength.
It seems that for nearly random players, the komi is close to 0 (or maybe 1
under chinese rules to compensate for 1 more stone)
Gunnar reported komi = 0.05 for
Le mercredi 10 janvier 2007 10:32, Sylvain Gelly a écrit :
Hello,
Also on 19x19 mogos plays also some very slow moves in the beginning of
7 handicap game.
[...]
In 19x19, MoGo only considers local moves, near the move you
just played or the last move it played. It even doesn't look at
Le samedi 13 janvier 2007 16:46, Hideki Kato a écrit :
CM-1's processing element is not a transputer but a custom (CMOS) 1-bit
ALU with 4Ki bit of RAM. I know this is not essential but believe this
kind of correction is old men's role :-).
oops, true, my memory mixed up some old stuff :)
1 - 100 of 116 matches
Mail list logo
