I 100% agree with Don, dynamic komi just cant be the right approach in my
opinion.
One idea I just have is this :
In the tree search part, instead of using a rule wich converges to MAX, use a
rule wich converges to alpha*MAX + beta*AVERAGE. Do this only for plies where
it is the weaker player
I noticed that, in general, changes in the playout policy have a much
bigger impact on larger boards than on smaller boards.
Rémi
I think rating differences are emplified on larger boards. This is easy to
see if you think about it this way :
Somehow a 19x19 board is like 4 9x9 boards. Let
I have a question :
If the lines in the graph are straight lines and they dont have the same
increase rate, then isnt there a point where they should cross ?
Do they all cross at the same point ?
I guess this point (if it exists) would indicate some kind of starting point
: It would correspond
M Interesting problem lol.
April fools'day, I guess?
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
: Magnus Persson [EMAIL PROTECTED]
To: computer-go@computer-go.org
Sent: Thursday, March 13, 2008 8:57 AM
Subject: Re: [computer-go] solving the nakade problem
Quoting Ivan Dubois [EMAIL PROTECTED]:
Hello,
I think there is a very easy and straigthforward solution to the
nakade/seki problem, here
Hello,
I think there is a very easy and straigthforward solution to the nakade/seki
problem, here it is :
For moves that are self-atari on a group that contains MORE than 5 stones :
Both in the tree and the playouts, strictly forbid them (exactly like you
forbid filling an eye).
Mogo is already very strong at endgame and certainly plays perfectly near the
end of the game. The more advanced the program, the sooner it can play perfect
endgame.
But correct ko threats playing has nothing to do with the playout part : Since
it is a strategic concept that involves global
Ok, I think I see what you mean, but I am not sure I really agree.
As you say, this is related to horizon effect. I think current MC programs can
play ko quite well because they are trying do delay the outcome of losing the
ko, therefore they tend to play threats do gain time, just like human
Hello,
I would like to add transposition handling to my UCT engine (it is currently
2050 elo on CGOS). I thought a little about how to do it, and realized it is
not obvious at all. So I thought I may ask to people on this list what they
think.
My first idea was to back-up the result of each
Hello,
I downloaded the file cgosGtp-win.zip from http://cgos.boardspace.net/ but I
cant make it work. I am on windows.
I tried this command : cgosgtp.exe -name MyProgram.bat
But it doesnt work.
What am I doing wrong ?
Could someone provide an example of a correct invocation of cgosgtp.exe ?
--gtp --log mybot.log
priority 3
- Don
ivan dubois wrote:
Hello,
I downloaded the file cgosGtp-win.zip from http://cgos.boardspace.net/ but
I cant make it work. I am on windows.
I tried this command : cgosgtp.exe -name MyProgram.bat
But it doesnt work.
What am I doing wrong
to your program with
2) You also have to provide the password and username
3) The quit.txt means that you logoff the program by creating a file
with this name
4) log.txt creates a log so you can look to see what went wrong if
it does not connect
Quoting ivan dubois [EMAIL PROTECTED]:
Hello
It does use GTP.
- Message d'origine
De : Raymond Wold [EMAIL PROTECTED]
À : computer-go computer-go@computer-go.org
Envoyé le : Dimanche, 24 Février 2008, 1h54mn 18s
Objet : Re: [computer-go] How to use CGOS ?
Once we're on the topic, is there a good reason why CGOS does not use GTP?
In the tree search part, there is generaly no restriction to the moves that can
be played. So a UCT program should have no problem seeing that A1 is the best
move localy. However, A1 will be considered a 50% killing move, not 100%. This
is because UCT will have trouble looking ahead the forced
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
well
Ok, this is a special minimax solver. Call it the Ivan Dubois stupid minimax
solver if you like.
Anyway, its only purpose is to show that :
Returns the best move when given enough time does NOT implie Is scalable
in practice.
I am very sad that this simple logic has no appeal to most
- Message d'origine
De : Harald Korneliussen [EMAIL PROTECTED]
À : computer-go@computer-go.org
Envoyé le : Mercredi, 23 Janvier 2008, 15h31mn 20s
Objet : [computer-go] Bent four in the corner was:Scalability problem of
play-out policies
Ivan Dubois mentioned the bent four in the corner shape
the
probability of a black win. Repeat until the program corrects its estimate.
It would be interesting to determine just how many simulations are needed to
solve this problem - which is obvious to double-digit kyu players.
Terry McIntyre [EMAIL PROTECTED]
- Original Message
From: ivan dubois
.
- Original Message
From: ivan dubois [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Wednesday, January 23, 2008 10:51:52 AM
Subject: Re : [computer-go] Bent four in the corner was:Scalability problem of
play-out policies
Hello,
I agree that the current
Thanks.
- Message d'origine
De : Russell Wallace [EMAIL PROTECTED]
À : computer-go computer-go@computer-go.org
Envoyé le : Mercredi, 23 Janvier 2008, 18h07mn 27s
Objet : Re: Re : Re : [computer-go] Is MC-UCT really scalable ... is a troll
On Jan 23, 2008 3:44 AM, Don Dailey [EMAIL
point of view.
Ivan
- Message d'origine
De : Michael Williams [EMAIL PROTECTED]
À : computer-go computer-go@computer-go.org
Envoyé le : Mercredi, 23 Janvier 2008, 20h38mn 32s
Objet : Re: Re : [computer-go] Bent four in the corner was:Scalability problem
of play-out policies
ivan
I gave you a proof of what I am claiming, I really dont see what I can do more.
Anyway we all now all this is just a waste of time for pleasure. People who are
really working on a UCT engine (I dont anymore) will find solutions to these
problems as soon as they become relevant to playing
Hello Don,
I think you are mostly right, but there is something you seem not to realise.
MC players are very good at scoring. They know when they will win for sure by
0.5. However, human players, even strong players, generaly never have such
accurate counting skills. So if they are ahead by
I think there is some missconception about this infinite scalability of MC
stuff.
Theory is only usefull when the model it is based on shares important aspects
with reality.
In theory, 19*19 Go is a finite game, wich can be analysed in a finite amount
of time. So ANY algorithm that solves the
.
Nevertheless, the human sometimes is under the impression the program
made a series of really bad moves and STILL WON, making the human
feel frustrated.But really it was not like that at all.
- Don
ivan dubois wrote:
Hello Don,
I think you are mostly right, but there is something you seem
, 22 Jan 2008, ivan dubois wrote:
in theory, infinitely scalable. For example, the folowing algorithm is
infinitely scalable :
Analyse the complete mini-max tree of the game. If enough time to
finish, returns the correct move, if not, return a random move.
Now, is this algorithm really
Janvier 2008, 23h38mn 30s
Objet : Re: Re : Re : [computer-go] Is MC-UCT really scalable ... is a troll
On Tue, 22 Jan 2008, ivan dubois wrote:
When people say that MC infinite scalability is mathematicaly proven,
they do not refer to the definition you give, they refer to the
definition I used
09s
Objet : Re: Re : [computer-go] Is MC-UCT really scalable ... is a troll
ivan dubois wrote:
I think there is some missconception about this infinite scalability of MC
stuff.
There is no misconception. This is clearly a PRACTICAL concept.
Theory is only usefull when the model
back on the fact that UCT is
cleaning up after one's mistakes: the eventual behavior, given enough
time, is still perfect play. (And of course it is not as if people
blindly adjust the monte carlo policies without checking the revised
versions for severe misconceptions.)
Weston
On 1/22/08, ivan
Hi Alain,
Sorry for being so insistant :
No i just said that, unless i really understood nothing, i read here from well
known competent persons that MC+UCT scales infinitely , and would reach perfect
play with infinite computational resources, and this is theoretically proven
(which is not the
[EMAIL PROTECTED]
À : computer-go computer-go@computer-go.org
Envoyé le : Mercredi, 23 Janvier 2008, 4h44mn 17s
Objet : Re: Re : Re : [computer-go] Is MC-UCT really scalable ... is a troll
ivan dubois wrote:
Thanks !
I think I agree with everything you said.
After some reasoning, I changed
Hello all,
Does someone know about an implementation and/or an algorithmic description of
the Bradley-Terry model ?
Thanks and happy new year !
_
Ne gardez plus qu'une seule adresse mail ! Copiez vos mails
Hello to all.
I have put my program on cgos, but i never receive the time_left command. Is
it normal, or am i doing something wrong ?
_
Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo!
le : Jeudi, 20 Septembre 2007, 21h37mn 18s
Objet : Re: [computer-go] time_left command on CGOS
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
CGOS does not send that command unless you tell it that it knows the
command using the known_commands
ivan dubois wrote:
Hello to all.
I have put my
implement time_settings? If you don't have that or respond
wrongly to it, the server (or perhaps it's the client) will not send the
time_left command.
- - Don
ivan dubois wrote:
Thanks, but i dont receive the known_command either :(
I added known_command to the list list_commands also, because
rank vs time
On Fri, 2007-01-26 at 13:38 +, ivan dubois wrote:
However, if you take for example a computer programm that does
straight UCT (global UCT, with no sub-areas), then i believe it can
not scale well when board size increases. Because the branching would
factor increase
36 matches
Mail list logo
