Re: [computer-go] Anchor Player

[Hideki Kato]

Increasing KOMI is much easier than placing stones, right?

Jacques Basaldúa‚³‚ñ <[EMAIL PROTECTED]>:
>I would like to take part in the 19x19 competition.
>I also prefer kyu rating to Elo, but I got the impression that
>you were relating kyu rating with handicap games (that is
>usually done by human players).
>
>I think handicap is a bad idea for computers. Handicap
>requires human intelligence to understand how the playing
>style must be changed. It completely ruins fuseki databases
>and may also make josekis that are good under equal play
>too slow. Of course, if you pretend to ruin fuseki database
>programs, its a good idea. But I think dan/pro level fuseki
>is not only legitimate, but probably the best possible fuseki
>and it can be played in ultrablitz which preserves computing
>time for later moves. The only drawback is 10 Mb of
>disk space. Any silly welcome video is heavier than that.
>
>I suggest, if handicap is implemented, it should be optional.
>
>Jacques.
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Anchor Player

[Hideki Kato]

Stuart A. Yeates‚³‚ñ <[EMAIL PROTECTED]>:
>Increasing komi is much easier than placing stores, but a much weaker
>representation of how go games are actually played in the real world.

Agree. But we'd better not to be bothered by fixed stones now, I
believe.

>cheers
>stuart
>
>On 12/15/06, Hideki Kato <[EMAIL PROTECTED]> wrote:
>>
>> Increasing KOMI is much easier than placing stones, right?
>>
>> Jacques Basaldúa‚³‚ñ <[EMAIL PROTECTED]>:
>> >I would like to take part in the 19x19 competition.
>> >I also prefer kyu rating to Elo, but I got the impression that
>> >you were relating kyu rating with handicap games (that is
>> >usually done by human players).
>> >
>> >I think handicap is a bad idea for computers. Handicap
>> >requires human intelligence to understand how the playing
>> >style must be changed. It completely ruins fuseki databases
>> >and may also make josekis that are good under equal play
>> >too slow. Of course, if you pretend to ruin fuseki database
>> >programs, its a good idea. But I think dan/pro level fuseki
>> >is not only legitimate, but probably the best possible fuseki
>> >and it can be played in ultrablitz which preserves computing
>> >time for later moves. The only drawback is 10 Mb of
>> >disk space. Any silly welcome video is heavier than that.
>> >
>> >I suggest, if handicap is implemented, it should be optional.
>> >
>> >Jacques.
>> >___
>> >computer-go mailing list
>> >computer-go@computer-go.org
>> >http://www.computer-go.org/mailman/listinfo/computer-go/
>> --
>> [EMAIL PROTECTED] (Kato)
>> ___
>> computer-go mailing list
>> computer-go@computer-go.org
>> http://www.computer-go.org/mailman/listinfo/computer-go/
>>
> inline file
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Anchor Player

[Hideki Kato]

Don Dailey: <[EMAIL PROTECTED]>:

>On the web I see that some ELO based GO servers assume 100 ELO is 1
>rank, and do exactly what I proposed, when they handicap they fold
>this into the ELO rating of the players for rating purposes.

In Nihon Kiin's ELO system(1), 1000 ELO is 1 rank, ex 25kyu is 
[1000,1999], 1 kyu is [25000,25999], pro is [34000,infinitive](2)
(1)  (J)
(2)  (J)
#Unfortunatelly, Nihon Kiin has no English page.

>I would like to do better than that, so what I need is a formula that
>can be gradually adjusted by the server.  Something more sophisticated
>than just an ELO to stones formula that takes more into consideration
>than just the rating difference.
>
>I'm glad you brought this to my attention.
>
>- Don
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Cheap multiprocessing

[Hideki Kato]

PS3's main memory is, however, 256MB which seems not enough.

John Tromp: <[EMAIL PROTECTED]>:
>On 1/5/07, Darren Cook <[EMAIL PROTECTED]> wrote:
>
>> The playstation multiprocessing looks very different: you get 1 general
>> purpose CPU and 6 specialized CPUs. Their key feature is they have 256K
>> of local memory - this is not cache, it is all the memory they can
>> access. Not useful for UCT designs (which seem memory-limited currently)
>> but fine for normal monte-carlo.
>
>The UCT tree is kept in main memory by the single PPE.
>The 6 SPEs which do the individual MC simulations don't need any access
>to that tree and should run perfectly fine in 256k...
>
>regards,
>-John
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

[computer-go] Re: How to use CGOS ?

[Hideki Kato]

See
http://www.mail-archive.com/computer-go@computer-go.org/msg04946.html

This link helps not only 19x19 but also 9x9 for Windows users.

-Hideki

ivan dubois: <[EMAIL PROTECTED]>:
>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 ?
>
>Thanks a lot.
>
>Ivan
>
>
>  
> _ 
>Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail 
>http://mail.yahoo.fr
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Re: How to use CGOS ?

[Hideki Kato]

Don Dailey: <[EMAIL PROTECTED]>:
>I think those instructions do not apply to the new client scripts - it
>works differently.

Oh, I see.  Then could you please change the link at the middle 
(immediately before "Suggest Improvements" paragraph) of the page, 
"Connect program to 19x19 server"?

-Hideki

>- Don
>
>
>Hideki Kato wrote:
>> See
>> http://www.mail-archive.com/computer-go@computer-go.org/msg04946.html
>>
>> This link helps not only 19x19 but also 9x9 for Windows users.
>>
>> -Hideki
>>
>> ivan dubois: <[EMAIL PROTECTED]>:
>>   
>>> 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 ?
>>>
>>> Thanks a lot.
>>>
>>> Ivan
>>>
>>>
>>>  
>>> _
>>>  
>>> Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! 
>>> Mail 
>>> http://mail.yahoo.fr
>>> ___
>>> computer-go mailing list
>>> computer-go@computer-go.org
>>> http://www.computer-go.org/mailman/listinfo/computer-go/
>>> 
>> --
>> [EMAIL PROTECTED] (Kato)
>> ___
>> computer-go mailing list
>> computer-go@computer-go.org
>> http://www.computer-go.org/mailman/listinfo/computer-go/
>>
>>   
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

[computer-go] Re: Should 9x9 komi be 8.0 ?]

[Hideki Kato]

Welcome Jonas.

[EMAIL PROTECTED]: <[EMAIL PROTECTED]>:
>> I experimented with something similar a while ago, using the
>> publicly available mogo and manipulating komi between moves.
>>
>> If its win probability fell below a certain threshold (and the move
>> number wasn't too high), I told it to play on the assumption that it
>> would receive a few points more komi (and similarly when the win
>> probability became high).
>
>That's certainly a nice solution !
>
>It's probably easy to implement, and relatively easy to tune.

I've implemented and used the idea for the first UEC Cup Computer-Go
tournament (19x19, Japanese rules) on Dec. 1-2 and was 5th/27
participants.
http://jsb.cs.uec.ac.jp/~igo/eng/ #No results in English pages.

It's easy to implement but hard to tune, though by my experiments. 
The point is how to caliculate an appropriate bias or komi from
current info, ie,expected winnig rate, number of moves, etc.  I've
tested some means and used following very ad-hoc formula for the
tournament.

delta_komi = 10^(K * (number_of_empty_points / 400 - 1)),
where K is 1 if winnig and is 2 if loosing.  Also, if expected
winning rate is around 50%, Komi is unmodified.

By a few tens of benchmark games against GNU Go before the tounament,
it improved about 100 ELO but the number of games is not enough
to believe this.

>Now, the question is: did it seem stronger to our eyes because it played
>more human-like ?

Yes, certainly.

I've tried and posted the use of tanh(K * score) to this list on Dec
13, as well.
Hideki Kato: <[EMAIL PROTECTED]>:
>Hi Begué  and Don,
>
>I did this in my earlier version of ggmc.  The real code was:
>
>reward = 0.5 * (1 + tanhf(K * (score - komi)));
># tanhf() is a float, not double, version of hyperbolic tangent
>function.
># I use tanh() as exp() may cause overflow.
># You can see the code from http://www.gggo.jp/ as it's still left.
>
>I got best performance around 10 of K but it's so little that I'm
>using simpler one now.

-Hideki

>As a remark, tests of strength with this kind of strategy could be made
>through self-play with handicap games.
>
>Moreover, if a program plays
>better when he is ahead (or conversely behind), it might be an idea to
>make the program play initially with a higher (resp. lower) komi.
>I seem to remember someone saying that a MC program (I don't remember which
>one) was better when he had handicap stones, than against them, because
>he used these stones well. I wonder if there was any link with the
>estimation of position.
>
>Jonas
>
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [EMAIL PROTECTED]: Re: [computer-go] Should 9x9 komi be 8.0 ?]

[Hideki Kato]

Don Dailey: <[EMAIL PROTECTED]>:
>
>
>[EMAIL PROTECTED] wrote:
>>> I experimented with something similar a while ago, using the
>>> publicly available mogo and manipulating komi between moves.
>>>
>>> If its win probability fell below a certain threshold (and the move
>>> number wasn't too high), I told it to play on the assumption that it
>>> would receive a few points more komi (and similarly when the win
>>> probability became high).
>>> 
>>
>> That's certainly a nice solution !
>>
>> It's probably easy to implement, and relatively easy to tune.
>>
>> Now, the question is: did it seem stronger to our eyes because it played
>> more human-like ?
>>   
>I experimented with this idea extensively a while back and never found
>an implementation that improved it's playing ability.In fact every
>version played weaker.I tried versions that dynamically adjusted
>komi during the course of a game when things looked close to hopeless
>(or certain) and I came to the eventual conclusion that whenever you
>didn't use the correct komi,  you were in fact decreasing it winning
>chances. If you tell it that is not winning when it really IS
>winning by 1/2 point,  then there will be games where it plays stupid
>desperate moves when it doesn't have to. 
>
>If it is almost losing and you tell it (by adjusting komi) that it has a
>good chance,  it will tend to lose with a higher score,  but you have
>essentially treated it as a spoiled child,  lowering your expectations
>for it and it is happy to play with the new goal of losing.  
>
>This whole concept is based on what appears to be a flawed idea,  
>deceive the program into believing something that isn't true in the
>hopes that it will somehow make it play better.   

I don't agree. If the estimated score by playouts had no error, you 
were correct.

I've applied my formula (in my previous post) when estimated winning 
probability beyonds 65% and beneth 45% or so and get better 
results.  For example, withou this, my program sometime lost games 
against weaker programs due to misunderstanding of L&D at corners 
with nakade.

-Hideki

>We had this conversation recently but with idea of changing the scoring
>algorithm, not the komi.I think the same principles apply.
>
>I actually think some variation of the idea would work if we understood
>the issues better.In SOME positions it might very well play
>objectively better if we lie to it by  lowering  or raising the komi or
>manipulating the scoring algorithm,  but we have to pick and choose the
>types of positions where this doesn't lead to weaker play. For
>instance it's good if it makes it fight better,  but in many positions
>lowering the komi to make it fight in a losing position will cause it to
>consolidate a losing position. UCT isn't going to fight when it can
>consolidate.   It doesn't care how difficult a position is to play for
>you,  only for it.

It depends on the property of playouts of programs, I guess.  That 
is, if the error of the estimated score decreases in monotonic 
manner, this idea won't help any.

-Hideki
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Re: Should 9x9 komi be 8.0 ?]

[Hideki Kato]

Gian-Carlo Pascutto: <[EMAIL PROTECTED]>:
>Hideki Kato wrote:
>
>> delta_komi = 10^(K * (number_of_empty_points / 400 - 1)),
>> where K is 1 if winnig and is 2 if loosing.  Also, if expected
>> winning rate is around 50%, Komi is unmodified.
>
>I don't think the formula you posted is correct.

It's just an experimental formla with no theoritical basis.  I don't 
think we can discuss its "correctness."

>In the opening it gives delta_komi = 0.8 and in the endgame it gives
>delta_komi = 0.1.

I'm sorry but I don't understand what do you want to say.  Too 
small?

-Hideki
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [EMAIL PROTECTED]: Re: [computer-go] Should 9x9 komi be 8.0 ?]

[Hideki Kato]

Don Dailey: <[EMAIL PROTECTED]>:
>
>Hideki Kato wrote:
>> Don Dailey: <[EMAIL PROTECTED]>:
>>   
>>> [EMAIL PROTECTED] wrote:
>>> 
>>>>> I experimented with something similar a while ago, using the
>>>>> publicly available mogo and manipulating komi between moves.
>>>>>
>>>>> If its win probability fell below a certain threshold (and the move
>>>>> number wasn't too high), I told it to play on the assumption that it
>>>>> would receive a few points more komi (and similarly when the win
>>>>> probability became high).
>>>>> 
>>>>> 
>>>> That's certainly a nice solution !
>>>>
>>>> It's probably easy to implement, and relatively easy to tune.
>>>>
>>>> Now, the question is: did it seem stronger to our eyes because it played
>>>> more human-like ?
>>>>   
>>>>   
>>> I experimented with this idea extensively a while back and never found
>>> an implementation that improved it's playing ability.In fact every
>>> version played weaker.I tried versions that dynamically adjusted
>>> komi during the course of a game when things looked close to hopeless
>>> (or certain) and I came to the eventual conclusion that whenever you
>>> didn't use the correct komi,  you were in fact decreasing it winning
>>> chances. If you tell it that is not winning when it really IS
>>> winning by 1/2 point,  then there will be games where it plays stupid
>>> desperate moves when it doesn't have to. 
>>>
>>> If it is almost losing and you tell it (by adjusting komi) that it has a
>>> good chance,  it will tend to lose with a higher score,  but you have
>>> essentially treated it as a spoiled child,  lowering your expectations
>>> for it and it is happy to play with the new goal of losing.  
>>>
>>> This whole concept is based on what appears to be a flawed idea,  
>>> deceive the program into believing something that isn't true in the
>>> hopes that it will somehow make it play better.   
>>> 
>>
>> I don't agree. If the estimated score by playouts had no error, you 
>> were correct.
>>   
>
>It's not about the error - it's about the side-effects of trying to
>second guess the cure.My grandmother used to think castor oil was
>the solution to every illness.   

I don't think that's a universal solver.  You wrote the idea is 
flawed but in fact the idea is effective for, at least, my program.


>It's naive to think some simplistic deception imposed upon the program
>is going to correct the error when you don't even know if the program is
>erring in the first place. How can you say,  "the program thinks it
>is losing, but it MUST be in error and I'm going to change the komi so
>that it will 'play better'?"You must have some basis for knowing the
>program is in error before you can lower it's goal.  

I never say so.  Perhaps my explanation made you misunderstand my 
issue.  Please read my example below once more.

>You have basically 2 cases when losing.   One case is that the program
>really is busted and is in a dead lost position.The other case is
>that the program THINKS it's lost but really is winning (or at least has
>excellent chances.) In the first case,  we are simply playing for a
>miracle,  hoping that if we lower our expectations the opponent will
>falter. This is at best a speculative and extremely minor
>enhancement if we can even make it work and I argue that it also imposes
>risks of it's own.Unless the score is actually zero in every line, 
>the program is going to play for any outside chance of a win,  no matter
>how small.   Telling it that a big loss is good enough will cause it to
>play safer, not more aggressively like you think.  (Yes, you can
>hand pick specific positions where you can "trick" it into doing the
>right thing, but that is "cooking the books", it's not a real solution.) 
> 
>The other case is that the program really isn't losing even though it
>thinks it is dead busted.How does the program know this is really
>the case?If it knew that, your program would be better.So you
>don't even know why it thinks it's busted.Even so,  I argue that
>telling it to accept less than what is required to win is risky and will
>lose more games than it will win  (which isn't very many since it almost
>certainly losing anyway.)

Re: [computer-go] Re: Should 9x9 komi be 8.0 ?]

[Hideki Kato]

Gian-Carlo Pascutto: <[EMAIL PROTECTED]>:
>Hideki Kato wrote:
>> Gian-Carlo Pascutto: <[EMAIL PROTECTED]>:
>>> Hideki Kato wrote:
>>>
>>>> delta_komi = 10^(K * (number_of_empty_points / 400 - 1)),
>>>> where K is 1 if winnig and is 2 if loosing.  Also, if expected
>>>> winning rate is around 50%, Komi is unmodified.
>>> I don't think the formula you posted is correct.
>> 
>> It's just an experimental formla with no theoritical basis.  I don't 
>> think we can discuss its "correctness."
>
>Even if it's a heuristic the outcome should be sensible. For what you 
>posted it doesn't seem to be at all. So I think that what you posted is 
>not what is in the program. That is what I mean by "correct".
>
>>> In the opening it gives delta_komi = 0.8 and in the endgame it gives
>>> delta_komi = 0.1.
>> 
>> I'm sorry but I don't understand what do you want to say.  Too 
>> small?
>
>Yes. I don't understand how it can do anything if it adds _at most_ 0.8 
>points difference.
>
>Should it have been 10* instead of 10^ or something?

I tried much bigger value first but it made my program very unstable.  
I decreased by a bit time by time and converged this.  Of course, this 
value depends on when you start increasing or decreasing komi. Please 
remember this delta is added to or subtracted from 
komi on _each_ play.  Adding 1.0 to komi on each move cuuld change 
the world dramatically in the middle of games on 19x19.  IIRC, this 
small value, less than 1.0, is better to adjust komi _smoothly_.   In 
other word, this formula is a conservative one.  

Sure, this value is sometime not enough.  I had tried to find more 
effective formula but, in such cases, it was very hard to tune factors 
to get stable.  Please note that I had to modify my code to 19x19 
board, Japanese rules, etc, all in a few weeks so that I couldin't try 
many.

I strongly believe you or others will be able to find much better 
formulae.

-Hideki

--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Re: Should 9x9 komi be 8.0 ?]

[Hideki Kato]

[EMAIL PROTECTED]: <[EMAIL PROTECTED]>:
>> delta_komi = 10^(K * (number_of_empty_points / 400 - 1)),
>> where K is 1 if winnig and is 2 if loosing.  Also, if expected
>> winning rate is between 45% and 65%, Komi is unmodified.
>
>There's one thing I don't like at all, there: you could get positive
>evaluation when losing, and hence play conservatively when you should
>not. That could especially be true near the end, when the situation
>drifted from bad to less bad. I think that if this happens you're
>doomed... The  other way around would probably be painful too.

 From my observaion, mc chooses good moves if and only if the winning 
rate is near 50%.  Once it gets loosing, it plays bad moves.  Surely 
it's an illusion but it helps to prevent them.

>After all, the aim of tinkering with komi is to avoid that the computer
>plays nonsensical moves, but it should know whether he must fight or
>calm down.

Agree.  So, it's important _when_ adjust komi or apply my method.  My 
object is to keep winning rate around 50%, which yields good moves.

>Here is a suggestion: give a new komi at each move (not a drift, though
>it would probably be a good idea that you *upper bound the komi change*,
>maybe by ten times the delta_komi you use now).
>For choosing it, punish the fact of being away from true komi
>proportionnally to | komi_aya - true_komi |. Call lambda the
>proportionnality constant.
>Punish the winning rate through (winning_rate - .5)^2.
>Total loss function is then:
>loss = lambda * |komi_aya - true_komi| + (winning_rate - .5)^2
>
>Suppose the change in winning rate is proportional to change in komi,
>that is take as hypothesis:
>winning_rate(komi_aya) = winning_rate(normal_komi) + C (komi_aya -
>normal_komi) 
>
>REMARK: C is negative !
>
>Take the change in komi that minimizes the punishment (a real), and
>truncate it to get an integer (truncation also means you have a tendancy
>to have delta_komi near 0).
>
>If you knew beforehand the winning rates for each komi, this would
>ensure you generally have a winning rate on the right side of .5, while
>it would not move komi if winning rate is somewhat near .5. 
>
>Solving the degree two equation yields:
>change_in_winning_rate_by_point_komi_change =
>
>new_komi_aya =
>truncation[(.5 - old_winning_rate) +
>C * old_komi_aya - lambda / (2 * C)]^{+}
>
>if the estimated winning rate with true komi is more than .5, and
>
>new_komi_aya =
>truncation[(.5 - old_winning_rate) +
>C * old_komi_aya + lambda / (2 * C)]^{-}
> ^^
>if the estimated winning rate with true komi is less than .5.
>
>
>The estimated winning rate with true komi is given by
>winning_rate - C old_komi_aya.
>
>You could take 
>lambda = K / (1 - number_of_empty_points / 400)
>if you want to be nearer true komi during yose. Less human-like, but
>less error-prone !
>Now that's probably not necessary since the constant C is probably much
>bigger when entering yose.
>
>
>The problem here in this formula is to find a good C, since this
>constant  change during the game.
>Here is an idea from the data in the game: use the last time the komi
>was changed and take:
>C = 
>(winning_rate_after_last_change - winning_rate_before_last_change) /
>(komi_aya_after_last_change - komi_aya_before_last_change)
>[* f(number_empty_points_last_change, number_empty_points_now) if you want to 
>refine]
>
>Now this estimation might be unstable, especially since it cannot tell if
>that's the evolution of the situation that made the winning rate change,
>or the change in komi. I'm sure ou can find ways to stabilize. The
>easiest I can think of would be a formula like:
>new_C = .3 * C_formula_above + .7 old_C
>
>
>END OF THE DELIRIUM

:) 

Thanks.  I will try it later as I'm now rewriting my code radically
which will take so long.

# One question: where _aya_ comes from or stands for?  If my guess is 
correct, you are confusing Hiroshi, author of Aya, and I, Hideki, 
author of GGMC :).  I'm sorry if I'm wrong.

-Hideki
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Re: Should 9x9 komi be 8.0 ?]

[Hideki Kato]

Thanks Heikki, this is what I'm trying to write in English right 
now :).

-Hideki

Heikki Levanto: <[EMAIL PROTECTED]>:
>On Mon, Mar 03, 2008 at 12:15:36PM -0800, Christoph Birk wrote:
>>
>> On Mon, 3 Mar 2008, Don Dailey wrote:
>> >What you are trying to do is more in the category of opponent
>> >modeling.You want to optimize for the case that you might
>> >occasionally salvage a game against an opponent that is much weaker than
>> >you but is beating you anyway.
>> 
>> No, absolutely not. The idea of following the 0.5 pt loss is always
>> true, even if the opponent is of comparable strength.
>
>I agree with this, 100%
>
>> >strength level.  If your program KNOWS it is losing by 0.5 points,  then
>> >it's reasonable to expect that your opponent does too, especially given
>> >the fact that he just outplayed you.
>> 
>> I think you are too much of "chess player" :-)
>> The fact that he is 0.5  point in the lead does not imply he is
>> (much) stronger. Any player, in particular a human player, is capable
>> of the making a mistake. So it is important to stay on the 'small'
>> losing line. That might a difference to chess, where there is no
>> 'small' loss.
>
>Even the top professionals make the occasional small mistake in the end game.
>I expect our programs will be playing (much) lesser opponents for the
>foreseeable future, and thus have a good hope of seeing slightly suboptimal
>play in the end game.
>
>> >So at best you hope your opponent will make a stupid mistake in an
>> >obviously lost position for you.
>> 
>> No, the opposite. Not a stupid mistake; I am hoping for the subtle
>> mistake. But you throw that opportunity away If you play "desparate"
>> moves just because you think you will lose the game by 0.5 points.
>
>Indeed! And there still is a (non-zero) risk that the program is estimating
>wrong, and actually has a small lead. Playing tight will preserve that, with
>a chance of improving it a bit, whereas playing "desperate" moves will throw
>it all away.
>
>
>Of course, if a program knows it is going to loose, it might as well
>resign.
>
>-H
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

[computer-go] Floating komi

[Hideki Kato]

I'd like to give here an example to make things clear.

The conditions are:
1) Using digitizing scheme that maps real score to [0,1] (or [-1,1]) 
so that the program cannot distinguish losing/winning by 0.5 or 10.5 
pt at all.
2) Playouts include some foolish moves (usually with low 
but not zero probability), not to connect large groups in atari 
position for example, due to hold its randomness.
3) The position is at early endgame where there are no moves that 
gain greater than 2 pt, for example, in perfect play.
4) Black is behind by 0.5 pt.

The playouts may return winning but gambling move (perhaps with low 
probability) under above conditions, especialy in case of the number 
of playouts is small which is usually true on 19x19, and UCT will 
choose it.

The question is, which is better to keep 0.5 pt behind or to play 
gambling moves (here I mean such moves that B will lose many pts if W 
will answer correctly) with expecting W's (stupid) mistakes?


In addition to above, there is one more issue to consider. If the 
playout has a systematic error, nakade for example, it's not good to 
keep 0.5 pt ahead.  Having more margin is clearly better.

The idea of floating komi helps above two.  I'd like to emphasize that 
I know it's not a universal solution.  As it seems, however, very hard 
to solve nakade problem, it could be a pracitical solution.

-Hideki
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Floating komi

[Hideki Kato]

Don Dailey: <[EMAIL PROTECTED]>:
>
>
>Hideki Kato wrote:
>> I'd like to give here an example to make things clear.
>>
>> The conditions are:
>> 1) Using digitizing scheme that maps real score to [0,1] (or [-1,1]) 
>> so that the program cannot distinguish losing/winning by 0.5 or 10.5 
>> pt at all.
>> 2) Playouts include some foolish moves (usually with low 
>> but not zero probability), not to connect large groups in atari 
>> position for example, due to hold its randomness.
>> 3) The position is at early endgame where there are no moves that 
>> gain greater than 2 pt, for example, in perfect play.
>> 4) Black is behind by 0.5 pt.
>>
>> The playouts may return winning but gambling move (perhaps with low 
>> probability) under above conditions, especialy in case of the number 
>> of playouts is small which is usually true on 19x19, and UCT will 
>> choose it.
>>
>> The question is, which is better to keep 0.5 pt behind or to play 
>> gambling moves (here I mean such moves that B will lose many pts if W 
>> will answer correctly) with expecting W's (stupid) mistakes?
>>
>>   
>The assumption is that you suddenly cannot trust MC to do what it does
>best even though you did for the entire game up until this point.   MC
>of course will choose the "gambling" move.  The whole concept of MC
>is to do what is most likely to produce a win.  
>
>We should think twice before asking it to choose the moves that produces
>the more sure loss.We are the ones that have a bias about this, not
>the MC programs.  

Whatever the 'concept' of MC is, I just will improve its weakness by
any means.  MC is just a method, IMHO, to evaluate a position better
than to use a static function.  # I'm just an engineer :).

>> In addition to above, there is one more issue to consider. If the 
>> playout has a systematic error, nakade for example, it's not good to 
>> keep 0.5 pt ahead.  Having more margin is clearly better.
>>   
>I believe nakade is a strawman.There are lots of things MC does
>better and lot's of things it does less well.You can always find
>positions that are hard or easy for your program to solve, but it isn't
>intrinsic to this issue. I don't think you should weaken this
>concept of playing for the best winning chances for the very few
>positions where MC programs take longer to resolve the endgame and there
>is a slight chance that it will win if it just happens to be enough to
>cover the exact situation.   Because this is no solution - it is at best
>a patch and would only work in some cases.   If I could do something
>that didn't hurt the program in other ways, but might help certain
>positions once in a while,  I would go for it. I've been in game
>programming a long time - if you have a problem with certain types of
>positions you really want a pointed solution that has little or no
>impact on other positions.   You don't want to be going back and forth
>fixing things up but you want to solve the problem as correctly as
>possible the first time.   I'll call this principle, "every solution
>has a side effect" but this is a pretty bad side effect.(I can't
>tell you how many times I "fixed" something in my chess program with
>some evaluation change only to find that I broke many other things at
>the same time.)

Although I'm afraid my English skill is enough to understand such a
long paragraph correctly (shorter is better :), I believe it's just a
choice.  Some are good at developing an essential solution but not
all.  As I know I'm worse at that, I just do what I can.

It was developped for the First UEC Cup that features
Japanese rules which count seki differently so that all MC programs
need to have some margin.  Rémi introduced a fixed margin by changing
komi for Crazy Stone and I've developed a dynamic one.  Do you
say we have to wait until we will develop an essential solution?

-Hideki

>- Don
>
>
>
>> The idea of floating komi helps above two.  I'd like to emphasize that 
>> I know it's not a universal solution.  As it seems, however, very hard 
>> to solve nakade problem, it could be a pracitical solution.
>>
>> -Hideki
>> --
>> [EMAIL PROTECTED] (Kato)
>> ___
>> computer-go mailing list
>> computer-go@computer-go.org
>> http://www.computer-go.org/mailman/listinfo/computer-go/
>>
>>   
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] 9x9 challenge

[Hideki Kato]

terry mcintyre: <[EMAIL PROTECTED]>:
>I attempted to access the games of IaGoChall, and
>could not; the KGS client beeped at me.
>
>Is there a method to review the game records?

We can download but cannot review the records directly.  Watch them
at offline.

-Hideki

>Thanks!
>
>
>Terry McIntyre <[EMAIL PROTECTED]>
>
>“Wherever is found what is called a paternal government, there is found state 
>education. It
>has been discovered that the best way to insure implicit obedience is to 
>commence tyranny in
>the nursery.”
>
>Benjamin Disraeli, Speech in the House of Commons [June 15, 1874]
>
>
>  
> 
>Never miss a thing.  Make Yahoo your home page. 
>http://www.yahoo.com/r/hs
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Life and Death

[Hideki Kato]

David Fotland: <[EMAIL PROTECTED]>:
>I just looked at this position and it looks like a win for black in the
>first position.  Many Faces evaluates it as a win for black, and plays c1 to
>save the lower left black group with almost no thinking time.
>
>Mogo is correct because the lower left black group is not dead.

I'm sorry if wrong but the black seems dead by B5 after C1, isn't 
it?

-Hideki

>David
>
>> -Original Message-
>> From: [EMAIL PROTECTED] [mailto:computer-go-
>> [EMAIL PROTECTED] On Behalf Of Matthew Woodcraft
>> Sent: Sunday, March 09, 2008 11:49 AM
>> To: computer-go
>> Subject: [computer-go] Life and Death
>> 
>> I've included two 13x13 positions below. In both positions it is
>> Black's
>> move.
>> 
>> The first position is simplified from a real game. Black has two
>> enclosed dead groups, and White has a small but easy win.
>> 
>> The second position is a modified version of the first in which the
>> dead
>> groups are more obviously dead.
>> 
>> If I try MogoRelease3 playing as Black on position 2, it shows a 20%
>> score and resigns either immediately or after a couple of moves.
>> 
>> If I try it on position 1, it shows a score of 70%+ for Black, and
>> continues to play until White takes steps to remove the dead groups
>> from
>> the board. I've tested with up to 2^24 playouts.
>> 
>> I have tried increasing --collectorLimitTreeSize and --limitTreeSize
>> (like bigMogo in the scalability study), but I can't set them much
>> higher than the default on this machine without running out of memory.
>> 
>> I'd be interested to see if someone with a bigger computer can find out
>> what resources it needs to judge this position well, and to see how
>> other engines do.
>> 
>> Position 1
>> 
>> (;GM[1]FF[4]
>> CA[UTF-8]
>> SZ[13]
>> HA[0]
>> KM[0.5]
>> AB[jb:kb][cb:cc][kc][bd:cd][jd:ld][be][he][cf:df][bg][gb:gh]
>> [ig:ih][jh:kh][eg:ei][li][aj:bj][hi:hj][lk][al][ck:cl][ji:jl]
>> [dm][im]
>> AW[ia:ja][ib][hc:jc][db:dd][hd:id][ce:de][ie][ke:le][bf][hf:jf]
>> [lf][jg:kg][mg][lh][ai:di][gi][mi][cj][ej:gj][ij][dk:fk][hk:ik]
>> [dl][il][bm][fl:fm][hm]
>> )
>> 
>> Position 2
>> 
>> (;GM[1]FF[4]
>> CA[UTF-8]
>> SZ[13]
>> HA[0]
>> KM[0.5]
>> AB[jb:mb][cb:cc][kc][bd:cd][jd:md][be][he][cf:df][bg][gb:gh]
>> [ig:ih][jh:kh][eg:ei][li][aj:bj][hi:hj][bk:ck][lk][al][cl]
>> [ji:jl][im]
>> AW[ia:la][ib][hc:jc][mc][db:dd][hd:id][ce:de][ie][ke:le][bf]
>> [hf:jf][lf][jg:kg][mg][lh][ai:di][gi][mi][cj][ej:gj][ij][dk:fk]
>> [hk:ik][dl][fl][il][bm:cm][em:fm][hm]
>> )
>> 
>> -M-
>> ___
>> computer-go mailing list
>> computer-go@computer-go.org
>> http://www.computer-go.org/mailman/listinfo/computer-go/
>
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Ing Challenge

[Hideki Kato]

David Fotland: <[EMAIL PROTECTED]>:
>The Ing prize stopped when Mr Ing died.  He was very interested in computer
>go.  His foundation still funds many go tournaments, but none for computers.
>
>The current computer go tournaments I know of are:
>
>European go congress (Late July)
>US go congress (August, small prize this year)
>Gifu Challenge in Japan (usually September or October, usually moderate
>prize) - http://www.computer-go.jp/gifu2005/English/outline/index.html
>Computer Olympiad (Beijing this October, usually no prize, pay to enter)
>UEC Cup, Japan, first one in 2007.  I don't know much about it.

2nd UEC Cup is planned at December 6 and 7, 2008.  I guess no prize.

-Hideki

>David
>
>
>> -Original Message-
>> From: [EMAIL PROTECTED] [mailto:computer-go-
>> [EMAIL PROTECTED] On Behalf Of Petr Baudis
>> Sent: Thursday, March 27, 2008 6:56 AM
>> To: computer-go
>> Subject: Re: [computer-go] Ing Challenge
>> 
>> On Wed, Mar 26, 2008 at 08:50:28PM -0700, David Fotland wrote:
>> > > You are right.
>> >
>> > Well, I did compete for this prize about 15 times, so I hope so :)
>> 
>> Are there any current prized computer tournaments or does anyone know
>> about Ing foundation or anyone else planning to resume the challenge?
>> What was the reason that it got interrupted, lack of fast enough
>> progress or simple reallocation of funds within the foundation?
>> 
>> --
>>  Petr "Pasky" Baudis
>> Whatever you can do, or dream you can, begin it.
>> Boldness has genius, power, and magic in it. -- J. W. von Goethe
>> ___
>> computer-go mailing list
>> computer-go@computer-go.org
>> http://www.computer-go.org/mailman/listinfo/computer-go/
>
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Paper for AAAI (David Silver) PDF problem

[Hideki Kato]

Hello,

I have the same problem with version 7.0.7 of Adobe Reader but
version 8.1.2 works fine.

Hope this helps,
Hideki

steve uurtamo: <[EMAIL PROTECTED]>:
>Hello,
>
>I'm getting the same thing here in windows:
>
>"Cannot extract the embedded font..."
>
>Was it made with pdflatex or somesuch?  Could
>it be a version issue there?
>
>s.
>
>On Mon, Apr 7, 2008 at 6:48 AM, Jacques Basaldúa <[EMAIL PROTECTED]> wrote:
>> Hi David
>>
>>
>> http://www.cs.ualberta.ca/~silver/research/publications/files/MoGoNectar.pdf
>>
>>  Your paper has a PDF problem concerning "embedded font BXGQFO+CMR12". I
>> have used
>>  different versions of Adobe Reader. I even updated one of the computers to
>> the latest version
>>  and I still cannot read any mathematical expressions. I guess this applies
>> to all Windows users.
>>
>>  Jacques.
>>  ___
>>  computer-go mailing list
>>  computer-go@computer-go.org
>>  http://www.computer-go.org/mailman/listinfo/computer-go/
>>
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Computer Go Forum

[Hideki Kato]

terry mcintyre: <[EMAIL PROTECTED]>:
>
>--- Erik van der Werf <[EMAIL PROTECTED]>
>wrote:
>
>> On Sat, May 3, 2008 at 8:49 AM, Joshua Shriver
>> <[EMAIL PROTECTED]> wrote:
>> > Is there a computer go forum?
>> 
>> http://www.computer-go.jp/

Thank you for remembering and annoucement of our forum, Erik :)

>Not quite what Joshua was looking for ;)

Agree :)

>The English-language page is not quite current with
>the Japanese version. The Japanese version describes a
>special meeting June 21,22. This meeting announcement
>does not appear on the English version.

As a member of CGF, I'd like to announce the meeting to the
subscribers of this list.  If you will be in Japan on June 21 and/or
22, please join our special meeting, which is an unofficial (exam)
tournament for the developers of computer go programs.  The meeing
will be held at 13F Daibiru which locates less than one minute from
Akihabara stn.

#We are sorry but our web page, not only English but also Japanse
version is not well managed these days as the site will move.

Hideki

>Terry McIntyre <[EMAIL PROTECTED]>
>
>“Wherever is found what is called a paternal government, there is found state 
>education. It
>has been discovered that the best way to insure implicit obedience is to 
>commence tyranny in
>the nursery.”
>
>Benjamin Disraeli, Speech in the House of Commons [June 15, 1874]
>
>
>  
> 
>Be a better friend, newshound, and 
>know-it-all with Yahoo! Mobile.  Try it now.
>http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

[computer-go] Re: Mogo scalability

[Hideki Kato]

David Fotland: <[EMAIL PROTECTED]>:
>The scalability study showed that mogo gains almost 100 rating points per
>doubling of performance.
>
>But on CGOS, there is mogo 1 CPU and mogo 4 CPU.  I would expect the 4 CPU
>mogo to be 150 rating points or more higher than 1 CPU.  But it is actually
>only 40 points higher.

I'm also wondering this for months.

One reason of this discount is that the MoGo bros running on cgos are 
the _big versions.  By my obserbation (they are running on my pcs and 
both are Q6600/3GHz with different mother boards), mogo_big_4core's 
perallelism is around 300% (by top command), perhaps due to its 
heavier uct part (just my guess).

>I guess this is because in the rating study mogo was mostly playing other
>mogo versions.  A the faster mogo can see everything the weaker mogo sees,
>and more.

I'm not sure.  Mogo_big_4core's winning rate against mogo_big_1core is 
about 60% (1641 / 2743) which corresponds only +70 ELO and current 
rating difference on cgos is about 40, as you wrote.  According to the 
scaling rule of mc playouts, it should be 160 ELO (log2(3) * 100 = 
158.5).

>But against other programs on CGOS, there will be weaknesses common to both
>fast and slow mogo, that other programs might exploit.
>
>Is the true scalability of mogo (against a variety of programs, or against
>people) less than the rating study indicates?

I believe their current ratings on cgos indicate so.

Hideki

>David
>
>
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Re: Mogo scalability

[Hideki Kato]

Olivier Teytaud: <[EMAIL PROTECTED]>:
>> One reason of this discount is that the MoGo bros running on cgos are
>> the _big versions.  By my obserbation (they are running on my pcs and
>> both are Q6600/3GHz with different mother boards), mogo_big_4core's
>> perallelism is around 300% (by top command), perhaps due to its
>> heavier uct part (just my guess).
>
>The top might overestimate the parallelization, as it depends the results 
>of top depend on how the locks are implemented. I don't know how was this
>part at the time of the release.
>
>With 4 cores, the
>current version of mogo is close to a speed-up four. I believed that the
>released version was quite similar from that point of view.

I recently checked so-called public relase 3 (essentially the same as 
the initial release, right?) as well and its 4 core version shows 
over 330% in top command.  So, I believe the big version doesn't have 
the same parallelism.

Does MoGo use simple mutex or some smarter locks?

I'd like to run newer version on cgos anyway :)

Hideki

>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

[computer-go] Shogi programs beat top amateurs

[Hideki Kato]

Today, at the 18th World Computer Shogi Championship, top two 
programs won against top amateur palyers in exihibition.
http://www.computer-shogi.org/index_e.html

The result of the tournament is here.
http://www.computer-shogi.org/wcsc18/index_e.html

You can replay the exhibition games here (in Japanese).
http://homepage.mac.com/junichi_takada/wcsc18/exhibition.html

The amateur players, Yukio Kato and Toru Shimizugami are current title 
holders and stroger than weaker professionals.

CSA stands for Computer Shogi Association (in Japan).  Shogi is a 
Chess like board game and is very popular in Japan but not in the 
world :(.  The search space is about 10^220 in Shogi where it's 10^300 
in 19x19 Go and 10^120 in Chess.

BTW, YSS, the champ of last year and the fourth today, is developed by
Hiroshi Yamashita, well known author of Aya.

-Hideki
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Re: Mogo scalability

[Hideki Kato]

Mark Boon: <[EMAIL PROTECTED]>:
>
>On 4-mei-08, at 14:57, Hideki Kato wrote:
>
>>  By my obserbation (they are running on my pcs and
>> both are Q6600/3GHz with different mother boards), mogo_big_4core's
>> perallelism is around 300% (by top command), perhaps due to its
>> heavier uct part (just my guess).
>
>Of course the CPU load doesn't really say how effective  
>parallelization is. Recently I bought an octo-core Mac and have been  
>running some tests. It takes time to get real conclusive data but I  
>have some observations that come purely from some testing and  
>watching. When using eight cores I get a speed-up of around six  
>times. That is in number of playouts per second. I think that's a  
>much more useful metric than looking at the CPU load.

Yes, of course.  It's just as wrote.

>Still, even number of playouts is not the end-all I believe. I have  
>the distinct impression that eight cores running for one second plays  
>considerably worse than one core running for six seconds, even though  
>the number of playouts is in the same ball-park. I haven't had the  
>time to do an extensive test on that yet but I'm convinced that the  
>picture is more complicated than just looking at total computing power.

I've wrote a paper about this issue for GPW 2007 (in Japanese).

Following is its English abstract.  Later half addresses this problem 
which parallel implementations of UCT show worse performance than 
single thread ones.  The cause is that uct part create and evaluate 
positions _before_ mc part (threads) finishes simulations 
completely.
--
A Study on Implementing Parallel MC/UCT Algorithm

HIDEKI KATO and IKUO TAKEUCHI

We have developed a parallel MC/UCT computer Go program as a test bed for our 
research,
applied recurrent neural networks. We measured the execution time of both 
commonly used
shared-tree and client-server implementations on two different types of 
systems, Intel Core
2 Quad on a PC and Cell Broadband Engine on a SONY PLAYSTATION 3. The 
client-server
implementation runs three times faster and 10% slower than shared-tree on the 
Playstation
3 and PC, respectively. Also, the effect of a well-known problem that 
parallelizing Monte
Carlo simulations may make UCT algorithm behave differently was evaluated with 
the winning
rates against GNU GO. Our experiments using four cores show that the winning 
rates
decrease 35 ELO at most and can be improved to 20 ELO.
---

-Hideki

>Mark
>
> inline file
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] 10k UCT bots

[Hideki Kato]

Álvaro Begué: <[EMAIL PROTECTED]>:
>Ooops! I hit sent before I finished writing the pseudo code. Sorry.
>
>int pick(Move *empties, int num_empties) {
> int num_candidates = num_empties;
> int picked;
>
> while(1) {
>   picked = rand()%num_candidates;

This code introduces few bias unless num_candidates is a power of two,
though.
#Assuming rand() returns [0 .. power of two).

-Hideki

>   if(!acceptable(empties[picked])) {
> num_candidates--;
> swap(empties[picked],empties[num_candidates]);
>   }
>   else
> break;
> }
> return picked;
>}
>
>
>
>On Tue, May 13, 2008 at 1:57 PM, Álvaro Begué <[EMAIL PROTECTED]> wrote:
>> On Tue, May 13, 2008 at 1:51 PM, Mark Boon <[EMAIL PROTECTED]> wrote:
>>  >
>>  > On 13-mei-08, at 14:10, Álvaro Begué wrote:
>>  >
>>  >
>>  > What others do is the right thing to do. Your method will introduce
>>  >
>>  > some biases.
>>  > Could you elaborate what bias it could lead to? I also do the same as 
>> Jason.
>>  > I did consider the possibility of a bias but couldn't immediately think of
>>  > one.
>>
>>  This has been explained already. After the first eye appears on the
>>  board, the first empty point after the eye has a probability of being
>>  picked that is twice the probability of any other empty point.
>>
>>
>>  > What good does moving it to the end of the list do? Next time around it's
>>  > just as likely to be picked as when left in place. Or do you only process
>>  > the 'end' after the 'front' moves are all tried?
>>
>>  You move it to the end and you reduce the number of candidates by one.
>>  The code is roughly this:
>>
>>  int pick(Move *empties, int num_empties) {
>>   int num_candidates = num_empties;
>>   int picked;
>>
>>   do {
>> picked = rand()%num_candidates;
>> num_candidates--;
>>   } while(!acceptable(empties[picked]);
>>
>>   return picked;
>>  }
>>
>>
>>  Álvaro.
>>
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] 10k UCT bots

[Hideki Kato]

I didn't against you, Álvaro, rather I just made a caution for
programmers who will use your pseudo code as is. :)

First, I prefer SFMT (SIMD-oriented Fast Mersenne Twister) rather
than integer pseudo random number generators in practice where the
quality of play-out is important.  Modern processors execute floating
operations as fast as interger ones and
picked = mt_rand() * (double) num_candidates;
is the simplest and safe. 
http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/index.html
#Converting int to double is, in fact, not so fast that
using double num_candidate through out the code may be faster.

When using integer pseudo random number generators and keeping exact
uniform distribution, following code can be used (slower twice).
This discards extra random numbers that bias the distribution.
#As Álvaro wrote, if n << RAND_MAX the bias is very small and may be
ignored.

unsigned long exactly_uniform_random(unsigned long n) { 
  unsigned long m, r; 
  if  (n == 0) return 0; 
  m = RAND_MAX % n; 
  do { 
r = rand(); 
  } while (r <= m) ; 
  return r % n; 
} 

In addition, xor_shift is better than builtin rand() and faster and
much smaller than MT.  #Hiroshi, the author of Aya, uses this.
http://en.wikipedia.org/wiki/Xorshift
http://www.jstatsoft.org/v08/i14/paper

unsigned long xorshiftrand(void) { 
  static unsigned long
x=123456789, y=362436069,
z=521288629, w=88675123; 
  unsigned long t; 
  t = x ^ (x << 11);
  x = y; y = z; z = w;
  return w = (w ^ (w >> 19)) ^ (t ^ (t >> 8)); 
} 

-Hideki

Álvaro Begué: <[EMAIL PROTECTED]>:
>On Tue, May 13, 2008 at 11:57 PM, Hideki Kato <[EMAIL PROTECTED]> wrote:
>>
>>  Álvaro Begué: <[EMAIL PROTECTED]>:
>>  >Ooops! I hit sent before I finished writing the pseudo code. Sorry.
>>  >
>>  >int pick(Move *empties, int num_empties) {
>>  > int num_candidates = num_empties;
>>  > int picked;
>>  >
>>  > while(1) {
>>  >   picked = rand()%num_candidates;
>>
>>  This code introduces few bias unless num_candidates is a power of two,
>>  though.
>>  #Assuming rand() returns [0 .. power of two).
>
>Oh, please. I should probably just take that as a provocation and
>ignore it, but I am weak. :)
>
>The pseudo-code I posted was meant to illustrate the process by which
>you move an element to the end and then exclude it from the lottery.
>rand()%num_candidates is just a quick way of telling the reader "pick
>a random integer in [0,num_candidates)".
>
>Besides, some people didn't care if a point had probability that was
>twice as large as the rest. In my system, RAND_MAX is 2147483647,
>which means that in the worst case, some points will have a
>probability that is a factor of 5948709/5948708=1.0016810372941485
>larger than the rest. Even I can live with that.
>
>Preemptive argument: Now someone will point out that the last few bits
>of rand() may not be very random in some common implementations, so in
>the case where num_candidates is a power of two I may have some
>biases. Please, reread two paragraphs above, or substitute rand() with
>the Mersenne twister.
>
>
>Álvaro.
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

[computer-go] Re: Mogo scalability

[Hideki Kato]

David, I just remembered that the scalability test was done without 
any opening book!

This could be the reason of their different scalablities.

-Hideki

David Fotland: <[EMAIL PROTECTED]>:
>The scalability study showed that mogo gains almost 100 rating points per
>doubling of performance.
>
>But on CGOS, there is mogo 1 CPU and mogo 4 CPU.  I would expect the 4 CPU
>mogo to be 150 rating points or more higher than 1 CPU.  But it is actually
>only 40 points higher.
>
>I guess this is because in the rating study mogo was mostly playing other
>mogo versions.  A the faster mogo can see everything the weaker mogo sees,
>and more.
>
>But against other programs on CGOS, there will be weaknesses common to both
>fast and slow mogo, that other programs might exploit.
>
>Is the true scalability of mogo (against a variety of programs, or against
>people) less than the rating study indicates?
>
>David
>
>
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

[computer-go] Re: Random (was: 10k UCT bots)

[Hideki Kato]

I also am not an expert of pseudo random number generator, Heikki.

It's very hard to estimate the effect of the quality of PRNG in MC 
simulations.  The only way is to compare their performance using your 
program, I believe.

I know that the generating speed of SFMT, about one nano second each 
on modern 3GHz processors with SSE2, is fast enough for my program and 
hardware, ie, neglegible in profile. So I didn't try other, known not 
better than MT in MC simulations, generators.
http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/speed.html

One thing I could say is that xor_shift could be faster than Park - 
Miller's but the difference must be neglegible.

How many times PRNG are called in one play-out?  Upto a few thousands 
for larger boards.  So, it would be better not being bothered by 
selecting PRNGs :).

-Hideki

Heikki Levanto: <[EMAIL PROTECTED]>:
>> In addition, xor_shift is better than builtin rand() and faster and
>> much smaller than MT.  
>
>I don't know that much about random numbers, so excuse my ignorance. But a
>bit of googling got me to the Park - Miller Minimal Standard random number
>generator 
>   http://www.firstpr.com.au/dsp/rand31/p1192-park.pdf
>
>>From what I read, it should be quite sufficient for go programs. It is
>dead simple and fast:
>
>long int pmrand() {
>const long int a=16807;
>const long int m= ( 1 << 31 ) -1;
>pmrandseed = ( pmrandseed * a ) % m ;
>return pmrandseed;
>} /* pmrand */
>
>
>Should I worry about this not being good enough? 
>
>  - Heikki
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

[computer-go] Re: aya bot handicap error?

[Hideki Kato]

Peter, I've checked the game record and felt nothing unnatural as 
a classical weaker bot.
#I've played against AyaBot series (AyaBot, AyaBot2...4) 59 games 
in total on KGS.

Please note that AyaBot (not AyaMC) is not an MC bot but a classical 
one.  Its moves are generated by patterns and selected based on 
estimated final scores.  It can't count exact scores which MC bots 
can easily and pricisely, rather sometime misjudges L&D at the end of 
games.  So, it's not a big problem even if it has a bug you pointed 
out :).

-Hideki (gghideki on KGS)

Peter Christopher: <[EMAIL PROTECTED]>:
>Hi I am just wondering if Aya bot has a handicap stone playout scoring 
>bug, in which it does not take account for handicap stones the same way 
>as kgs.  I just played against it on kgs (peterchris vs AyaBot4) and 
>about 80% into this game I made a huge error that should have cost me 
>the game, but Aya was kind enough from that point on to think VERY fast 
>(as if it knew it was going to win) playing excessively safe wins and 
>allowing me to win by 3.5 points (according to kgs scoring).
>Peter
>
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Random

[Hideki Kato]

Following url may help.
http://softwarecommunity.intel.com/isn/Community/en-US/forums/thread/30235396.aspx

-Hideki

Michael Williams: <[EMAIL PROTECTED]>:
>I don't think Don was saying to use many calls to RDTSC to generate a single 
>random number.
>I think he meant do something like (FastBadRand() XOR RDTSC).
>The first part has low quality low-order bits and the second part has low 
>quality high-order 
>bits.
>
>Also, I can't imagine why executing a RDTSC would take 50 cycles.  But I 
>couldn't find any 
>docs on that aspect of the instruction.
>
>
>
>steve uurtamo wrote:
>> the only thing to watch is that you'll likely need
>> 30+ bits from these guys to seed a prng, and
>> getting those bits in any organized way is likely
>> going to happen on a regular schedule (i.e. if
>> you get them in a loop, you're likely going to
>> space them out in an organized way).
>> 
>> s.
>> 
>> 
>> On 5/15/08, Don Dailey <[EMAIL PROTECTED]> wrote:
>>> For a long time I have pondered whether you could build a very high quality
>>> random number generator that was extremely fast using the pentium RDTSC
>>> instruction as a low order bit entropy source. The idea would be to use
>>> an extremely fast (but low quality) pseudo random number generator,  but
>>> modify the output (or the internal state of the generator) with the time
>>> stamp register at each call.
>>>
>>> RDTSC reads the pentiums internal clock and is basically just a 64 bit
>>> counter.However it increments very quickly and could be viewed as an
>>> entropy source in the lowest bits as it would introduce at least a little
>>> bit of non-determinism, and I think a little is all you would need to
>>> transform a horrible generator into a good practical one for many
>>> applications.   I  think the lowest 2 or 3 (or more)  bits would appear to
>>> modern processors as almost unpredictable since there is so much going on
>>> inside modern computers that are unpredictable.
>>> I don't know if the call to RDTSC is fast or how it would affect the
>>> parallelism of todays modern machines.   I'm not particularly interested in
>>> non-deterministic generators as I sometimes depend on this for testing and
>>> debugging,  but it's an idea I thought I would throw out there.
>>> - Don
>>>
>>>
>>>
>>>
>>>
>>> Don Dailey wrote:
 If you are looking for a cheap fast and simple random number generator,  A
>>> post by George Marsaglia, an expert/guru on random number generation has
>>> several and a C implemention.
 These are one line generators,  coded as macros.He also discusses the
>>> period and quality of each of them. This is a gem of a post  on
>>> sci.stat.math,sci.math  if you are interested in RNG:
   http://www.math.niu.edu/~rusin/known-math/99/RNG

 - Don



 Heikki Levanto wrote:

>> In addition, xor_shift is better than builtin rand() and faster and
>> much smaller than MT.
>>
> I don't know that much about random numbers, so excuse my ignorance. But
>>> a
> bit of googling got me to the Park - Miller Minimal Standard random
>>> number
> generator
>>> http://www.firstpr.com.au/dsp/rand31/p1192-park.pdf
> >From what I read, it should be quite sufficient for go programs. It is
> dead simple and fast:
>
> long int pmrand() {
>const long int a=16807;
>const long int m= ( 1 << 31 ) -1;
>pmrandseed = ( pmrandseed * a ) % m ;
>return pmrandseed;
> } /* pmrand */
>
>
> Should I worry about this not being good enough?
>  - Heikki
>
>
>
>
>
 ___
 computer-go mailing list
 computer-go@computer-go.org
 http://www.computer-go.org/mailman/listinfo/computer-go/


>>> ___
>>> computer-go mailing list
>>> computer-go@computer-go.org
>>> http://www.computer-go.org/mailman/listinfo/computer-go/
>>>
>> ___
>> computer-go mailing list
>> computer-go@computer-go.org
>> http://www.computer-go.org/mailman/listinfo/computer-go/
>> 
>
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

[computer-go] mogo-pr-4core on cgos 9x9

[Hideki Kato]

Dear CGOS watchers, :)

Mogo-pr-4core is the public release (not big float) version of MoGo 
and running on Intel Q9550, latest 45nm chip of Core2 micro 
architecture with larger L2 cache (2 x 6MB), at 3.4 GHz (8.5 
x 400MHz; overclocked from rated 2.83GHz) on ASUS 
P5K-VM motherboard.

Its performance is almost tie against mogo-big-4core but seems better 
to others.  Somewhat interesting.

-Hideki
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

[computer-go] Re: Shogi programs beat top amateurs

[Hideki Kato]

Here is a report by Reijer Grimbergen, associate professor at 
Yamagata University in Japan and author of a Shogi program Spear 
which was 12nd at the tournament. 

His report is very interesting, dramatic and should 
make you were at the tournament even if you know nothing about 
Shogi.

The 18th CSA World Computer Shogi Championships
http://gamelab.yz.yamagata-u.ac.jp/SHOGI/CSA2008/18csa.html

-Hideki

Hideki Kato: <[EMAIL PROTECTED]>:
>Today, at the 18th World Computer Shogi Championship, top two 
>programs won against top amateur palyers in exihibition.
>http://www.computer-shogi.org/index_e.html
>
>The result of the tournament is here.
>http://www.computer-shogi.org/wcsc18/index_e.html
>
>You can replay the exhibition games here (in Japanese).
>http://homepage.mac.com/junichi_takada/wcsc18/exhibition.html
>
>The amateur players, Yukio Kato and Toru Shimizugami are current title 
>holders and stroger than weaker professionals.
>
>CSA stands for Computer Shogi Association (in Japan).  Shogi is a 
>Chess like board game and is very popular in Japan but not in the 
>world :(.  The search space is about 10^220 in Shogi where it's 10^300 
>in 19x19 Go and 10^120 in Chess.
>
>BTW, YSS, the champ of last year and the fourth today, is developed by
>Hiroshi Yamashita, well known author of Aya.
>
>-Hideki
>--
>[EMAIL PROTECTED] (Kato)
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] 10k UCT bots

[Hideki Kato]

Gunnar Farnebäck: <[EMAIL PROTECTED]>:
>Hideki Kato wrote:
> > I didn't against you, Álvaro, rather I just made a caution for
> > programmers who will use your pseudo code as is. :)
> >
> > First, I prefer SFMT (SIMD-oriented Fast Mersenne Twister) rather
> > than integer pseudo random number generators in practice where the
> > quality of play-out is important.  Modern processors execute floating
> > operations as fast as interger ones and
> > picked = mt_rand() * (double) num_candidates;
> > is the simplest and safe.
>
>Please note that for uniformity purists this method has exactly the
>same problem as good_quality_int_rand() % num_candidates.

Mt_rand() has very good uniform distributions in [0..1)
while
good_quality_int_rand() % num_candidates
doesn't disribute uniformly when num_candidates is not a power of 2,
assuming good_quality_int_rand() ranges [0..2^32 or so) due to modulo
operations.  They are not the same, aren't they?

-Hideki

>/Gunnar
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] 10k UCT bots

[Hideki Kato]

Assumming good_quality_int_rand() ranges [0..15] and N is 9, the
mapping is 0->0, 1->1, ..., 8->8, 9->0, ..., 15->6.  This shows 0 to 6
have twice of the chance of 7 and 8.  This is the bias caused by
the modulo operation.

In addition,
>multiplication + rounding.
may return N.  Use trancate instead for the range [0..N).
#I used float instead of double and also got N (very rare). Please be
careful.

-Hideki

Gunnar Farnebäck: <[EMAIL PROTECTED]>:
>Hideki Kato wrote:
>> Gunnar Farnebäck: <[EMAIL PROTECTED]>:
>>> Hideki Kato wrote:
>>>> I didn't against you, Álvaro, rather I just made a caution for
>>>> programmers who will use your pseudo code as is. :)
>>>>
>>>> First, I prefer SFMT (SIMD-oriented Fast Mersenne Twister) rather
>>>> than integer pseudo random number generators in practice where the
>>>> quality of play-out is important.  Modern processors execute floating
>>>> operations as fast as interger ones and
>>>>picked = mt_rand() * (double) num_candidates;
>>>> is the simplest and safe.
>>> Please note that for uniformity purists this method has exactly the
>>> same problem as good_quality_int_rand() % num_candidates.
>> 
>> Mt_rand() has very good uniform distributions in [0..1)
>> while
>> good_quality_int_rand() % num_candidates
>> doesn't disribute uniformly when num_candidates is not a power of 2, 
>> assuming good_quality_int_rand() ranges [0..2^32 or so) due to modulo 
>> operations.  They are not the same, aren't they?
>
>Well, there's nothing magic about floating point numbers. Even a very 
>good uniform distribution in some interval is implemented by 
>distributing N discrete values over the interval as uniformly as 
>possible. When those N values by some mapping procedure are transformed 
>into a smaller range M, some of those will get at least one more hit 
>than some others, unless M divides N. It doesn't matter whether the 
>mapping procedure is an integer modulo operation or a floating point 
>multiplication + rounding.
>
>/Gunnar
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] 10k UCT bots

[Hideki Kato]

Thank you for detailed explanation.  I've understood well now.

It's essentially the mapping problem from [0..N) to [0..M) where
N > M and N % M != 0  or N is greater than M and M don't divide N.
The frequencies of the mapping have to have the least difference, one
(unless discarding extra part of source, mentioned in my previous
post).

The modulo operation, however, is not preferable because it
introduces very systematic bias, smaller numbers always have the
bonus for every M.  In this sense, multiply and divide operations are
not the same as modulo.

Thanks again,
Hideki

Gunnar Farnebäck: <[EMAIL PROTECTED]>:
>I wrote:
> > Hideki Kato wrote:
> >> Gunnar Farnebäck: <[EMAIL PROTECTED]>:
> >>> Hideki Kato wrote:
> >>>> I didn't against you, Álvaro, rather I just made a caution for
> >>>> programmers who will use your pseudo code as is. :)
> >>>>
> >>>> First, I prefer SFMT (SIMD-oriented Fast Mersenne Twister) rather
> >>>> than integer pseudo random number generators in practice where the
> >>>> quality of play-out is important.  Modern processors execute floating
> >>>> operations as fast as interger ones and
> >>>> picked = mt_rand() * (double) num_candidates;
> >>>> is the simplest and safe.
> >>> Please note that for uniformity purists this method has exactly the
> >>> same problem as good_quality_int_rand() % num_candidates.
> >>
> >> Mt_rand() has very good uniform distributions in [0..1)
> >> while
> >> good_quality_int_rand() % num_candidates
> >> doesn't disribute uniformly when num_candidates is not a power of 2,
> >> assuming good_quality_int_rand() ranges [0..2^32 or so) due to modulo
> >> operations.  They are not the same, aren't they?
> >
> > Well, there's nothing magic about floating point numbers. Even a very
> > good uniform distribution in some interval is implemented by
> > distributing N discrete values over the interval as uniformly as
> > possible. When those N values by some mapping procedure are transformed
> > into a smaller range M, some of those will get at least one more hit
> > than some others, unless M divides N. It doesn't matter whether the
> > mapping procedure is an integer modulo operation or a floating point
> > multiplication + rounding.
>
>It seems like this short explanation was too abstract. Let's try with
>a more concrete one.
>
>The function dsfmt_genrand_close1_open2 in the file dSFMT.h from
>dSFMT-src-1.3, downloadable from
>http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/index.html,
>generates uniformly distributed double precision floating point
>numbers in the interval 1 <= x < 2.  This is done by taking uniformly
>distributed 52 bit integers and placing those as the least significant
>bits of a 64 bit IEEE 754 double precision floating point number with
>the bit pattern
>
>0 011 y,
>
>where y denotes the 52 bits uniformly distributed integer. This is
>interpreted as the floating point number with value
>
>x = 1 + y / 2^52
>
>The function dsfmt_genrand_close_open generates uniformly distributed
>double precision floating point numbers in the interval 0 <= x < 1
>simply by subtracting one from the numbers above. These are still
>exactly representable by IEEE754 double precision floating point
>numbers although their bit representations become somewhat more
>involved due precisely to the point floating around.
>
>Thus we now have the uniform integer distribution 0, ..., 2^52-1
>mapped onto the floating point numbers 0, 1*2^(-52), 2*2^(-52), ...,
>(2^52-1)*2^(-52).
>
>Next we multiply this by num_candidates and round down to the nearest
>integer. Let's say that num_candidates is 7. Then the 52 bit integers
>are mapped onto the interval 0, 1, 2, 3, 4, 5, 6 so that
>
>0 -  643371375338642 are mapped to 0
>  643371375338643 - 1286742750677284 are mapped to 1
>1286742750677285 - 1930114126015926 are mapped to 2
>1930114126015927 - 2573485501354569 are mapped to 3
>2573485501354570 - 3216856876693211 are mapped to 4
>3216856876693212 - 3860228252031853 are mapped to 5
>3860228252031854 - 4503599627370495 are mapped to 6
>
>This means that moves 0, 3 have a relative chance of 643371375338643
>to be chosen whereas moves 1, 2, 4, 5, 6 have a relative chance of
>only 643371375338642. Of course this is for almost any purpose
>negligible but it is exactly the same bias you get by taking a
>uniformly distributed 52-bit integer modulo 7, except that then it's
>the moves 0 and 1 that are favored instead of 0 and 3

[computer-go] Re: 10k UCT bots

[Hideki Kato]

I wrote:
>In addition, xor_shift is better than builtin rand() and faster and 
>much smaller than MT. 
but it's wrong.  Sorry all.

I found recently a comparison at
http://www001.upp.so-net.ne.jp/isaku/rand.html (in Japanese).

Time to generate 10^8 pesudorandom numberson a Core 2 Duo E6600 + 
VS2005:
 zsfmt(SSE2)   :  156ms
 SFMT(SSE2):  156ms
 zmtrand(SSE2) :  250ms
 zxor  :  265ms
 zmtrand   :  266ms
 xor128()  :  328ms
 zsfmt :  375ms
 mt19937ar :  625ms
 SFMT  : 1046ms
 rand(): 1969ms

unsigned long xor128(){ 
static unsigned long x=123456789,y=362436069,z=521288629,w=88675123; 
unsigned long t; 
t=(x^(x<<11));x=y;y=z;z=w; return( w=(w^(w>>19))^(t^(t>>8)) ); 
} 
http://www.jstatsoft.org/v08/i14/

This shows SFMT/SSE2 is the fastest and twice faster than xor_shift 
(at least on that environment).

-Hideki

Hideki Kato: <[EMAIL PROTECTED]>:
>I didn't against you, ?lvaro, rather I just made a caution for 
>programmers who will use your pseudo code as is. :)
>
>First, I prefer SFMT (SIMD-oriented Fast Mersenne Twister) rather 
>than integer pseudo random number generators in practice where the 
>quality of play-out is important.  Modern processors execute floating 
>operations as fast as interger ones and
>   picked = mt_rand() * (double) num_candidates;
>is the simplest and safe. 
>http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/index.html
>#Converting int to double is, in fact, not so fast that 
>using double num_candidate through out the code may be faster.
>
>When using integer pseudo random number generators and keeping exact 
>uniform distribution, following code can be used (slower twice).  
>This discards extra random numbers that bias the distribution.
>#As ?lvaro wrote, if n << RAND_MAX the bias is very small and may be 
>ignored.
>
>unsigned long exactly_uniform_random(unsigned long n) { 
>  unsigned long m, r; 
>  if  (n == 0) return 0; 
>  m = RAND_MAX % n; 
>  do { 
>r = rand(); 
>  } while (r <= m) ; 
>  return r % n; 
>} 
>
>In addition, xor_shift is better than builtin rand() and faster and 
>much smaller than MT.  #Hiroshi, the author of Aya, uses this.
>http://en.wikipedia.org/wiki/Xorshift
>http://www.jstatsoft.org/v08/i14/paper
>
>unsigned long xorshiftrand(void) { 
>  static unsigned long
>x=123456789, y=362436069,
>z=521288629, w=88675123; 
>  unsigned long t; 
>  t = x ^ (x << 11);
>  x = y; y = z; z = w;
>  return w = (w ^ (w >> 19)) ^ (t ^ (t >> 8)); 
>} 
>
>-Hideki
>
>?lvaro Begu?: <[EMAIL PROTECTED]>:
>>On Tue, May 13, 2008 at 11:57 PM, Hideki Kato <[EMAIL PROTECTED]> wrote:
>>>
>>>  ?lvaro Begu?: <[EMAIL PROTECTED]>:
>>>  >Ooops! I hit sent before I finished writing the pseudo code. Sorry.
>>>  >
>>>  >int pick(Move *empties, int num_empties) {
>>>  > int num_candidates = num_empties;
>>>  > int picked;
>>>  >
>>>  > while(1) {
>>>  >   picked = rand()%num_candidates;
>>>
>>>  This code introduces few bias unless num_candidates is a power of two,
>>>  though.
>>>  #Assuming rand() returns [0 .. power of two).
>>
>>Oh, please. I should probably just take that as a provocation and
>>ignore it, but I am weak. :)
>>
>>The pseudo-code I posted was meant to illustrate the process by which
>>you move an element to the end and then exclude it from the lottery.
>>rand()%num_candidates is just a quick way of telling the reader "pick
>>a random integer in [0,num_candidates)".
>>
>>Besides, some people didn't care if a point had probability that was
>>twice as large as the rest. In my system, RAND_MAX is 2147483647,
>>which means that in the worst case, some points will have a
>>probability that is a factor of 5948709/5948708=1.0016810372941485
>>larger than the rest. Even I can live with that.
>>
>>Preemptive argument: Now someone will point out that the last few bits
>>of rand() may not be very random in some common implementations, so in
>>the case where num_candidates is a power of two I may have some
>>biases. Please, reread two paragraphs above, or substitute rand() with
>>the Mersenne twister.
>>
>>
>>?lvaro.
>>___
>>computer-go mailing list
>>computer-go@computer-go.org
>>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

[computer-go] Re: Mogo scalability

[Hideki Kato]

I run no opening book versions of MoGo_big with one and two threads 
on a quad core box, Intel Q6600 at 3GHz, on which mogo_big_1core is 
running, namely mogo_big_1c_nb and mogo_big_2c_nb on cgos 9x9.

They show good scalability now, though the number of games is not 
enough yet.  One strange thing is that mogo_big_2c seems not weaker 
than mogo-big-4core.
http://cgos.boardspace.net/9x9/standings.html

-Hideki

Hideki Kato: <[EMAIL PROTECTED]>:
>David, I just remembered that the scalability test was done without 
>any opening book!
>
>This could be the reason of their different scalablities.
>
>-Hideki
>
>David Fotland: <[EMAIL PROTECTED]>:
>>The scalability study showed that mogo gains almost 100 rating points per
>>doubling of performance.
>>
>>But on CGOS, there is mogo 1 CPU and mogo 4 CPU.  I would expect the 4 CPU
>>mogo to be 150 rating points or more higher than 1 CPU.  But it is actually
>>only 40 points higher.
>>
>>I guess this is because in the rating study mogo was mostly playing other
>>mogo versions.  A the faster mogo can see everything the weaker mogo sees,
>>and more.
>>
>>But against other programs on CGOS, there will be weaknesses common to both
>>fast and slow mogo, that other programs might exploit.
>>
>>Is the true scalability of mogo (against a variety of programs, or against
>>people) less than the rating study indicates?
>>
>>David
>>
>>
>>___
>>computer-go mailing list
>>computer-go@computer-go.org
>>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Congratulations to AyaMC and to StoneGrid!

[Hideki Kato]

Thank you for a long, very interesting report, Nick.

I found a typo(?), however, about the version of HBotSVN.  Jason wrote
earlier games were played by r761 but you wrote by r763.

-Hideki

Nick Wedd: <[EMAIL PROTECTED]>:
>In message 
><[EMAIL PROTECTED]>, Jason 
>House <[EMAIL PROTECTED]> writes
>>Is it possible to show the board for the round 1 open division game? 
>>You refer specifically to a choice made at move 60...
>
>I have added a diagram.  But it turns out my analysis was wrong, I now 
>think that by move 60 White had no way of winning.
>
>>Also, the processor description for HBotSVN is incorrect.  Rounds 1-6
>>were through a virtual machine on a box with a 2GHz Intel Core Duo.   
>>Rounds 7-9 was running native on a Dual Core T2330 (1.6GHz/533Mhz
>>FSB/1MB cache).
>>
>>It also turns out that rounds 7-9 were run with a newer version of the
>>bot.  IIRC, they ran with HouseBot 0.7 r763 while the earlier rounds
>>were run with HouseBot 0.7 r761.
>
>Ok, I have corrected this, thank you for telling me.
>
>Nick
>
>>On Mon, Jun 16, 2008 at 12:33 PM, Nick Wedd <[EMAIL PROTECTED]> wrote:
>>  AyaMC and StoneGrid were the winners of yesterday's KGS bot
>>  tournament, both undefeated, with 6/6 and 9/9 wins respectively.  My
>>  report is at
>>  http://www.weddslist.com/kgs/past/39/index.html
>>
>>  It is longer than usual, because I found quite a few of the games
>>  interesting.
>>
>>  Nick
>>  --
>>  Nick Wedd   [EMAIL PROTECTED]
>>  ___
>>  computer-go mailing list
>>  computer-go@computer-go.org
>>  http://www.computer-go.org/mailman/listinfo/computer-go/
>>___
>>computer-go mailing list
>>computer-go@computer-go.org
>>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Ladders and UCT

[Hideki Kato]

>>>while(((white_pass && black_pass ) == true) || tree_deep == 1000)
"while" should be "until".

-Hideki

WSK: <[EMAIL PROTECTED]>:
>Am 17.06.2008, 20:37 Uhr, schrieb Zach Wegner <[EMAIL PROTECTED]>:
>
>> On Mon, Jun 16, 2008 at 4:42 PM, WSK <[EMAIL PROTECTED]>  
>> wrote:
>>
>>> program oh_iam_sooo_quick_and_dirty;
>>>
>>> //get_input_move(input);
>>> .
>>> .
>>> .
>>> do
>>> {
>>>set_randomseed(); //sic! :)
>>>do
>>>{
>>>color = black;
>>>  if("pass" == play_random_move(color); // pass only if  
>>> there are NO VALID moves on board anymore!
>>>black_pass = true;
>>>else {
>>>set_move_to_tree(tree); //more complicated!!!
>>>   black_pass = false;
> }
> color = white;
>   
>>>if("pass" == play_random_move(color); // pass only if there are  
>>> NO VALID moves on board anymore!
>>>white_pass = true;
>>>else {
>>>set_move_to_tree(tree); //more complicated!!!
> white_pass = false;
>>>}
> tree_deep++;
> }
>>>while(((white_pass && black_pass ) == true) || tree_deep == 1000)
>>> set_next_root_tree(input);
>>> }
>>> while(time <= 10 sec)
>>> .
>>> .
>>> .
>>> program ends;
>>
>> A few small errors I see:
>>
>> 1. It should be while (pass < 2)
>> 2. It should be while (time < 10 sec)
>> 3. The way you do it only detects the end of the game when white
>> passes, then black passes. If black passes and then white does, it
>> won't catch it.
>> 4. Black plays before white
>
>1.+2.: Yes, its cleaner ;)
>
>3. Oh! Youre right, thanks! Hope it works now.
>
>4. Not a bug a feature! :) Because the first input would be black. But
>for transparency I edit it.
>
>Comments are welcome! (RFC if you want, lol)
>
>Greets
>
>> ___
>> computer-go mailing list
>> computer-go@computer-go.org
>> http://www.computer-go.org/mailman/listinfo/computer-go/
>
>
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] 2008 World 9x9 Computer Go Championship in Taiwan

[Hideki Kato]

I strongly believe Gifu Challenge will not come back any more.

#Please attend The 2nd UEC Cup, planned on December 13-14, 2008,
instead.

-Hideki

David Fotland: <[EMAIL PROTECTED]>:
>Is there any word on the Gifu tournament in Japan, which is usually in
>September?
>
>David
>
>> -Original Message-
>> From: [EMAIL PROTECTED] [mailto:computer-go-
>> [EMAIL PROTECTED] On Behalf Of Rémi Coulom
>> Sent: Tuesday, July 01, 2008 8:59 AM
>> To: computer-go
>> Subject: [computer-go] 2008 World 9x9 Computer Go Championship in
>> Taiwan
>> 
>> Hi,
>> 
>> This was just announced on the ICGA Tournaments web site:
>> http://go.nutn.edu.tw/eng/main_eng.htm
>> 
>> It is right before the Computer Olympiad, and registration is free for
>> participants in the Olympiad.
>> 
>> Rémi
>> ___
>> computer-go mailing list
>> computer-go@computer-go.org
>> http://www.computer-go.org/mailman/listinfo/computer-go/
>
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

[computer-go] Re: Operator needed

[Hideki Kato]

Magnus,

I'd like to provide my quad core pc to run Valkyria on cgos 9x9.  
It, however, will be used for my reseach experiments sometimes.  
If you could allow this, please send its binary for Linux to me.

-Hideki

Magnus Persson: <[EMAIL PROTECTED]>:
>I also see myself listed in the EGC tournament(I made a half promise  
>some time ago). I cannot go myself but fortunately Valkyria run in  
>Windows, and I can setup an easy to use Zip file for any volunteer.
>
>On this topic: I would also want to ask if there is any volunteer with  
>good hardware who would like to run Valkyria on CGOS. Unless I buy a  
>new computer myself I currently have no access to fast machines.  
>Preferable with 4 cores so that the scaling and stability of my thread  
>implementation can be tested. I am running on a 4-year old 1.4 Ghz  
>Pentium M, so it would be interesting to see the difference.
>
>Best
>Magnus
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

[computer-go] Re: kartoffel on cgos

[Hideki Kato]

I'm afraid that kartoffel may cause some confusion on the ratings.  
I've set mogo-big-4c-nb-32 never resign but this will help little.

I'd like to prefer every program never resign until the author of 
kartoffel fix the bug to prevent the ratings being corrupted.

-Hideki

John Fan: <[EMAIL PROTECTED]>:
>Seems it has a serious bug on end game against weak bots. Most of its losing
>games against weak bots lost on illegal move.
>
>On Fri, Jul 25, 2008 at 9:36 PM, John Fan <[EMAIL PROTECTED]> wrote:
>
>> kartoffel on cgos has a high winning ratings against strong bots, but
>> losing to weak bots. Its rating is only 1575, but has higher than 50%
>> against bots over 2200 ratings. Anybody knows what algorithm it uses?
>>
> inline file
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Re: kartoffel on cgos

[Hideki Kato]

Don Dailey: <[EMAIL PROTECTED]>:
>
>I don't think this has a very large impact on the rating pool.   It's 
>annoying, but it will all average out.   No extra points are leaving or 
>entering the rating pool as a result of this  so this will not cause 
>general inflation or deflation.It may cause a slight "compression" 
>effect where the lows and highs come closer together, but I believe this 
>will be minor. 

Sure, "compression" can be observed but I don't believe it's minor.  

The rating of mogo-big-4c-nb-32 is 2465 now (which could decrease more 
if allowed resign) while it had been over 2500 for months.  
This is one example and another is that the winning rate against 
mogo-big-4c-nb-32 of Salat is 50% (19/38) but its rating is 
only 2341, which should be over 2400 in former days, I believe.

-Hideki

>The next time I run the all time rating list,  I will see what happens 
>if I ignore kartoffel's games - just to see if this has much of an 
>impact.  
>
>- Don
>
>
>
>
>Hideki Kato wrote:
>> I'm afraid that kartoffel may cause some confusion on the ratings.  
>> I've set mogo-big-4c-nb-32 never resign but this will help little.
>>
>> I'd like to prefer every program never resign until the author of 
>> kartoffel fix the bug to prevent the ratings being corrupted.
>>
>> -Hideki
>>
>> John Fan: <[EMAIL PROTECTED]>:
>>   
>>> Seems it has a serious bug on end game against weak bots. Most of its losing
>>> games against weak bots lost on illegal move.
>>>
>>> On Fri, Jul 25, 2008 at 9:36 PM, John Fan <[EMAIL PROTECTED]> wrote:
>>>
>>> 
>>>> kartoffel on cgos has a high winning ratings against strong bots, but
>>>> losing to weak bots. Its rating is only 1575, but has higher than 50%
>>>> against bots over 2200 ratings. Anybody knows what algorithm it uses?
>>>>
>>>>   
>>>  inline file
>>> ___
>>> computer-go mailing list
>>> computer-go@computer-go.org
>>> http://www.computer-go.org/mailman/listinfo/computer-go/
>>> 
>> --
>> [EMAIL PROTECTED] (Kato)
>> ___
>> computer-go mailing list
>> computer-go@computer-go.org
>> http://www.computer-go.org/mailman/listinfo/computer-go/
>>
>>   
> inline file
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Re: kartoffel on cgos

[Hideki Kato]

Don Dailey: <[EMAIL PROTECTED]>:
>I can't think of any really clever way to handle this. Here is about 
>the best I can think of right now:
>
>Keep statistics on each program - how often it loses due to time or 
>illegal moves.   Use those statistics to reduce the impact of the rating 
>formula.   I could arrange it so that even if  10% of your games are 
>lost that way,   your rating becomes highly suspicious and given very 
>little weight in the rating formula.   This basically amounts to 
>treating the games of such players as if they were un-rated games.  

Nice idea, I believel this will work well.  Thank you, Don.

-Hideki

>- Don
> 
>
>
>
>
> 
>
>
>Hideki Kato wrote:
>> Don Dailey: <[EMAIL PROTECTED]>:
>>   
>>> I don't think this has a very large impact on the rating pool.   It's 
>>> annoying, but it will all average out.   No extra points are leaving or 
>>> entering the rating pool as a result of this  so this will not cause 
>>> general inflation or deflation.It may cause a slight "compression" 
>>> effect where the lows and highs come closer together, but I believe this 
>>> will be minor. 
>>> 
>>
>> Sure, "compression" can be observed but I don't believe it's minor.  
>>
>> The rating of mogo-big-4c-nb-32 is 2465 now (which could decrease more 
>> if allowed resign) while it had been over 2500 for months.  
>> This is one example and another is that the winning rate against 
>> mogo-big-4c-nb-32 of Salat is 50% (19/38) but its rating is 
>> only 2341, which should be over 2400 in former days, I believe.
>>
>> -Hideki
>>
>>   
>>> The next time I run the all time rating list,  I will see what happens 
>>> if I ignore kartoffel's games - just to see if this has much of an 
>>> impact.  
>>>
>>> - Don
>>>
>>>
>>>
>>>
>>> Hideki Kato wrote:
>>> 
>>>> I'm afraid that kartoffel may cause some confusion on the ratings.  
>>>> I've set mogo-big-4c-nb-32 never resign but this will help little.
>>>>
>>>> I'd like to prefer every program never resign until the author of 
>>>> kartoffel fix the bug to prevent the ratings being corrupted.
>>>>
>>>> -Hideki
>>>>
>>>> John Fan: <[EMAIL PROTECTED]>:
>>>>   
>>>>   
>>>>> Seems it has a serious bug on end game against weak bots. Most of its 
>>>>> losing
>>>>> games against weak bots lost on illegal move.
>>>>>
>>>>> On Fri, Jul 25, 2008 at 9:36 PM, John Fan <[EMAIL PROTECTED]> wrote:
>>>>>
>>>>> 
>>>>> 
>>>>>> kartoffel on cgos has a high winning ratings against strong bots, but
>>>>>> losing to weak bots. Its rating is only 1575, but has higher than 50%
>>>>>> against bots over 2200 ratings. Anybody knows what algorithm it uses?
>>>>>>
>>>>>>   
>>>>>>   
>>>>>  inline file
>>>>> ___
>>>>> computer-go mailing list
>>>>> computer-go@computer-go.org
>>>>> http://www.computer-go.org/mailman/listinfo/computer-go/
>>>>> 
>>>>> 
>>>> --
>>>> [EMAIL PROTECTED] (Kato)
>>>> ___
>>>> computer-go mailing list
>>>> computer-go@computer-go.org
>>>> http://www.computer-go.org/mailman/listinfo/computer-go/
>>>>
>>>>   
>>>>   
>>>  inline file
>>> ___
>>> computer-go mailing list
>>> computer-go@computer-go.org
>>> http://www.computer-go.org/mailman/listinfo/computer-go/
>>> 
>> --
>> [EMAIL PROTECTED] (Kato)
>> ___
>> computer-go mailing list
>> computer-go@computer-go.org
>> http://www.computer-go.org/mailman/listinfo/computer-go/
>>
>>   
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

[computer-go] Re: What Do You Need Most?

[Hideki Kato]

Though my program is not strong :), I bet new algorithms.

Especially, better (heavy)-playout with not only spatial features 
but also temporal ones, which gives small error of the score, and 
better uct part with some enhancement, perhaps, with RL.

-gg

Darren Cook: <[EMAIL PROTECTED]>:
>I have a strong interest in seeing a 19x19 computer go program that is
>at least 3-dan by 2010. The recent jump in strength on the 9x9 board has
>given me new hope and I want to ask people here, especially the authors
>of strong programs, what you now need to make the next jump in strength.
>There seem to be four broad categories:
>
> * More hardware (CPU cycles? Memory? Faster networking? Do you just
>need that hardware for offline tuning, or for playing too?)
>
> * More data
>
> * New algorithms (if so, to solve exactly what? evaluation? search? other?)
>
> * More community
>
>By community I mean things like this mailing list, CGOS, open source
>projects, etc.
>
>By data I mean things like: game records, or board positions, marked up
>with correct/incorrect moves; game records generally; pattern libraries;
>test suites; opening libraries.
>
>Darren
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] What Do You Need Most?

[Hideki Kato]

Mark Boon: <[EMAIL PROTECTED]>:
>Opposed to removing 9x9.
>
>In favor of adding 13x13 wthout removing 9x9.

Me too.  If, however, limited two 9x9 and 13x13 might be better now as 
19x19 is not so utilized, IMHO.  It's just early this year many 
programs started being running on 9x9.

I will donate too but no so much until I'll have a job :).

-Hideki

>I'd make a donation if it's easy as well. I doubt we're a big enough  
>crowd to pay for a VPS through $5 donations though... Better add an  
>option to enter a free amount as I'm not going to click a button  
>dozens of times.
>
> Mark
>
>On 31-jul-08, at 10:00, Don Dailey wrote:
>
>> Of course KGS is certainly more polished than CGOS.
>>
>> However, it looks like we can eventually solve the growing pains of
>> CGOS, I am working on something now.
>>
>> My question to the group, especially those using CGOS, is whether you
>> would be in favor, or opposed to replacing 9x9 with 13x13?
>>
>> - Don
>>
>>
>>
>> On Thu, 2008-07-31 at 08:05 -0400, Jason House wrote:
>>> On Jul 30, 2008, at 6:55 PM, Don Dailey <[EMAIL PROTECTED]> wrote:
>>>
 I think someone already has a website somewhere where they try to  
 rank
 bots based on KGS games.
>>>
>>> I'm pretty sure the site stopped doing rankings when KGS moved to
>>> gokgs.com
>>>
>>>
 If you can figure out how to make it
 schedule games fairly and consistently then go for it.
>>>
>>> I doubt you'd get the CGOS style for either of these out of the box.
>>>
>>> Scheduling for automatch is likely a first-come, first-serve basis,
>>> probably with some kind of anti-repeat feature. Having engines
>>> reconnect at the start of a round could help fairness issues.
>>> Randomized connection times could be helpful too.
>>>
>>> KGS would limit games to within 9 stones and would automatically give
>>> handicap, but I consider that a good thing.
>>>
>>> Obviously, the more wms helps (or lets us provide code, the better
>>> things will be. I doubt we'd get anywhere without Nick Wedd backing
>>> the idea, and he probably wouldn't if you don't. A KGS alternative  
>>> may
>>> never be as good as a custom computer go server, but if it's  
>>> close, it
>>> has other side benefits... Game caches, wider human audiences,
>>> potential integration with human play, etc
>>>
>>>
>>>
>>>
>>>
>>>
 I want to be
 able to put my bot on line,  leave it alone for a day or more,  and
 know
 it will play only other computers under a consistent rule set and
 get a
 ranking.  Also I want to know that you can't just disconnect and to
 abort lost games.  I don't want the same player playing it 20 games
 in a
 row and so on.   If you can get all that to happen without WMS
 support,
 then I'm definitely interested.


 - Don



 On Wed, 2008-07-30 at 18:20 -0400, Jason House wrote:
> Where there's a will, there's a way. It may not be hard to use auto
> match with the self-proclamed bot ranks as a first step
> approximation.
> All that's needed for that is to allow bots to be paired against  
> each
> other. Ratings could be computed offline and used by a kgsGtp  
> wrapper
> to update the self-proclaimed ratings between games.
>
> Everything else could be incremental tweaks as issues are  
> identified.
>
> Sent from my iPhone
>
> On Jul 30, 2008, at 5:07 PM, Don Dailey <[EMAIL PROTECTED]> wrote:
>
>> I like KGS and the maturity of it compared to CGOS.   However,
>> it's a
>> different problem.   KGS doesn't schedule games for you.
>>
>> I also tried to persuade WMS to rate 9x9 bot games, but he was
>> unwilling
>> to add more indexes and overhead to the database.   And even if he
>> agreed, sometimes I want to play other bots, although I like the
>> idea of
>> being able to play humans when I want that.   Still,  it's a
>> scheduling
>> issue that KGS just doesn't support.
>>
>> If WMS had made a computer go server that looks like KGS but does
>> the
>> scheduling and rating for bots only (or given a choice with humans
>> too)
>> and such, I would have never written CGOS.   If he does it  
>> later, I
>> would probably prefer it to CGOS and would use it instead.
>>
>> - Don
>>
>>
>>
>>
>>
>> On Wed, 2008-07-30 at 15:35 -0400, Jason House wrote:
>>> Maybe we should approach wms about using KGS. Rank and pairings
>>> could
>>> be computed separately. Once upon a time, there was a page that
>>> computed 9x9 bot ratings
>>>
>>> Sent from my iPhone
>>>
>>> On Jul 30, 2008, at 3:16 PM, Don Dailey <[EMAIL PROTECTED]> wrote:
>>>
 There seems to be something special about 9x9 go for computers,
 it's
 very popular, perhaps because it's so much more approachable.

 However I personally think it's time to start looking at b

[computer-go] Re: CGOS server boardsize

[Hideki Kato]

Don,

Why we have to have three servers for three boardsizes?  Isn't it 
possoble to build a server that handle any boarsize?

-Hideki

Don Dailey: <[EMAIL PROTECTED]>:
>There has been some discussion about which additional board sizes to use
>for the server once it is running.   
>
>Of course running all 3 board sizes is a possibility now that we will
>have server space,  but my fear all along has been that they will kill
>each other.  There is something to be said about numbers and you want as
>many programs as possible playing on the server you want to test on. 
>
>Instead of asking for a lot of opinions however, I think it makes sense
>to put all 3 servers up and see what happens for a while.   In other
>words you will vote with your participation.   I think we will see that
>programs will gravitate more towards one server than another and I don't
>know which one that will be.   If they all get reasonable usage I will
>leave them all up,  but if one tends to get very little usage, I will
>bring it down later.   I'll let them all stay up for a reasonable length
>of time.
>
>So there will be 9x9, 13x13 and 19x19, at least for the first month or
>so, depending on usage.
>
>For time controls,  I have changed my previous position, I think I
>prefer somewhat faster time controls.   There are disadvantages but
>almost many advantages.  The foremost advantages is that I believe it
>encourages participation,  more programs are likely to test on the
>server if they do not have to wait unduly long for solid results.
>Another advantage is that the games are more fun to watch.  
>
>Right now, the time control for 9x9 assuming the average number of moves
>is roughly equivalent to the number of points on the board is about 3.7
>seconds per move or 5 minutes.  Using this same exact reasoning if we
>try to match the same rate of play per move we have this table:
>
>  9x9  - 300 seconds or 5 minutes
> 13x13 - 625 seconds or 10 minutes, 18 seconds. 
> 19x19 - 1336 seconds or 22 minutes, 16 seconds per move.
>
>There is no particular reason that the time control has to be in
>multiples of 5 minutes except that we humans seems to be offended if
>things are rounded nicely for us.
>
>So we could accept those values as is, or we could round it to what to
>our sensibilities seems somehow more "normal" and use 5 minutes 10
>minutes and 20 minutes for 9x9, 13x13 and 19x19 respectively.
>
>If we want to speed things up a bit, we might consider going from 3.7
>seconds per move to 2.5 seconds per move.   This gives the following
>approximate table:
>
>  9x9   -  202.5 seconds  or 3 minutes, 22 seconds
> 13x13  -  422.5 seconds  or 7 minutes 2 seconds 
> 19x19  -  902.5 seconds  or 15 minutes 2 seconds
>
>These could be rounded to 3 minutes, 7 minutes and 15 minutes or kept as
>is.  
>
>There is some argument for making the bigger boards play faster based on
>the notion that you SHOULD play faster since the game will have a lot
>more moves in it.   
>
>In this case, the time control could be set the same for all board
>sizes, perhaps 15 minutes per game or even 10 minutes per game.  There
>is some appeal to having this kind of consistency, but of course the
>quality of the games on the big boards would suffer accordingly.  Of
>course we don't care about absolute quality since we are testing
>programs against each other and we accept that they play much better at
>longer time controls.
>
>But we could set the average time per move faster if we were not
>comfortable with just making them all the same.   We could do something
>like 5, 10, 15 or something like that.
>
>In addition to the time control, there is currently a 0.75 second gift
>which is configurable.  The gift makes it possible for some programs
>with high latency connection issues to finish ridiculously long games
>without defaulting on time despite the fact that they are playing
>instantly.   So fast time controls shouldn't be dominated by network
>speed considerations.  
>
>My current default choice is:
>
>   9x9 - 5 minutes.  (to keep it the same as it is.)
> 13x13 - 10 minutes.
> 19x19 - 15 or 20 minutes.
>
>Feedback?
>
>- Don
>
>
>
>
>
>
>
>- Don
>
> 
>
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Ladders and UCT again

[Hideki Kato]

David Fotland: <[EMAIL PROTECTED]>:
>I keep liberty counts.

Me too.  Also is Hiroshi.

-Hideki

>David
>
>> -Original Message-
>> From: [EMAIL PROTECTED] [mailto:computer-go-
>> [EMAIL PROTECTED] On Behalf Of Jason House
>> Sent: Saturday, August 02, 2008 6:43 AM
>> To: computer-go
>> Subject: Re: [computer-go] Ladders and UCT again
>> 
>> On Aug 2, 2008, at 4:31 AM, Gunnar Farnebck <[EMAIL PROTECTED]>
>> wrote:
>> 
>> > It's often a good idea to bias capturing moves in the playouts,
>> > regardless whether it's a ladder or not. This would result in those
>> > stones being captured in most simulations.
>> 
>> What method do people use for finding capture moves in playouts?
>> Pseudo liberties can miss simple stuff like open triangles and one-
>> eyed groups. Additionally, some literature discusses captures to add
>> group liberties. What's the preferred method to detect
>> that?___
>> computer-go mailing list
>> computer-go@computer-go.org
>> http://www.computer-go.org/mailman/listinfo/computer-go/
>
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Ladders and UCT again

[Hideki Kato]

One is not so effective but simple.  Trace all adjacent
four intersections of all stones of a string with marking to
avoid duplicate.

The other is the combination of two dimensional shift, logical or, and
logical and operations on bitboards using 128 bit (or wider)
registers.

-Hideki

Łukasz Lew: <[EMAIL PROTECTED]>:
>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-
>>>> [EMAIL PROTECTED] On Behalf Of Jason House
>>>> Sent: Saturday, August 02, 2008 6:43 AM
>>>> To: computer-go
>>>> Subject: Re: [computer-go] Ladders and UCT again
>>>>
>>>> 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 it's a ladder or not. This would result in those
>>>> > stones being captured in most simulations.
>>>>
>>>> What method do people use for finding capture moves in playouts?
>>>> Pseudo liberties can miss simple stuff like open triangles and one-
>>>> eyed groups. Additionally, some literature discusses captures to add
>>>> group liberties. What's the preferred method to detect
>>>> that?___
>>>> computer-go mailing list
>>>> computer-go@computer-go.org
>>>> http://www.computer-go.org/mailman/listinfo/computer-go/
>>>
>>>___
>>>computer-go mailing list
>>>computer-go@computer-go.org
>>>http://www.computer-go.org/mailman/listinfo/computer-go/
>> --
>> [EMAIL PROTECTED] (Kato)
>> ___
>> computer-go mailing list
>> computer-go@computer-go.org
>> http://www.computer-go.org/mailman/listinfo/computer-go/
>>
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Program don't start playing on CGOS

[Hideki Kato]

Don,

This problem can only be relevant to the routers built on Linux.  If 
the server site uses Linux router(s) then this may be relevant. 
Servers and clients themselves are not relevant anyway.

-Hideki

Don Dailey: <[EMAIL PROTECTED]>:
>I am looking at this page:
>
>http://cryp.to/publications/masquerading-idle-connections/
>
>and wondering if it's relevant.   It seems to describe the problem
>pretty well,  talks about a 15 minute timeout which would do it and the
>timeout is built into the linux kernel but can be changed.   
>
>I'm really very weak on networking so I'm not sure what I'm actually
>reading or whether this fix needs to be applied on the server end or the
>client end.   Any ideas is this is relevant?
>
>- Don
>
>
>
>On Sat, 2008-08-09 at 10:42 -0400, Jason House wrote:
>> I hit this problem long ago when CGOS was young. The fix at that time  
>> was to send the estimated time until the next round. Eventually, that  
>> cluttered the logs and was removed from the server code.
>> 
>> Sent from my iPhone
>> 
>> On Aug 9, 2008, at 9:19 AM, Don Dailey <[EMAIL PROTECTED]> wrote:
>> 
>> > Ben,
>> >
>> > I am having the same exact problem, so I don't think it's anything you
>> > are doing wrong.   It seems to have something to do with idling a long
>> > time and it only seems to affect certain networks.On my own  
>> > machine
>> > and internet connection it never happens.
>> >
>> > But I have access to a machine where it's happening.
>> >
>> > I am also interested if anyone else has run into this and perhaps  
>> > solved
>> > it or has an idea what is going on.
>> >
>> > - Don
>> >
>> >
>> >
>> >
>> > On Sat, 2008-08-09 at 08:39 +0200, Ben Lambrechts wrote:
>> >> If my program has to wait to long before it gets a game, the console
>> >> don't send commands to my program.
>> >>
>> >> I tried all I could think about: I used the tclkit from Equi4 and
>> >> tried ActiveTcl.
>> >> I tried to create a .bat file and run it in the normal console and
>> >> PowerShell.
>> >>
>> >> Can someone help with this problem please?
>> >>
>> >> With kind regards, Ben
>> >>
>> >> 
>> >>
>> >> I followed the instructions from
>> >> http://www.mail-archive.com/computer-go@computer-go.org/msg04946.html
>> >> and correctly set the server and port in the tcl-script to
>> >> cgos.boardspace.net and 6819
>> >>
>> >> C:\CGOS> tclsh85 cgos3.tcl GtpTest3  MyGtpProgram.exe
>> >> 08:00:20C->E list_commands
>> >> 08:00:22E->C boardsize
>> >> 08:00:22E->C clear_board
>> >> ...
>> >> 08:00:22E->C undo
>> >> 08:00:22E->C version
>> >> 08:00:22recieved full response to list_commands
>> >> 08:00:22Engine uses  time control commands
>> >> 08:00:23Successful connection to CGOS server
>> >> 08:00:23S->C protocol
>> >> 08:00:23C->S e1 CGOS tcl engine client 1.2 Windows-x86 by Don
>> >> Dailey
>> >> 08:00:23S->C username
>> >> 08:00:23C->S GtpTest3
>> >> 08:00:23S->C password
>> >> 08:00:23C->S 
>> >>
>> >> By now a game is started and my program don't get commands from the
>> >> console, but it seems that the console also don't get commands from
>> >> the server...
>> >> If I try to restart the start-script I get additional lines:
>> >>
>> >> 08:21:50S->C Error: You are already logged on!  Closing
>> >> connection.
>> >> 08:21:50Connection to server has closed.  Will try to reconnect
>> >> shortly
>> >>
>> >> And most of the time, my program loses on time because of this. But
>> >> sometimes it suddenly connects and plays its game.
>> >>
>> >> ...
>> >> 08:36:38C->E genmove w
>> >> 08:36:38E->C = A10
>> >> 08:36:38C->S A10
>> >> 08:36:38S->C play b PASS 1199968
>> >> 08:36:38C->E play b PASS
>> >> 08:36:38E->C =
>> >> 08:36:39S->C genmove w 300024
>> >> 08:36:39C->E time_left w 300 0
>> >> 08:36:39E->C =
>> >> 08:36:39C->E genmove w
>> >> 08:36:39E->C = J4
>> >> 08:36:39C->S J4
>> >> 08:36:39S->C play b PASS 1199968
>> >> 08:36:39C->E play b PASS
>> >> 08:36:39E->C =
>> >> 08:36:39S->C genmove w 300024
>> >> 08:36:39C->E time_left w 300 0
>> >> 08:36:39E->C =
>> >> 08:36:39C->E genmove w
>> >> 08:36:39E->C = pass
>> >> 08:36:39C->S pass
>> >> 08:36:40S->C gameover 2008-08-09 W+40.5
>> >> 08:36:40C->S ready
>> >>
>> >> And then I have just the same problem, if it has to wait to long
>> >> before the other games are finished, it doesn't start in his next
>> >> game.
>> >> ___
>> >> computer-go mailing list
>> >> computer-go@computer-go.org
>> >> http://www.computer-go.org/mailman/listinfo/computer-go/
>> >
>> > ___
>> > computer-go mailing list
>> > computer-go@computer-go.org
>> > http://www.computer-go.org/mailman/listinfo/computer-go/
>> ___
>> computer-go mailing list
>> computer-go@computer-go.org
>> http://www.computer

Re: [computer-go] Program don't start playing on CGOS

[Hideki Kato]

Oh, perhaps my brain is damaged :(.

Just FYI,
A few months ago, the same problem occured on 9x9 cgos. Only GNU Go 
clients eventualy hangged-up and others, including MoGo and FatMan-1, 
were working well.  After observing while, I though long idle time 
after finishing games caused this (GNU Go plays fast).  Then I reset 
the NAT timer of my router longer, 3600 seconds, but this didn't 
solve and the poblem vanished a few or more days later.  

-Hideki

Don Dailey: <[EMAIL PROTECTED]>:
>I am putting the informational messages back into the server as a test
>to see if it stops this problem.  If it does, this is at least a strong
>indication that log periods of inactivity triggers the problem.
>
>- Don
>
>
>
>On Sun, 2008-08-10 at 01:40 +0900, Hideki Kato wrote:
>> Don,
>> 
>> This problem can only be relevant to the routers built on Linux.  If 
>> the server site uses Linux router(s) then this may be relevant. 
>> Servers and clients themselves are not relevant anyway.
>> 
>> -Hideki
>> 
>> Don Dailey: <[EMAIL PROTECTED]>:
>> >I am looking at this page:
>> >
>> >http://cryp.to/publications/masquerading-idle-connections/
>> >
>> >and wondering if it's relevant.   It seems to describe the problem
>> >pretty well,  talks about a 15 minute timeout which would do it and the
>> >timeout is built into the linux kernel but can be changed.   
>> >
>> >I'm really very weak on networking so I'm not sure what I'm actually
>> >reading or whether this fix needs to be applied on the server end or the
>> >client end.   Any ideas is this is relevant?
>> >
>> >- Don
>> >
>> >
>> >
>> >On Sat, 2008-08-09 at 10:42 -0400, Jason House wrote:
>> >> I hit this problem long ago when CGOS was young. The fix at that time  
>> >> was to send the estimated time until the next round. Eventually, that  
>> >> cluttered the logs and was removed from the server code.
>> >> 
>> >> Sent from my iPhone
>> >> 
>> >> On Aug 9, 2008, at 9:19 AM, Don Dailey <[EMAIL PROTECTED]> wrote:
>> >> 
>> >> > Ben,
>> >> >
>> >> > I am having the same exact problem, so I don't think it's anything you
>> >> > are doing wrong.   It seems to have something to do with idling a long
>> >> > time and it only seems to affect certain networks.On my own  
>> >> > machine
>> >> > and internet connection it never happens.
>> >> >
>> >> > But I have access to a machine where it's happening.
>> >> >
>> >> > I am also interested if anyone else has run into this and perhaps  
>> >> > solved
>> >> > it or has an idea what is going on.
>> >> >
>> >> > - Don
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > On Sat, 2008-08-09 at 08:39 +0200, Ben Lambrechts wrote:
>> >> >> If my program has to wait to long before it gets a game, the console
>> >> >> don't send commands to my program.
>> >> >>
>> >> >> I tried all I could think about: I used the tclkit from Equi4 and
>> >> >> tried ActiveTcl.
>> >> >> I tried to create a .bat file and run it in the normal console and
>> >> >> PowerShell.
>> >> >>
>> >> >> Can someone help with this problem please?
>> >> >>
>> >> >> With kind regards, Ben
>> >> >>
>> >> >> 
>> >> >>
>> >> >> I followed the instructions from
>> >> >> http://www.mail-archive.com/computer-go@computer-go.org/msg04946.html
>> >> >> and correctly set the server and port in the tcl-script to
>> >> >> cgos.boardspace.net and 6819
>> >> >>
>> >> >> C:\CGOS> tclsh85 cgos3.tcl GtpTest3  MyGtpProgram.exe
>> >> >> 08:00:20C->E list_commands
>> >> >> 08:00:22E->C boardsize
>> >> >> 08:00:22E->C clear_board
>> >> >> ...
>> >> >> 08:00:22E->C undo
>> >> >> 08:00:22E->C version
>> >> >> 08:00:22recieved full response to list_commands
>> >> >> 08:00:22Engine uses  time control commands
>> >> >> 08:00:23Successfu

[computer-go] Re: mogo beats pro!

[Hideki Kato]

Hi all,

I'd like to say first "Congratulations!" to MoGo team.

I have a question.  Why do you all call the game as "human vs.
computer"?  It's obviously a match between Kim 8p and MoGo, a program
developped by MoGo team, running on a supercomputer.

As both MoGo and the supercomputer were developped by human, the game
is clearly (a special type of) human vs. human.

I'm afraid it may raise unnecessary emotional thoughts of against
computers among people.  It might be better to call such a game
something of a style "a professinal Goplayer vs. a program with its
developper(s)" to emphasize the program was created by human.

-Hideki


terry mcintyre: <[EMAIL PROTECTED]>:
>This is from the AGA newsletter:

>

>COMPUTER BEATS PRO AT U.S. GO CONGRESS: In a historic achievement, the MoGo 
>computer program
>defeated Myungwan

>Kim 8P (l) Thursday afternoon by 1.5 points in a 9-stone game billed as

>“Humanity’s Last Stand?” “It played really well,” said Kim, who

>estimated MoGo’s current strength at “two or maybe three dan,” though

>he noted that the program – which used 800 processors, at 4.7 Ghz, 15

>Teraflops on a borrowed European supercomputer – “made some 5-dan

>moves,” like those in the lower right-hand corner, where Moyogo took

>advantage of a mistake by Kim to get an early lead. “I can’t tell you

>how amazing this is,” David Doshay -- the SlugGo programmer who

>suggested the match -- told the E-Journal after the game.

>“I’m shocked at the result. I really didn’t expect the computer to win

>in a one-hour game.” Kim easily won two blitz games with 9 stones and

>11 stones and minutes and lost one with 12 stones and 15 minutes by 3.5

>points. The games were played live at the U.S. Go Congress, with over

>500 watching online on KGS. “I think there’s no chance on nine stones,”

>Kim told the EJ after the game. “It would even be difficult with eight

>stones. MoGo played really well; after getting a lead, every time I

>played aggressively, it just played safely, even when it meant

>sacrificing some stones. It didn’t try to maximize the win and just

>played the most sure way to win. It’s like a machine.” The game

>generated a lot of interest and discussion about the game’s tactics and

>philosophical implications. “Congratulations on making history today,” game 
>organizer Peter
>Drake told both Kim and Olivier Teytaud, one of MoGo’s programmers, who 
>participated ina
>brief online chat after the game. At a rare loss for words in a brief

>interview with the EJ after the game, Doshay wondered “How much time do

>we have left? We’ve improved nine stones in just a year and I suspect

>the next nine will fall quickly now.”

>- reported by Chris Garlock, photo by Brian Allen

>

> Terry McIntyre <[EMAIL PROTECTED]>

>

>

>

>

>“Wherever is found what is called a paternal government, there is found state 
>education. It
>has been discovered that the best way to insure implicit obedience is to 
>commence tyranny in
>the nursery.”

>

>

>Benjamin Disraeli, Speech in the House of Commons [June 15, 1874]

>

>

>

> 
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Re: mogo beats pro!

[Hideki Kato]

Hi Darren,

Darren Cook: <[EMAIL PROTECTED]>:
>> I have a question.  Why do you all call the game as "human vs. 
>> computer"?  It's obviously a match between Kim 8p and MoGo, a program 
>> developped by MoGo team, running on a supercomputer.
>
>Quick answer: it is the established term. ("human-machine" is perhaps
>even more common?)

Sure, it's the same here in Japan.

>Longer answer: Mogo is on its own choosing moves; the programmers cannot
>help it while it is playing. Similarly the human player is on his own
>and not allowed to discuss positions with his teachers, students, go
>books, etc.

It does not change the fact MoGo was developped by the programmers.  
And the fact the programmers spent many resources, like the people 
fighting at Beijing right now, to develop MoGo.

>(BTW, just about everybody here has congratulated the "Mogo team" not
>Mogo. But the human side is the same: if the human player won an
>important game and his parents were in the room people would go up and
>shake their hand and say "Congratulations, you must be very proud.")

(Really the same?)

>> I'm afraid it may raise unnecessary emotional thoughts of against 
>> computers among people.
>
>People like that will get emotional whichever words you use.

Don't you think it cannot be changed or, at least, improved? 
#Assuming we agree it's "unnecessary."

Hideki
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Re: What's happening at the European Go Congress?

[Hideki Kato]

Don Dailey: <[EMAIL PROTECTED]>:
>On Tue, 2008-08-12 at 09:55 +0900, Darren Cook wrote:
>> > [The pro] was also a bit "unlucky" in the sense that Leela did not 
>> > understand it
>> > was dead lost.
>> > 
>> > I use quotes because had it understood better it was losing, it would have
>> > put up more of a fight :-)
>> 
>> My first impression of watching the game was that Leela was handicapped
>> by having a handicap. By that I mean it would have seen itself so far
>> ahead for the first few moves that is was playing arbitrarily.
>
>I was blasted for making that observation many months ago concerning the
>possibility of handicap matches on CGOS.   I thought it not a good idea
>for Monte Carlo players because each player starting with a dead won or
>dead lost game.   The response was that it didn't matter, the programs
>would still fight.  
>
>So I yielded to the opinion of others since I am not a go player.  I now
>think they were probably right.   MCTS still tries to maximize the
>chances of winning.  If you are up 8 or 9 stones, that is STILL the
>right strategy isn't it?  
>
>Also, if you are down 8 or 9 stones, maximizing your winning chances is
>still the right strategy, right?   

I think NO because of the model of the opponent.   MCTS uses itself 
for the model but it's obvously not correct in hadicapped games.

Hideki

>I'm trying to come up with some kind of analogy to real life.  How about
>investing your money?   Let's say you play a game where the goal is to
>turn 500 thousand into 1 million dollars in 10 years.  Double your money
>in 10 years is not particularly difficult so if the only thing that
>matters is winning this game then you would use very conservative
>investments.  This is like being up 9 stones because in theory you have
>a relatively simple task to perform, just double your money.   
>
>The temptation is to be foolish by thinking if you are a lot more
>aggressive, you can get ahead of the game and get there faster.  Surely,
>if you have a good year or two, you can coast the rest of the way!  Have
>you ever been with someone who is about to run out of gas?  They want to
>drive FASTER thinking that if they get there faster, they will use less
>fuel.  Or maybe they just get anxious which causes you to drive a little
>faster.  
>
>
>> This is a direct consequence of the UCT algorithm playing for the win,
>> instead of trying to maximize the score. I'm fine with that (please see
>> the archives for numerous passionate discussion on the subject), but
>> surely you need an opening book to allow for the fact that evaluations
>> are going to have a high error margin in the early game?
>> 
>> (I'll go out on a limb and say black 3 was a mistake; I'm sure it is a
>> win at 0.5pt komi, but I strongly suspect it is dubious at 5.5pt komi or
>> higher.)
>> 
>> >From another angle: if a UCT computer program is being given a handicap
>> against a stronger player it should lie to itself about the komi at the
>> start. It could then gradually adjust komi so it is at the correct value
>> by the early middle game (e.g. move 6 in 9x9 go, move 30 in 19x19 go).
>> Or it could keep adjusting komi (until it reaches the actual komi) so
>> that it thinks it is only just winning.
>
>It could turn out that the best strategy is simply to let the opponent
>play desperately and not over-react, because to have any chance when
>giving 9 stones you must in some sense over-play it.  
>
>- Don
>
>> 
>> Darren
>> 
>> 
>
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Re: mogo beats pro!

[Hideki Kato]

David,

I didn't intend to offend any person in this list, sorry for short 
of my words.  I'm just trying to prevent people misunderstand the 
truth.

Hideki

David Doshay: <[EMAIL PROTECTED]>:
>It is of no consequence what words WE use to describe this. Journalists
>will ALWAYS print it that way. If you use too many big words or ideas
>that are accurate but convoluted, you will either not get the publicity
>or the journalist will make up something even more absurd.
>
>
>Sorry if I am a bit over sensitive ... getting misquoted, my work  
>ignored,
>and getting credit for the work of others in this past week has me very
>aware of how these people work. They are on a deadline and meeting the
>deadline with a headline that captures a lay reader's attention is the  
>only
>priority. I know how my attempts to get a correction were greeted ...
>
>Cheers,
>David
>
>
>
>On 11, Aug 2008, at 8:37 AM, Hideki Kato wrote:
>
>> Hi all,
>>
>> I'd like to say first "Congratulations!" to MoGo team.
>>
>> I have a question.  Why do you all call the game as "human vs.
>> computer"?  It's obviously a match between Kim 8p and MoGo, a program
>> developped by MoGo team, running on a supercomputer.
>>
>> As both MoGo and the supercomputer were developped by human, the game
>> is clearly (a special type of) human vs. human.
>>
>> I'm afraid it may raise unnecessary emotional thoughts of against
>> computers among people.  It might be better to call such a game
>> something of a style "a professinal Goplayer vs. a program with its
>> developper(s)" to emphasize the program was created by human.
>>
>> -Hideki
>
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Re: What's happening at the European Go Congress?

[Hideki Kato]

Don Dailey: <[EMAIL PROTECTED]>:
>On Tue, 2008-08-12 at 11:50 +0900, Darren Cook wrote:
>> > Also, if you are down 8 or 9 stones, maximizing your winning chances is
>> > still the right strategy, right?   
>> 
>> With MCTS algorithms the error margin is high at the start of the game,
>> and low in the endgame. In a handicap game against a stronger opponent
>> the assumption is that the weaker player will make more mistakes (i.e.
>> has a higher error margin overall). But MCTS programs don't see it that
>> way - their opponent model is the same strength as they are. So they
>> choose a move that gives them 95% (+/- 20%) win (against themselves)
>> instead of the better move that they only gives them a 90% (+/- 20%) win
>> (against themselves). (I.e. I'm saying their error margin in the opening
>> is much greater than the difference in their estimate of move values.)
>
>There could be something to that.  
>
>Do you believe that they will play the 90% move if they are told they
>are not really down 9 stones? 
>
>I did a bunch of experiments and ALWAYS got a reduced wins when I faked
>the komi.   But there are a million ways to do this and I may not have
>stumbled on the right way.

Mr. Okasaki, a strong amatur, tested MoGo with a 9 stones handicap 
game at winning rate around 50% by adjusting komi on each move and 
reported it played clearly stronger than others, say, on KGS and the 
cluster version at Paris.

Hideki
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Re: mogo beats pro!

[Hideki Kato]

Darren Cook: <[EMAIL PROTECTED]>:
>> It does not change the fact MoGo was developped by the programmers.  
>> And the fact the programmers spent many resources, like the people 
>> fighting at Beijing right now, to develop MoGo.
>
>And Kim was developed by his parents, his go teachers, go books, and
>each opponent he has played against and learnt something from. But when
>the game starts each is on his own, and you are just left with a human
>with knowledge, and a machine with knowledge.

Mr. Kim was _created from scratch_ by his parents? :)

 I'm afraid it may raise unnecessary emotional thoughts of against 
 computers among people.
>>> People like that will get emotional whichever words you use.
>> 
>> Don't you think it cannot be changed or, at least, improved? 
>
>Yes, you should have it play across a board using this android to play
>the moves:
> http://news.bbc.co.uk/1/hi/sci/tech/4714135.stm
>
>It should smile sweetly, and flutter its eyelids across the board every
>now and again.

Yah, it's well known in Japan but I feel rather it's weird (some 
around me agree).

>(In case anyone says I forgot the smiley, I'm being serious: people will
>mind losing less to a pretty machine than losing to a cube of metal;
>just as an elderly man would rather the above android helps them to the
>toilet than something that looks R2-D2.)

Interesting.

Hideki
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

[computer-go] Re: Depth-first UCT

[Hideki Kato]

Rémi Coulom: <[EMAIL PROTECTED]>:
>Gian-Carlo Pascutto wrote:
>>
>> The *paper* about MTD(f) is extremely interesting because it shows 
>> that many best-first algorithms can be rewritten as depth-first 
>> algorithms.
>>
>> It happened for SSS, it happened for proof-number search.
>>
>> Who will make it happen for UCT?
>>
>
>
>Actually, there was a paper presented at the 2007 Computer-Game Workshop 
>in Japan entitled "Depth-First UCT and its Application to Go", by 
>Haruhiro Yoshimoto, Akihiro Kishimoto, Tomoyuki Kaneko, and Kazuki Yoshizoe.

Abstract in English:
The UCT algorithm is a representative best-first search algorithm that
has been popularly used in Monte Carlo Go.  This paper presents the
DFUCT (Depth-First UCT) algorithm, which is an efficient depth-first
variant of UCT.  Experimental results in Go show that DFUCT achieves
3% improvement in running time, while the solving abilities of DFUCT
and UCT are comparable.

This paper is written in Japanese.  DFUCT was not parallelized in this
paper.

Hideki

--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

[computer-go] Re: Depth-first UCT

[Hideki Kato]

Hideki Kato: <[EMAIL PROTECTED]>:
>Rémi Coulom: <[EMAIL PROTECTED]>:
>>Gian-Carlo Pascutto wrote:
>>>
>>> The *paper* about MTD(f) is extremely interesting because it shows 
>>> that many best-first algorithms can be rewritten as depth-first 
>>> algorithms.
>>>
>>> It happened for SSS, it happened for proof-number search.
>>>
>>> Who will make it happen for UCT?
>>>
>>
>>
>>Actually, there was a paper presented at the 2007 Computer-Game Workshop 
>>in Japan entitled "Depth-First UCT and its Application to Go", by 
>>Haruhiro Yoshimoto, Akihiro Kishimoto, Tomoyuki Kaneko, and Kazuki Yoshizoe.
>
>Abstract in English:
>The UCT algorithm is a representative best-first search algorithm that
>has been popularly used in Monte Carlo Go.  This paper presents the
>DFUCT (Depth-First UCT) algorithm, which is an efficient depth-first
>variant of UCT.  Experimental results in Go show that DFUCT achieves
>3% improvement in running time, while the solving abilities of DFUCT
>and UCT are comparable.
>
>This paper is written in Japanese.  DFUCT was not parallelized in this
>paper.

OOPS, this may mislead readers.  I don't know it's parallelized or
not now.

Hideki

--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Re: Depth-first UCT

[Hideki Kato]

Zach Wegner: <[EMAIL PROTECTED]>:
>Interesting. Could you (or someone else) explain how DFUCT works? I'd
>imagine it doesn't save all the nodes in memory, but that seems rather
>counterintuitive.

As far as I understand,

The basic idea is that DFUCT continues searching avoiding going back 
to root node if possible.  To do this, DFUCT saves the number of wins, 
the number of visits and the sum of number of visits of the brothers 
of two nodes at root those ucb values are the maximum (first) and next 
to the maximum (second), in a stack.

The authors claimed in the paper that although DFUCT does not behave 
the same as UCT when the third node at root comes up to the second, 
it's so rare that can be ignored.

Hideki
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Re: Depth-first UCT

[Hideki Kato]

Oops.

Hideki Kato: <[EMAIL PROTECTED]>:
>Zach Wegner: <[EMAIL PROTECTED]>:
>>Interesting. Could you (or someone else) explain how DFUCT works? I'd
>>imagine it doesn't save all the nodes in memory, but that seems rather
>>counterintuitive.
>
>As far as I understand,
>
>The basic idea is that DFUCT continues searching avoiding going back 
>to root node if possible.  To do this, DFUCT saves the number of wins, 
>the number of visits and the sum of number of visits of the brothers 
>of two nodes at root those ucb values are the maximum (first) and next 
"two nodes" should be "two arcs (moves)".

>to the maximum (second), in a stack.

>The authors claimed in the paper that although DFUCT does not behave 
>the same as UCT when the third node at root comes up to the second, 
"third node" should be "third arc".

>it's so rare that can be ignored.

Sorry for mistakes.

Hideki
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] What was the specific design of the Mogo version which beat the pro...

[Hideki Kato]

Bob Hearn: <[EMAIL PROTECTED]>:
>The MoGo programmer who answered questions after the match (Olivier  
>Teytaud) did state that MoGo no longer used UCT. He gave a one-line  
>statement of the reason they switched, which I did not follow.

The first post Olivier wrote they no longer used UCT is:
http://computer-go.org/pipermail/computer-go/2008-February/014102.html

Hideki

>On Aug 12, 2008, at 7:00 PM, Jim O'Flaherty wrote:
>
>> All,
>>
>> Can anyone detail the design of the version of Mogo that beat the  
>> professional? Or is there a web-page where at least the general  
>> approach has been described? Is the information even public? I am  
>> not seeing the the implementation details, just the overall design  
>> and general strategies. However, if the implementation details are  
>> available, I would love to see those as well.
>>
>> I am confused around what Mogo used. Was it Monte Carlo only, UCT  
>> only, Monte Carlo integrated with UCT, RAVE, etc? I have read  
>> through all of the recent emails, and I have not been able to get a  
>> clear picture of it's design. Mogo at one timed used Monte Carlo and  
>> UCT. I read an email that the one that played the pro and won did  
>> not use UCT at all. However, I thought the massive tests that Don  
>> did awhile back showed that MC did not scale very well, but MC + UCT  
>> did.
>>
>> And what language/platform is Mogo written in; C/C++, Java,  
>> Assembly, PHP, etc.? And how did the language/platform choice impact  
>> the overall efforts; speed them up, slow them down, complicate/ease  
>> creating the parallelism on the super computer, etc.?
>>
>> So, I am now confused precisely what method or methods were used and/ 
>> or integrated to produce the current scalable version of Mogo. I  
>> want to know these details so I can at least get a better sense of  
>> what actually occurred with the win. I don't care near as much about  
>> the hardware as I do the software architecture and design.
>>
>>
>> Thank you,
>>
>> Jim
>>
>> ___
>> computer-go mailing list
>> computer-go@computer-go.org
>> http://www.computer-go.org/mailman/listinfo/computer-go/
>>
>
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Re: mogo beats pro!

[Hideki Kato]

Magnus Persson: <[EMAIL PROTECTED]>:
>Quoting Don Dailey <[EMAIL PROTECTED]>:
>
>> Yes, UCT is easier to use with multiple CPU's because with additional
>> processors alpha-beta programs do wasted work, unless you are talking
>> about theoretical programs with perfect move ordering, which you aren't.
>
>Nice that all is clear about alpha-beta programs.
>
>But... does not UCT with additional processors waste a lot of  
>simulations because what would be the optimal path through the search  
>tree depends on the threads that have not finished yet?

Yes, UCT does.  From my recent experiments with a delay 
line (a fixed size FIFO queue) between a UCTsearcher and an MC 
simulator with RAVE against GNU Go 3.7.11 level 0 on 9x9 (single 
thread):

delay   #po winsgames   winning rateELO 1 sigma of wr
0   1,000   721 2,000   36.05%  -99.6   1.07%
1   1,000   721 2,000   36.05%  -99.6   1.07%
2   1,000   690 2,000   34.50%  -111.4  1.06%
3   1,000   663 2,000   33.15%  -121.8  1.05%
5   1,000   642 2,000   32.10%  -130.1  1.04%
10  1,000   522 2,000   26.10%  -180.8  0.98%
20  1,000   412 2,000   20.60%  -234.4  0.90%
50  1,000   82  2,000   4.10%   -547.6  0.44%

Hideki

>Some people reported that more processors helps a lot on large boards,  
>whereas on smaller one there is not much gain.
>
>-Magnus
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Re: mogo beats pro!

[Hideki Kato]

steve uurtamo: <[EMAIL PROTECTED]>:
>this is interesting!
>
>perhaps i misunderstand the setup of the experiment -- what
>is the unit of measure for the delay, or how is delay being
>implemented?

>the FIFO queue is doing what, and where is the delay
>being introduced?

The UCT searcher pushes a position to the FIFO queue upon the end of 
each search but the MC simulator does not get the position until the 
queue overflows.  So, the searcher selects optimal arcs based on the 
older results of simulations by "delay" times.  Especially at 
beginning, the searcher does blind search and pushes the same 
positions "delay" times.

Hideki

>On Wed, Aug 13, 2008 at 9:20 AM, Hideki Kato <[EMAIL PROTECTED]> wrote:
>> Magnus Persson: <[EMAIL PROTECTED]>:
>>>Quoting Don Dailey <[EMAIL PROTECTED]>:
>>>
>>>> Yes, UCT is easier to use with multiple CPU's because with additional
>>>> processors alpha-beta programs do wasted work, unless you are talking
>>>> about theoretical programs with perfect move ordering, which you aren't.
>>>
>>>Nice that all is clear about alpha-beta programs.
>>>
>>>But... does not UCT with additional processors waste a lot of
>>>simulations because what would be the optimal path through the search
>>>tree depends on the threads that have not finished yet?
>>
>> Yes, UCT does.  From my recent experiments with a delay
>> line (a fixed size FIFO queue) between a UCTsearcher and an MC
>> simulator with RAVE against GNU Go 3.7.11 level 0 on 9x9 (single
>> thread):
>>
>> delay   #po winsgames   winning rateELO 1 sigma of wr
>> 0   1,000   721 2,000   36.05%  -99.6   1.07%
>> 1   1,000   721 2,000   36.05%  -99.6   1.07%
>> 2   1,000   690 2,000   34.50%  -111.4  1.06%
>> 3   1,000   663 2,000   33.15%  -121.8  1.05%
>> 5   1,000   642 2,000   32.10%  -130.1  1.04%
>> 10  1,000   522 2,000   26.10%  -180.8  0.98%
>> 20  1,000   412 2,000   20.60%  -234.4  0.90%
>> 50  1,000   82  2,000   4.10%   -547.6  0.44%
>>
>> Hideki
>>
>>>Some people reported that more processors helps a lot on large boards,
>>>whereas on smaller one there is not much gain.
>>>
>>>-Magnus
>>>___
>>>computer-go mailing list
>>>computer-go@computer-go.org
>>>http://www.computer-go.org/mailman/listinfo/computer-go/
>> --
>> [EMAIL PROTECTED] (Kato)
>> ___
>> computer-go mailing list
>> computer-go@computer-go.org
>> http://www.computer-go.org/mailman/listinfo/computer-go/
>>
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Re: mogo beats pro!

[Hideki Kato]

Magnus Persson: <[EMAIL PROTECTED]>:
>Quoting Hideki Kato <[EMAIL PROTECTED]>:
>
>> Yes, UCT does.  From my recent experiments with a delay
>> line (a fixed size FIFO queue) between a UCTsearcher and an MC
>> simulator with RAVE against GNU Go 3.7.11 level 0 on 9x9 (single
>> thread):
>>
>> delay#po winsgames   winning rateELO 1 sigma of wr
>> 01,000   721 2,000   36.05%  -99.6   1.07%
>> 11,000   721 2,000   36.05%  -99.6   1.07%
>> 21,000   690 2,000   34.50%  -111.4  1.06%
>> 31,000   663 2,000   33.15%  -121.8  1.05%
>> 51,000   642 2,000   32.10%  -130.1  1.04%
>> 10   1,000   522 2,000   26.10%  -180.8  0.98%
>> 20   1,000   412 2,000   20.60%  -234.4  0.90%
>> 50   1,000   82  2,000   4.10%   -547.6  0.44%
>
>If I understand this correctly this simulation for delay 50 computes  
>50 playouts and then updates the tree.

Not exactly, if I understand correctly.  The UCT searcher and the MC 
simulator is connected by a delay line of fixed size.  So, except 
initial time, the tree is updated on every playout.  The playout is 
sperated in two parts here, the search (descend) of the tree and 
the simulation, and there is a "delay" between them.  That is, at 
time T, the tree is updated by the result of the simulation of the 
position at (T - 50) if the delay is 50.

>In Valkyria I do the following. Every simulation from the root with  
>their own thread updates all nodes as visited down the tree before  
>entering the heavy playout. This means that all moves made in the tree  
>are temporarily updated as losses. When a playout has finished, half  
>of the moves were winners and updated accordingly.
>
>The idea behind this is that this hopefully avoids searching the same  
>path over and over again. Have tried anything like this?

I use "modifying fpu" method (fpu was introduced in the first report 
of MoGo).  It's very simple.  Before simulating an optimal arc at a 
leaf node, the value (fpu) of the arc is decreased a little (value *= 
0.99).  This avoids simulating the same node if all arcs have 
the same value or no value (ie. at beginning of UCB1 algorithm) but 
does not avoid repeated simulations of significantly better arcs.

>Also your results shows clearly that there is inefficency. But do you  
>also have results where for example delay 50 also computes 50x1000  
>simulations so that we can see if what it means in practise?

As my implementation expands one node on each simulation like MoGo, 
this happens in practice.  NB: this experiment is for a network 
environment where MC simulation servers return results to a UCT 
searcher client with very long delay.

Hideki
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

[computer-go] Re: Arc vs. Move

[Hideki Kato]

Hi Darren,

Darren Cook: <[EMAIL PROTECTED]>:
>Hideki Kato wrote:
>> queue overflows.  So, the searcher selects optimal arcs based on the
>> older results of simulations by "delay" times.  Especially at
>
>Hi Hideki,
>You have used the word "arc" a few times, and it seems to mean move, but
>I wondered if there was some nuance intended. (E.g. maybe an arc can be
>a forced sequence of more than one move, or something like that)?

No, the reason I use "arc" is just because it's one of the pair {node, 
arc} in mathematics (at least in my mind :-).   In contrast, I use 
"move" for the people who are more familiar with Go than 
mathematics.

Hideki
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] no interest in 13x13

[Hideki Kato]

Don Dailey: <[EMAIL PROTECTED]>:

>Why don't we leave it up for another month or
>two and see if it's being used.   If there are no opponents, even if
>someone wants to use it they won't be able to unless they provide their
>own opponents.

In addition, there are no anchors so long :(

May it be better to move some GNUs on my site from 9x9 to 13x13?

Hideki

>- Don
>
>
>
>> 
>> Christoph
>> 
>> ___
>> computer-go mailing list
>> computer-go@computer-go.org
>> http://www.computer-go.org/mailman/listinfo/computer-go/
>
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Kaori-Crazystone

[Hideki Kato]

Don Dailey: <[EMAIL PROTECTED]>:
>It's difficult for me to understand this due to different ranking
>systems and pro ratings vs amateur ratings.   I see here listed as a 4
>dan player on this page:  
>
>http://www.nihonkiin.or.jp/player/htm/ki000343.htm
>
>
>Is that 4 dan pro?  My understanding is something like this:
>
>kyu player are casual players (or weak tournament players)
>
>low dan players are something like advanced amateurs or experts and weak
>masters in chess.
>
>Pro's are like super high dan players and there is not very much
>difference between ranks compared to regular dan players.  I have heard
>that a 1d professional will beat a 9d professional with 3 or 4 stones. 
>
>So a 1d pro is something like a 7 or 8d+ amateur?  
>
>Is this all "roughly" correct?   

I guess _yes_ but all the numbers are of Japanese rating, which is
something different than KGS.  Following is a (not authorized
but many people agreed) mapping:
KGS Japan (more exactly, East Japan)
1d  3d~4d
1k  2d~3d
2k  1d~2d

I'm KGS 3k now and, perhaps, 1d at Tokyo.  I won a game against a
Japanese 9p once with 8 stones handicap at a teaching game last Nov
but I won't be able to win against Kaori Inaba 4p at an open game with
8 stones.

I'm pretty sure that Crazy Stone is stronger than I and is 1k or
stronger because, as you wrote, it won the game.

Hideki

>So I assume that Aoba Kaori is a 4d professional?  That would relate to
>something in the ballpark of 9 or 10d amateur if there were such a
>thing.   And with 8 stones handicap, this implies that CrazyStone did
>what a 2d+ would have done,  or it is weaker than 2d but got lucky.  So
>it's "performance rating" for that one game is lower bounded at around 1
>or 2 dan.   Since it won the game we could pick 2 dan as a better lower
>bound guess although since it won we do not have a reasonable upper
>bound guess on it's performance except our own credulity.   
>
>Does what I said make any sense?  I am not a go player and I'm not very
>comfortable with this guesswork.   In chess, if you beat a player I am
>used to thinking in terms of setting a performance rating of around 400
>ELO higher for that one game.   I know this is not precise, but I also
>think of 400 ELO subtracted from the player you beat as a kind of
>"estimated" lower bound on your strength.  If you beat a 2500 ELO chess
>player, it's a relatively safe bet that you are at least 2100 ELO in
>strength although technically there is a chance you could lose to
>anybody, even a random move generator.
>
>I know this isn't precise language, but how many ranks would give us
>around 90 - 95% confidence of superiority?If I beat a 5 dan player,
>could you say that it's "very likely" I am at least 3 dan in strength?
>
>I'm thinking that if we estimate Aoba at 10d amateur and CrazyStone wins
>with 8 stone handicap, it is roughly equivalent to beating a 2d player
>without handicap and that we can subtract 2 stones to say that with
>pretty high confidence CrazyStone is playing at least 1 kyu  (but that's
>it's much more likely Crazy Stone is stronger than this - after all it
>performed in this one game at least as well as 2d player.) 
>
>
>- Don
>
>
>
>
>On Thu, 2008-09-04 at 16:28 +0200, Rémi Coulom wrote:
>> terry mcintyre wrote:
>> > Congratulations!
>> >   
>> 
>> Thanks.
>> 
>> > I'm dying for details! What was the time limit?
>> 
>> The organizers asked that the program should play at a constant time (30 
>> second) per move. The sgf file contains time stamps (you can see the 
>> time with gogui, for instance). I don't know what was her time control, 
>> but she apparently played at the same pace as the program.
>> 
>> >  Did the game end on time or by resignation at move 179? 
>> >   
>> 
>> She resigned.
>> 
>> > The pro was Aoba Kaori, yes? 
>> >   
>> 
>> Yes.
>> 
>> The only other information I have about the match are these pages in 
>> Japanese:
>> https://secure1.gakkai-web.net/gakkai/fit/program/html/event/event.html#6
>> http://www.ipsj.or.jp/10jigyo/fit/fit2008/events.html#1-4-1
>> 
>> I hope the organizers can send me some photos tomorrow. Then I will set 
>> up a web page and tell the list.
>> 
>> Rémi
>> ___
>> computer-go mailing list
>> computer-go@computer-go.org
>> http://www.computer-go.org/mailman/listinfo/computer-go/
>
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] cgos 13x13 seems down

[Hideki Kato]

Christoph Birk: <[EMAIL PROTECTED]>:
>On Fri, 5 Sep 2008, Magnus Persson wrote:
>> I will also run Valkyria on CGOS 13x13 over the weekend, (or long as things 
>> are stable).
>
>One anchor would be nice.

OK, I will run Gnugo-3.7.10-a4 soon.

Hideki

>Christoph
>
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

[computer-go] Re: cgos 9x9 is back up, but without anchors.

[Hideki Kato]

I restarted FatMan-1 now.

Hideki

David Fotland: <[EMAIL PROTECTED]>:
>
>
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Lockless hash table and other parallel search ideas

[Hideki Kato]

Rémi Coulom: <[EMAIL PROTECTED]>:

>I'll run tests to try to figure out how much strength is lost by 
>parallelization (ie, what is the winning rate of 10,000 sequential 
>playouts vs 1,000 playouts over 10 processors). Hideki ran similar tests 
>against GNU Go, and found 25 Elo loss with 4 CPUs. So 54,193 playouts 
>per second over 16 CPUs will certainly not perform as well as 54,193 
>sequential playouts.

By my recent experiments, 8~9 * (threads - 1) ELO is lost.  This
matches my earlier result well.

Hideki
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Lockless hash table and other parallel search ideas

[Hideki Kato]

Olivier Teytaud: <[EMAIL PROTECTED]>:
>>
>>
>> By my recent experiments, 8~9 * (threads - 1) ELO is lost.  This
>> matches my earlier result well.
>>
>
>Do you have tricks for avoiding redundancies between simulations ?

Yes.  I use Sylvain's fpu and decrease it a little before starting a 
simulation, say, fpu *= 0.99.  This is very simple and fast.

For detailed info, you can read my implementation of PMCTS 
(parallel MCTS) submitted to GPW 2007.  Though it's written in 
Japanese, pseudo code are in English and abstract and captions are 
written in both.
http://www.geocities.jp/hideki_katoh/publications/gpw2007/gpw07-private.pdf
If you have any trouble on downloading or reading, please let me 
know.

Hideki

>I suggest simple tricks like "do not go to node X if there is a thread
>currently in node X"
>(simply by setting the score of the moves leading to node X to zero until
>you get out of the node).
> inline file
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

[computer-go] Re: 13x13 anchor hung

[Hideki Kato]

Don Dailey: <[EMAIL PROTECTED]>:
>Who is running the 13x13 anchor?   It is hung and needs to be restarted.

It's me and restarted right now.

Hmmm, I cannot find any strange things in the log file.  My guess is 
that there are no players other than the anchor running for a while 
and the match server doesn't sent any message to my site, the NAPT 
table time-out syndrome happened.

Hideki

>- Don
>
>
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Lockless hash table and other parallel search ideas

[Hideki Kato]

Olivier Teytaud: <[EMAIL PROTECTED]>:
>>
>>
>> Yes.  I use Sylvain's fpu and decrease it a little before starting a
>> simulation, say, fpu *= 0.99.  This is very simple and fast.
>
>
>Ok. Perhaps I'm wrong (I might misunderstand your solution and I might be
>wrong
>whenever I've understood :-) ); but
>- I think that this does not avoid redundancies in the tree, if I understand
>well.
>- also, even in a final node in a tree, it does not avoid redundancies for
>moves
>  which have already been simulated.
>- finally, in a final node in a tree and for moves which have not yet been
>simulated,
>  it only avoid redundancies if 0.99 is sufficiently small.

Perhaps yes.  I use _no_ pre-knowledge yet, ie, the initial value of 
fpu is a constant, 1.10.

>Avoiding redundancies is very important in SMP parallelization. The limited
>speed-up
>of MPI parallelization in 9x9  is also probably due to redundancies, but for
>that we have no
>good solution - whereas in 19x19 (or even 13x13), the speed-up of the MPI
>parallelization is great (both
>in our results and other published papers), in 9x9 it is limited.

Although I'm parallelizing in not SMP systems but a cluster of loosely 
coupled (small) computers connected through moderate speed networks 
using broadcasting positions, this may not change the vlaue of 
avoiding redundancies.  I'll study more when implementing 
pre-knowledge or some.  Thanks.

Best regards,
Hideki

>Best regards,
>Olivier
> inline file
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Lockless hash table and other parallel search ideas

[Hideki Kato]

Olivier Teytaud: <[EMAIL PROTECTED]>:
>>
>>
>> Although I'm parallelizing in not SMP systems but a cluster of loosely
>> coupled (small) computers connected through moderate speed networks
>> using broadcasting positions, this may not change the vlaue of
>> avoiding redundancies.  I'll study more when implementing
>> pre-knowledge or some.  Thanks.
>
>
>
>Do you have the winning rate of your best parallel algorithm against the
>sequential version in 9x9 Go
>in such a setting without shared memory ? We stay below 80% for this form of
>parallelization (but this
>speed-up can be cumulated with SMP speed-up), whenever we use fast networks
>(infiniband).

Not yet.  I have many benchmarks now but only against GNU Go level _0_ 
on 9x9 and 13x13.  The best WR on 9x9 is 72% using four quad-core PCs 
on a GbE private LAN with 0.16 second per move (less than 10 seconds 
per game) but the speed-up (strength-speedup by G. Chaslot) against 1 
PC is just 1.6.  This may be improved in longer time settings but I'm 
not sure.
# I can use only 4 x 4 cores in hand now so that it's very hard to 
have benchmarks on 19x19.

>In 19x19, it's much better, but the MPI parallelization of  9x9 Go is
>challenging.

Strongly agree.  Even in 13x13, it's much better.

Best,
Hideki

>Best regards,
>Olivier
> inline file
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Lockless hash table and other parallel search ideas

[Hideki Kato]

Christoph Birk: <[EMAIL PROTECTED]>:
>On Tue, 9 Sep 2008, Olivier Teytaud wrote:
>> testbed for
>> parallelization because it's more difficult) and as "real" targets (as there
>> are players
>> for both).
>
>Sorry, but there are (almost) no players for 9x9. To repeat
>D.Fotland's earlier comment: 9x9 is just for beginner's practice.
>It's not go.

Other than the match CS vs. Kaori Aoba 4p, which Rémi reported
recently, there was a 9x9 match CS vs. Meien O 9p with no komi at
FIT2008.  CS (B) won by 3 points.

I'd like to emphasize "9x9 is Go."

Hideki

>Christoph
>
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Lockless hash table and other parallel search ideas

[Hideki Kato]

I'm not sure about the strength of professional players on 9x9 but
basically agree with Don.

Of course, there are no definition what Go is. So, I'd just like to
introduce some in Japan.

- Meien O 9p is radical in some sense.  He wrote in his book that Go
is already unified in the sense that baseball is unified. Say,
although the size of the ball, for example, is different in US
and Japan, people don't say threre are two baseballs or Japanese
baseball is not a baseball, at lease these days :-).  So, according to
his idea, 9x9 is, of course, Go.

#Oh, if you can read Japanese, please visit the site below titled
"Kanpai, Monte-Carlo".
http://taisen.mycom.co.jp/taisen/contents/igo/meien/meien_30.htm
"Kanpai" here has two meanings, "perfect loss" and "to toast".

- There had been a TV program of professional 9x9 Go for years (some
member of this list have the records of the games played in this
program).  Takemiya 9p and Yuki 9p were the strongest.

- A vert famous and one of the strongest 9p in Japan, Chikun Cho is
well known by his research about 9x9 Go.

So, I'm sure all professtonal Go players in Japan think 9x9 is Go.  

- There are threads for discussions and online 9x9 games (by
beginners, kyu and dan players) on the largest BBS in Japan.

- Finally, Mr. Okasaki, a researcher of the game of Go, sometime
argued 9x9 is not Go.  He sometime also argued computer's Go is not Go
:).

Hideki

Don Dailey: <[EMAIL PROTECTED]>:
>The rules are exactly the same for 9x9 as for 19x19.  The boardsize is
>different and that changes the game some.
>
>I would suggest that if a top go player plays a game of chess
>immediately after first learning the rules,   he would lose very badly
>to even mediocre players or even advanced beginners.   
>
>I really doubt this would be the case with 9x9 go.  I don't think you
>can really make a strong argument that 9x9 isn't go or that it's not the
>same game.You CAN argue that the characteristics of the game are
>different and different aspects of the game are emphasized.  
>
>Some really strong players may not be specialists in 9x9 and may lose to
>players who specialize in 9x9 but are otherwise a few stones weaker at
>19x19, but that's not remarkable.   In chess you can also be weakened
>significantly and be "thrown off your game" by a surprise opening - or
>we could imagine a game where your opening is decided for you and it
>would make you very uncomfortable.
>
>My guess (and it's only a guess) is that strong players playing on the
>9x9 board are simply very uncomfortable but probably do not play as weak
>as they imagine.In chess I heard that someone once did a study to
>find out if playing speed chess weakened the performance of some players
>more than others and despite the fact that many players imagine that it
>does, it turned out that there was a remarkable correlation, although no
>doubt some players who specialize at different time controls would have
>an edge.
>
>- Don
>
> 
>
>On Wed, 2008-09-10 at 11:27 +0900, Hideki Kato wrote:
>> Christoph Birk: <[EMAIL PROTECTED]>:
>> >On Tue, 9 Sep 2008, Olivier Teytaud wrote:
>> >> testbed for
>> >> parallelization because it's more difficult) and as "real" targets (as 
>> >> there
>> >> are players
>> >> for both).
>> >
>> >Sorry, but there are (almost) no players for 9x9. To repeat
>> >D.Fotland's earlier comment: 9x9 is just for beginner's practice.
>> >It's not go.
>> 
>> Other than the match CS vs. Kaori Aoba 4p, which Rémi reported 
>> recently, there was a 9x9 match CS vs. Meien O 9p with no komi at 
>> FIT2008.  CS (B) won by 3 points.
>> 
>> I'd like to emphasize "9x9 is Go."
>> 
>> Hideki
>> 
>> >Christoph
>> >
>> >___
>> >computer-go mailing list
>> >computer-go@computer-go.org
>> >http://www.computer-go.org/mailman/listinfo/computer-go/
>> --
>> [EMAIL PROTECTED] (Kato)
>> ___
>> computer-go mailing list
>> computer-go@computer-go.org
>> http://www.computer-go.org/mailman/listinfo/computer-go/
>
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Lockless hash table and other parallel search ideas

[Hideki Kato]

Erik van der Werf: <[EMAIL PROTECTED]>:
>Maybe these are the same?
>
>http://gobase.org/9x9/

Yes but a part.  Unfortunatelly, whole records is temporary not 
available.  Following is the reason (and history) which I can remember 
now.

All records were published (but not sold) in a few booklets.  Dr. 
Saito and Mr. Okasaki made them computer readable ten or more years 
ago.  They are copyrighted by Yomiuri TV but Mr. Okasaki has a grant 
to distribute them for research purposes.  They had been distributed 
under his permission for years.

Last year, Mr. Okasaki studied them precisely and found so many errors 
that he asked me to stop distribution.  I have no idea when I will be 
able to restart.

Hideki

>Erik
>
>On Wed, Sep 10, 2008 at 4:38 PM, Olivier Teytaud <[EMAIL PROTECTED]> wrote:
>>>
>>> - There had been a TV program of professional 9x9 Go for years (some
>>> member of this list have the records of the games played in this
>>> program).  Takemiya 9p and Yuki 9p were the strongest.
>>
>> I'm afraid the answer is no, but:
>> are these records free and available somewhere ?
>>
>> Thanks for your interesting informations around Go and 9x9 Go :-)
>>
>>
>> ___
>> computer-go mailing list
>> computer-go@computer-go.org
>> http://www.computer-go.org/mailman/listinfo/computer-go/
>>
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

[computer-go] Re: 9x9 go Principle Variation with perfect play

[Hideki Kato]

David Fotland: <[EMAIL PROTECTED]>:
>At this point I think everyone would agree that E5 is the optimal first move
>for black on 9x9.

Some Japanese professionals say E5 is 1 to 2 points loss, though komi 
is 6.5 and with Japanese rules.

>Now that I have deeper and more accurate search, my engine favors E7 in
>response to E5 by a large margin.  Do the other strong programs also find
>that E7 is best response?
>
>After E5 E7, there are several moves I've seen from strong engines.  My
>opinion as a go player is that best next move is either E3 or D6.  My
>program chooses different moves here depending on the search settings.

After E5-E7-E3, E2 is prefered by the professinals.

Hideki

>David
>
>
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

[computer-go] Re: Disputes under Japanese rules

[Hideki Kato]

Japanese rules have two procedures to stop the game and to verify 
the score (these names are my personal, not official).

In the case you mentioned, your opponent has no needs to remove the 
stones, if he/she thought the stones are dead (exactly speaking, 
he/she _can_ make the stones dead).

So, he/she simply play pass and the game ends.  After the end of 
game, the players can continue play to check the stones are really 
dead, if necessary.  This procedure does not affect the score if the 
stone are really dead.

The idea of Japanese rules is that the players have no need to remove 
any stones those are dead  at the end of game.

Hideki

Peter Drake: <[EMAIL PROTECTED]>:
>I've asked this question of a couple of people and got different  
>answers, so I thought I'd check here.
>
>Suppose, under Japanese rules, I throw a (hopeless) stone into your  
>territory. I keep passing until you've actually removed it (playing  
>four stones inside your own territory, thus losing a net three  
>points). If you try to pass as well, I stubbornly insist that the  
>stone is alive, thus restarting the game.
>
>What prevents this sort of abuse? Is this one of those cases where the  
>tournament director has to adjudicate?
>
>(This is not a problem under Chinese or AGA rules.)
>
>Peter Drake
>http://www.lclark.edu/~drake/
>
>
>
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

[computer-go] Re: Congratulations to Leela and to Many Faces!

[Hideki Kato]

Hi Nick,

Thank you for origanizing the tounaments.

However, the hardware I (FudoBot) used is wrong.  It was running on a 
loosely coupled cluster of four PCs connected through a usual Gigabit 
Ethernet LAN.  Each PC has one Intel Core2Quad processor running at 
3GHz.  So, 16 cores in total.  

Then you may ask why not strong :).  It's just becaues, other than 
some known bugs,  implementing my parallel MCTS took so many months 
that other parts are not improved since last year.  Say, no 
progressive widening, no smart patterns, etc.

BTW, where followings came from?
>FudoBot 
>Intel(R) Pentium(R) 4 CPU 1.6GHz 

Hideki

Nick Wedd: <[EMAIL PROTECTED]>:
>Congratulations to Leela and to Many Faces of Go, the winners of the two 
>divisions of Sunday's KGS bot tournament.
>
>My report is at http://www.weddslist.com/kgs/past/42/index.html
>I am sure it has as many errors as usual, and I look forward to 
>receiving your corrections.
>
>I would also appreciate views on my proposal to change the time system 
>used for these events, so that instead of say 18 minutes absolute time, 
>they will use 18 minutes plus 20 stones/20 seconds Canadian overtime.  I 
>want to use something with a fairly sharp cutoff, so that the schedule 
>will not be disrupted by overrunning games.  However I want to avoid the 
>situation where a program claims the status of the groups correctly but 
>then loses on time in the clean-up phase.
>
>Nick
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] MoGo v.s. Kim rematch

[Hideki Kato]

David Doshay: <[EMAIL PROTECTED]>:
>It was 800, just like last time, but the networking had been upgraded  
>from ethernet to infiniband. Olivier said that this should have been a  
>good improvement because he felt that communication overhead was  
>significant.

Really previous Huygens used Ethernet?  It's hard to believe...

Hideki

>Cheers,
>David
>
>
>
>On 22, Sep 2008, at 6:06 AM, terry mcintyre wrote:
>
>> Consider this as tentative, since I heard it about 3rd-hand, but I  
>> believe the number of processors used to have been 3000.
>
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] MoGo v.s. Kim rematch

[Hideki Kato]

David,

I've found a description that Infiniband was improved from 2 x 4X IB 
(20 Gbps) to 8 x 8X IB (160 Gbps) on Jun 2008 at the bottom of 6th 
page of a pdf about Huygens system:
https://www.os3.nl/_media/2007-2008/courses/inr/week7/sne_20080320_walter.pdf

I guess that is the "better hardware" Olivier wrote.

Hideki

David Doshay: <[EMAIL PROTECTED]>:
>On 22, Sep 2008, at 10:50 PM, Hideki Kato wrote:

>>
>> David Doshay: <[EMAIL PROTECTED]>:
>>> It was 800, just like last time, but the networking had been upgraded
>>> from ethernet to infiniband. Olivier said that this should have  
>>> been a
>>> good improvement because he felt that communication overhead was
>>> significant.
>>
>> Really previous Huygens used Ethernet?  It's hard to believe...
>>
>> Hideki
>
>I thought so as well, but Olivier wrote to me:
>
>Begin forwarded message:
>
>> From: Olivier Teytaud <[EMAIL PROTECTED]>
>> Date: 6, September 2008 2:07:42 AM PDT
>> To: David Doshay <[EMAIL PROTECTED]>
>> Subject: Re: [computer-go] yet a mogo vs human game
>>
>> Hi David,
>> ...
>>
>> We will have at least the same number of cores, probably more, and  
>> we will very likely have a better hardware -
>> the infiniband network should be available, and this makes a big  
>> difference.
>>
>> ...
>> Best regards,
>> Olivier
>
>
>So, perhaps Huygens has both and they were not using it last time,
>or maybe they brought Huygens up with E-net and then upgraded.
>
>But Mogo did not use it for the Portland exhibition, but did use
>infiniband for the rematch.
>
>Cheers,
>David
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

[computer-go] Re: Results of recent Computer Go events

[Hideki Kato]

Nick Wedd: <[EMAIL PROTECTED]>:
>Does anyone have any information on the results of [the computer Go 
>aspects of] these events?
>
>Cotsen go tournament 2008
>September 20 & 21
>http://www.cotsengotournament.com/   treats it as being in the future
>
>Jiuding Cup
>September 22-26
>http://219.142.86.87/English/index.asp  times out
>
>World 9x9 Computer Go Championship
>September 26 & 27
>http://go.nutn.edu.tw/eng/main_eng.htm   treats it as in the future

Now we can see the results of all five rounds at
http://go.nutn.edu.tw/eng/main_eng.htm.
However, Fudo Go won against HappyGo in round 4.

Following is my private summary.
Pos.Program Score   SOS SoD
1   MoGo10
2   Go Intellect6   16  18
3*  Jimmy   6   16  12
4*  Erica   6   16  12
5   Fudo Go 6   16  6
6   CPS 6   10
7   GoStar  4   20
8   GoKing  4   18
9   HappyGo 2
10  ChangJung1  0   
See http://go.nutn.edu.tw/eng/rule_eng.htm for the rules.
*Jimmy won against Erica in round 5.

Hideki

>
>Why do organisers of Go events held outside Europe so rarely publish the 
>results?  Do they assume that no-one cares who won?  This isn't just 
>computer Go, it is all Go events.
>
>In Europe, even the smallest events, such as the "Cornish Open" with 24 
>participants, produce results tables which are published promptly:  see 
>http://www.britgo.org/results/2008/cornwall.html.  But the 2008 North 
>American Go Congress, which must have had hundreds of participants, has 
>never produced a full table of results.  I am sure a lot of people would 
>be interested in a results table like this one for the 2008 European Go 
>Congress: http://egc2008.eu/en/congress/scoreboard/index.php
>
>
>Nick
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Congratulations to David Fotland!

[Hideki Kato]

Don Dailey: <[EMAIL PROTECTED]>:
>On Thu, 2008-10-02 at 19:17 +0200, Michael Markefka wrote:
>> So, when are we going to see distributed computing? [EMAIL PROTECTED], 
>> [EMAIL PROTECTED], [EMAIL PROTECTED] With Go engines that scale well to 
>> increased 
>> processing capacity, imagine facilitating a few thousand PCs to do the 
>> computing. For good measure, [EMAIL PROTECTED] as about 800,000 nodes online 
>> as 
>> of now.
>
>This subject keeps coming up - but it's not a good application at all
>for this type of thing.   I think if you read the instructions on how to
>do this you will see that it's extremely impractical for a go program.  
>
>Imagine trying to build an interactive chess or go program on an
>incredibly slow network and you will get the picture.   Imagine the
>network is something like using email to communicate.   
>
>The [EMAIL PROTECTED] type of stuff is based on a bunch of machines being able
>to go off and do a work unsupervised - and basically communicating with
>a single centralized process somewhere - very infrequently.  
>
>It might be possible to build a huge cooperating go program network but
>I believe it would require building our own system - and it would be far
>from trivial.   It would have to be designed in an extremely fault
>tolerant way too.

You and David is right in general.  @home type systems are 
good for larger problems without realtimeness.  However, I'd like to 
say it is possible to use such sysytem for computer-go tournament and 
it is not necessary to build my own system.  I'm now at Beijing and 
using a quad-core pc with two Playstation 3 (PS3) consoles connected 
together via a Gigabit Ethernet lan.  One PS3 increases simulations 
about 10% on 9x9 with current not-optimized-for-Cell implementatiion.  
The program running on PS3 Linux is just a simple and small 
application.

The long communication time via Internet will really decrease 
performance of UCT but for larger boards and with much heavier 
playouts that I will use, thousands or more PS3s will be helpful.

Hideki

>- Don
>
>
>
>> 
>> What's the approximate increase in playing level per increase in 
>> processing power? Any rough law for that?
>> 
>> Best regards,
>> Mike
>> 
>> 
>> Olivier Teytaud wrote:
>> > Mogo was allowed to use 800 cores, not more, and only for games against 
>> > humans.
>> > We have no acces to so many cores for computer-computer games (if there 
>> > were only three teams involved,
>> > we could :-) ).
>> > For some games Huygens was unaivalable at all, and mogo played with much 
>> > weaker hardware (some quad-cores,
>> > however, it is not so bad :-) ).
>> > 
>> > Best regards,
>> > Olivier
>> > 
>> > 
>> > 
>> > 
>> > ___
>> > computer-go mailing list
>> > computer-go@computer-go.org
>> > http://www.computer-go.org/mailman/listinfo/computer-go/
>> 
>> ___
>> computer-go mailing list
>> computer-go@computer-go.org
>> http://www.computer-go.org/mailman/listinfo/computer-go/
> inline file
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

[computer-go] Re: Tiebreak 9x9 in Beijing ?!

[Hideki Kato]

I don't know the detail but the cluster (or the connection) had some
trouble and the play-off will be resumed this morning (at Beijing
time; +0800).

Hideki

Ingo Althöfer: <[EMAIL PROTECTED]>:
>Olivier Teytaud wrote here:
>> ... and good luck for both MoGo and Leela for 
>> the silver medal in 9x9 :-)
>
>I saw on KGS that one tiebreak game between MoGo
>and Leela was played today: starting time 13:00 GMT,
>MoGo with Black starting with 4,3 move, and Leela
>winning.
>
>When I understood GCP correctly, another game
>with colors exchanged has to be played ... and one more
>Amageddon game in case of a 1-1 score after the two.
>
>Does someone here know what happened?
>
>Thx in advance, Ingo.
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Congratulations again to David Fotland !

[Hideki Kato]

David Fotland: <[EMAIL PROTECTED]>:
>Gostar and Yogo were also classical on 19x19.  Yogo was MCTS on 9x9.  I
>don't know about Break.  Gostar's author said he will now rewrite to use
>MCTS.

Break is not MCTS.  The author of NineHeadBird also said he will
rewrite and attend next year.

Hideki

>It is very clear to me that MCTS is very well suited to computer go.  It has
>some real issues though, so I think the best approach is MCTS that uses
>tradition program knowledge (like Many Faces).
>
>David
>
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of Ian Osgood
>Sent: Saturday, October 04, 2008 9:21 AM
>To: computer-go
>Subject: Re: [computer-go] Congratulations again to David Fotland !
>
>
>On Oct 4, 2008, at 5:23 AM, Ingo Althöfer wrote:
>
>> Hello,
>>
>> Many Faces of Go has won also the 19x19 competition
>> in the "13th International Computer Games Championships",
>> with a 100 % score.  The silver medal goes to MoGo (only
>> loss against MFoG), Leela achieves Bronze (only two losses,
>> against MFoG and MoGo).
>>
>> Details, including sgf-files, under
>> http://www.grappa.univ-lille3.fr/icga/tournament.php?id=181
>>
>> Congratulations again to David!
>>
>> Ingo.
>
>Congrats to all! This is another strong validation of the scalability  
>of Monte Carlo search. Were there any classical programs competing  
>besides Katsunari?
>
>Before the conference closes, it would be interesting to play the  
>field with GNU Go, to see where it would fall in the lineup if it had  
>competed this year as a measure of recent progress.
>
>Ian
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
>
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] programming languages

[Hideki Kato]

SIMD version of SFMT is 3 to 7 time faster than MT.  See 
http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/speed.html
for detail.

Hideki

Don Dailey: <[EMAIL PROTECTED]>:
>On Thu, 2008-10-09 at 15:20 -0400, [EMAIL PROTECTED] wrote:
>> Computers + random = can of worms.
>
>Has anyone seen this:
>
> http://home.southernct.edu/~pasqualonia1/ca/report.html#files
>
>They are claiming impressive speed and high quality for a random number
>generator.   The code is compact and small, much nicer than mt19937 and
>the speed seems to blow mt19937 out of the water.
>
>I haven't looked at any papers on this and I'm wondering how good it is.
>
> Here is quote:
>
>
>The cellular automaton outperforms the GSL random number
>generators, being more than three times as fast as the GSL
>generators.
>
>The following table shows the mean time for 10 runs of each
>generator, with each run producing 10 million integers. Source
>code for both the GSL generators and the cellular automaton was
>compiled using GCC version 4.1.0 with the -O2 optimization flag.
>
>RNG:  Mean time to produce 10 million integers:
>
>cellular automaton0.062000 seconds
>gsl_rng_taus  0.20 seconds
>gsl_rng_gfsr4 0.20 seconds
>gsl_rng_mt19937   0.223000 seconds
>gsl_rng_ranlxd1   2.652000 seconds
>
>
>- Don
> inline file
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

[computer-go] 2nd GPW Cup Computer Go Tournament in Hakone, Japan

[Hideki Kato]

The 2nd GPW Cup Gomputer Go Tournament will be held as a night event 
of Game Programming Workshop 2008.
GPW2008:  http://sig-gi.c.u-tokyo.ac.jp/gpw/2008/ (in Japanese)
#Those who can't read Japanese and have interests in paticipating GPW 
Cup Computer Go Tournament, please mail me.

The 13th Game Programming Workshop will be held November 7 - 9 at 
Hakone Seminor House, Hakone, Japan.  GPW Cup Computer Go 
Tournament will be held at the first and second nights, together with 
the other night events, such as GPW Cup Computer Shogi Tournament, 
using Chinese rules, round robin alternating black and white, 15 
minutes SD, and 6.5 points komi.  Participants have to prepare 
necessary equipments by themselves (no Internet connection is 
available at the Seminor House, no loan PCs and/or no agents are 
provided by the organizer).  The programs should be original.  Human 
players can participate as well.

The rules of the tournament may be changed on particular conditions if 
necessary, ex., if there will be too many participants to keep the 
schedule.

Hideki
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

[computer-go] Tainan & Beijing Pix

[Hideki Kato]

Hi all,

Here are some pictures on my thirteen days trip to World 9 x 9 
Computer GO Championship (Tainan, Taiwan) and ICGA International 
Computer Games Champioinship (Beijing, China).
http://www.gggo.jp/13days/

The official pages for the Tainan and Beijing tournaments are
http://go.nutn.edu.tw/ and 
http://www.grappa.univ-lille3.fr/icga/event.php?id=37.

Hideki
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] The 2nd Comuputer Go UEC Cup

[Hideki Kato]

Seems Ito-sensen is very busy...

The committee prepares a very limited number of volunteer operators.  
See "4-3 Volunteer Operators" at 
http://jsb.cs.uec.ac.jp/~igo/2008/eng/sankayouken.html for detail.

Hideki

David Fotland: <[EMAIL PROTECTED]>:
>Do we have to show up in person, or can our programs be operated for us?
>
>David Fotland
>
>> -Original Message-
>> From: [EMAIL PROTECTED] [mailto:computer-go-
>> [EMAIL PROTECTED] On Behalf Of "TAKESHI ITO"
>> Sent: Monday, October 27, 2008 7:22 PM
>> To: computer-go@computer-go.org
>> Subject: [computer-go] The 2nd Comuputer Go UEC Cup
>> 
>> 
>> 
>> *
>>  CALL FOR PARTICIPATION
>> 
>>  The 2nd Computer Go UEC Cup
>>The University of Electro-Communication,
>>Tokyo, Japan, 13-14 December 2008
>>http://jsb.cs.uec.ac.jp/~igo/2008/eng/index.html
>> *
>> 
>> #Important Information
>>Championship: December 13-14, 2008
>>Entry's Deadline: November 28, 2008
>> 
>> #Schedule
>>December 13
>>  Preliminary Match
>>December 14
>>  Final Tournament
>>  Exhibition Match
>>  Explanation by professional Igo player
>> 
>> #Guest Comentator
>>Mr.Cheng Ming Huang(9th-grade), Ms.Kaori Aoba(4th-grade)
>> 
>> #Event
>>Exhibition match:  Ms.Kaori Aoba(4th-grade) VS Championship Program
>> (Handicap Game)
>> 
>> #Entry
>>Cost:free
>>Entry:accepting now
>>  http://jsb.cs.uec.ac.jp/~igo/2008/eng/mailform.html
>> 
>> #Venue
>>The University of Electro-communications
>>: Building W-9 3F AV hall(campus map:40)
>> 1-5-1 Chofugaoka, Chofu-shi, Tokyo 182-8585 Japan.
>> 
>> #Past
>>The 1st Comuputer Go UEC Cup
>>   http://jsb.cs.uec.ac.jp/~igo/2007/eng/index.html
>> 
>> #Host Organizer
>>Cognitive Science and Entertainment (E&C) Research Station,
>>The University of Electro-communications
>> 
>> #Support
>>Computer Go Forum
>> 
>> #Contact (Tournament committee)
>>[EMAIL PROTECTED]
>> 
>> 
>>   -
>>Takeshi Ito
>>   The University of Electro-Communications
>>   [EMAIL PROTECTED]
>> ___
>> computer-go mailing list
>> computer-go@computer-go.org
>> http://www.computer-go.org/mailman/listinfo/computer-go/
>
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] The 2nd Comuputer Go UEC Cup

[Hideki Kato]

Seems Ito-sensei is very busy...

Remote computing is allowed.  See "1-4: Using a Remote Host via the 
Internet" at http://jsb.cs.uec.ac.jp/~igo/2008/eng/sankayouken.html 
("Requirements for participation" in the side menu) for detail.

Hideki

David Doshay: <[EMAIL PROTECTED]>:
>Will remote computing be allowed, or do we need to have our hardware  
>on site?
>
>Cheers,
>David
>
>
>
>On 27, Oct 2008, at 7:21 PM, TAKESHI ITO wrote:
>
>>
>>
>> *
>> CALL FOR PARTICIPATION
>>
>> The 2nd Computer Go UEC Cup
>>   The University of Electro-Communication,
>>   Tokyo, Japan, 13-14 December 2008
>>   http://jsb.cs.uec.ac.jp/~igo/2008/eng/index.html
>> *
>>
>> #Important Information
>>   Championship: December 13-14, 2008
>>   Entry's Deadline: November 28, 2008
>>
>> #Schedule
>>   December 13
>> Preliminary Match
>>   December 14
>> Final Tournament
>> Exhibition Match
>> Explanation by professional Igo player
>>
>> #Guest Comentator
>>   Mr.Cheng Ming Huang(9th-grade), Ms.Kaori Aoba(4th-grade)
>>
>> #Event
>>   Exhibition match:  Ms.Kaori Aoba(4th-grade) VS Championship  
>> Program (Handicap Game)
>>
>> #Entry
>>   Cost:free
>>   Entry:accepting now
>> http://jsb.cs.uec.ac.jp/~igo/2008/eng/mailform.html
>>
>> #Venue
>>   The University of Electro-communications
>>   : Building W-9 3F AV hall(campus map:40)
>>1-5-1 Chofugaoka, Chofu-shi, Tokyo 182-8585 Japan.
>>
>> #Past
>>   The 1st Comuputer Go UEC Cup
>>  http://jsb.cs.uec.ac.jp/~igo/2007/eng/index.html
>>
>> #Host Organizer
>>   Cognitive Science and Entertainment (E&C) Research Station,
>>   The University of Electro-communications
>>
>> #Support
>>   Computer Go Forum
>>
>> #Contact (Tournament committee)
>>   [EMAIL PROTECTED]
>>
>>
>>  -
>>   Takeshi Ito
>>  The University of Electro-Communications
>>  [EMAIL PROTECTED]
>> ___
>> computer-go mailing list
>> computer-go@computer-go.org
>> http://www.computer-go.org/mailman/listinfo/computer-go/
>
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] The 2nd Comuputer Go UEC Cup

[Hideki Kato]

David Doshay: <[EMAIL PROTECTED]>:
>This is wonderful news for SlugGo, but unfortunately my wife just  
>booked a
>vacation for us at the same time. I will have to wait until next time  
>to be
>able to attend.

That's unlucky for us.

>I will plan to hold this time open next year and hope that you will be  
>holding
>the tournament again at that time.

We look forward you and SlugGo next year.  This tournament will be 
held on weekend every early December but not guaranteed.

You are welcome,
Hideki

>Thank you,
>David
>
>
>
>On 28, Oct 2008, at 8:00 PM, Hideki Kato wrote:
>
>> Seems Ito-sensei is very busy...
>>
>> Remote computing is allowed.  See "1-4: Using a Remote Host via the
>> Internet" at http://jsb.cs.uec.ac.jp/~igo/2008/eng/sankayouken.html
>> ("Requirements for participation" in the side menu) for detail.
>>
>> Hideki
>>
>> David Doshay: <[EMAIL PROTECTED]>:
>>> Will remote computing be allowed, or do we need to have our hardware
>>> on site?
>>>
>>> Cheers,
>>> David
>>>
>>>
>>>
>>> On 27, Oct 2008, at 7:21 PM, TAKESHI ITO wrote:
>>>
>>>>
>>>>
>>>> *
>>>> CALL FOR PARTICIPATION
>>>>
>>>> The 2nd Computer Go UEC Cup
>>>>  The University of Electro-Communication,
>>>>  Tokyo, Japan, 13-14 December 2008
>>>>  http://jsb.cs.uec.ac.jp/~igo/2008/eng/index.html
>>>> *
>>>>
>>>> #Important Information
>>>>  Championship: December 13-14, 2008
>>>>  Entry's Deadline: November 28, 2008
>>>>
>>>> #Schedule
>>>>  December 13
>>>>Preliminary Match
>>>>  December 14
>>>>Final Tournament
>>>>Exhibition Match
>>>>Explanation by professional Igo player
>>>>
>>>> #Guest Comentator
>>>>  Mr.Cheng Ming Huang(9th-grade), Ms.Kaori Aoba(4th-grade)
>>>>
>>>> #Event
>>>>  Exhibition match:  Ms.Kaori Aoba(4th-grade) VS Championship
>>>> Program (Handicap Game)
>>>>
>>>> #Entry
>>>>  Cost:free
>>>>  Entry:accepting now
>>>>http://jsb.cs.uec.ac.jp/~igo/2008/eng/mailform.html
>>>>
>>>> #Venue
>>>>  The University of Electro-communications
>>>>  : Building W-9 3F AV hall(campus map:40)
>>>>   1-5-1 Chofugaoka, Chofu-shi, Tokyo 182-8585 Japan.
>>>>
>>>> #Past
>>>>  The 1st Comuputer Go UEC Cup
>>>> http://jsb.cs.uec.ac.jp/~igo/2007/eng/index.html
>>>>
>>>> #Host Organizer
>>>>  Cognitive Science and Entertainment (E&C) Research Station,
>>>>  The University of Electro-communications
>>>>
>>>> #Support
>>>>  Computer Go Forum
>>>>
>>>> #Contact (Tournament committee)
>>>>  [EMAIL PROTECTED]
>>>>
>>>>
>>>> -
>>>>  Takeshi Ito
>>>> The University of Electro-Communications
>>>> [EMAIL PROTECTED]
>>>> ___
>>>> computer-go mailing list
>>>> computer-go@computer-go.org
>>>> http://www.computer-go.org/mailman/listinfo/computer-go/
>>>
>>> ___
>>> computer-go mailing list
>>> computer-go@computer-go.org
>>> http://www.computer-go.org/mailman/listinfo/computer-go/
>> --
>> [EMAIL PROTECTED] (Kato)
>> ___
>> computer-go mailing list
>> computer-go@computer-go.org
>> http://www.computer-go.org/mailman/listinfo/computer-go/
>
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] The 2nd Comuputer Go UEC Cup

[Hideki Kato]

Yes.  You (or, possibly an agent) will have to play by hand.

This, however, is so common in Computer Olympiad tournaments that I 
guess it's not a big problem.

Hideki

terry mcintyre: <[EMAIL PROTECTED]>:
>The protocol used is described as a "modified NNGS" protocol. The paragraph on 
>remote 
>computing seems to suggest that no direct connection between the Internet and 
>the tournament 
>is permitted; that an operator must manually transfer moves from the remote 
>computer to a GUI 
>which is connected to the local network. You'll want to tune your computer to 
>leave a margin 
>for that manual transfer of information.
>
>If I understand the site correctly, remote computing is permitted when the 
>computer is so 
>huge that it cannot be brought to the venue. 
>
>Excerpt follows:
>
>
>Another way to join the UEC Cup without bringing in a computer 
>is to use the Internet connection for game information exchange.
>This is used when the computer of a competitor is so huge that
>he/she cannot bring it to the venue. Because of security purpose, 
>we do not allow to play a game on the Internet.
>The Internet connection must only be used for 
>communicating between a (possibly delegated) operator 
>in the conference room and a remote computer.
>The operator then must use some GUI program
>to play a match. See 2-2 for using GUI program. Anyone who want to use a 
>remote host must 
>submit a written format to the UEC Cup committee
>at registration, and receive a permission for remote play. 
>2: Playing a Match
>2-1 Playing through Network
>Games are played over a TCP/IP network.
>A game managing server will be set up to manage the game.
>A programs should be able to play games over the network.
>For the protocols, see Protocols. 
>2-2 Playing by hand
>If games over the network are impossible for a program,
>the competitor can manually input moves through the GUI program
>the UEC Cup office prepares.
>In this case, the following conditions will be applied.
>The operator must input a move designated by the program.
>If he/she input different moves, the competitor loses the game immediately.
>The time to input moves is also clocked. 
>
>
>
> Terry McIntyre <[EMAIL PROTECTED]>
>
>
>-- Libertarians Do It With Consent!
>
>
>
>- Original Message 
>> From: Hideki Kato <[EMAIL PROTECTED]>
>> To: computer-go 
>> Cc: TAKESHI ITO <[EMAIL PROTECTED]>
>> Sent: Tuesday, October 28, 2008 8:00:06 PM
>> Subject: Re: [computer-go] The 2nd Comuputer Go UEC Cup
>> 
>> Seems Ito-sensei is very busy...
>> 
>> Remote computing is allowed.  See "1-4: Using a Remote Host via the 
>> Internet" at http://jsb.cs.uec.ac.jp/~igo/2008/eng/sankayouken.html 
>> ("Requirements for participation" in the side menu) for detail.
>> 
>> Hideki
>> 
>> David Doshay: <[EMAIL PROTECTED]>:
>> >Will remote computing be allowed, or do we need to have our hardware  
>> >on site?
>> >
>> >Cheers,
>> >David
>> >
>> >
>> >
>> >On 27, Oct 2008, at 7:21 PM, TAKESHI ITO wrote:
>> >
>> >>
>> >>
>> >> *
>> >> CALL FOR PARTICIPATION
>> >>
>> >> The 2nd Computer Go UEC Cup
>> >>   The University of Electro-Communication,
>> >>   Tokyo, Japan, 13-14 December 2008
>> >>  http://jsb.cs.uec.ac.jp/~igo/2008/eng/index.html
>> >> *
>> >>
>> >> #Important Information
>> >>   Championship: December 13-14, 2008
>> >>   Entry's Deadline: November 28, 2008
>> >>
>> >> #Schedule
>> >>   December 13
>> >> Preliminary Match
>> >>   December 14
>> >> Final Tournament
>> >> Exhibition Match
>> >> Explanation by professional Igo player
>> >>
>> >> #Guest Comentator
>> >>   Mr.Cheng Ming Huang(9th-grade), Ms.Kaori Aoba(4th-grade)
>> >>
>> >> #Event
>> >>   Exhibition match:  Ms.Kaori Aoba(4th-grade) VS Championship  
>> >> Program (Handicap Game)
>> >>
>> >> #Entry
>> >>   Cost:free
>> >>   Entry:accepting now
>> >>http://jsb.cs.uec.ac.jp/~igo/2008/eng/mailform.html
>> >>
>> >> #Venue
>> >>   The University of Electro-communications
>> >>   : B

[computer-go] Re: List of go engines

[Hideki Kato]

Thank you Eric,

GGMC and FudoGo ('Fudo Go' is proper like 'GNU Go') support only 
Linux.  The Elo rating of FudoGo v3 is between 2000 and 2100 on CGOS 
9x9 using four cores.

Hideki

Eric Marchand: <[EMAIL PROTECTED]>:
>Hi all,
>Here is a list of 24 free go engines (18 with source):
>http://ricoh51.free.fr/go/engineeng.htm
>Please let me know if there are errors or omissions.
>
>eric
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

[computer-go] Re: Monte-Carlo and Japanese rules

[Hideki Kato]

Hello Ingo,

You (we) have to adjust one point if a game ends by black in usual
(no seko etc) cases.  As Japanese doesn't count dame while Chinese
does, if a game ends by black, black gets one more point under Chinese
rules than Japanese.

Hideki

Ingo Althöfer: <[EMAIL PROTECTED]>:
>Hello all, two questions.
>
>(i) Do there exist strong 9x9-go programs on Monte-Carlo base
>for Japanese rules?
>
>(ii) Having available only programs for Chinese rules, but playing
>in a tournament with Japanese rules, which special tricks and
>settings should be used to maximise winning chances? (This is meant
>especially in the light of MC's tendency to win games by 0.5
>points according to the rules implemented.)
>
>Ingo.
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

[computer-go] GPW08 paper: Parallel MCTS

[Hideki Kato]

Hi,

This is my GPW08 paper.

Parallel Monte-Carlo Tree Search with Simulation Servers
by Hideki Kato and Ikuo Takeuchi

Abstract: Recently Monte-Carlo tree search is boosting the performance 
of computer Go playing programs. A novel parallel Monte-Carlo tree 
search algorithm is proposed. A tree searcher runs on a client 
computer and multiple Monte-Carlo simulation servers run on other 
computers on a network. The client broadcasts a position to be 
simulated to every server, which then simulates a game from the 
position to the end and sends the result (win or loss) back to the 
client. The statistical information in the search tree is updated by 
the client according to the result. This architecture allows servers 
on-the-fly connection or disconnection. Experimental results using 
four quad-core Linux computers on a private Gigabit Ethernet LAN show 
its performance scales well.

http://www.gggo.jp/publications/gpw08-private.pdf
http://www.gggo.jp/publications/gpw08.ppt

If you read the paper, please check gpw08.ppt together as it contains 
revised charts which will help avoid confusion.

Hideki
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

[computer-go] Result of 2nd GPW Cup Computer Go Tournament in Hakone, Japan

[Hideki Kato]

Japanese version of the result of 2nd GPW Cup Computer Go Tournament 
is available at 
http://sig-gi.c.u-tokyo.ac.jp/gpw/2008/night.html#go-results

English version follows.

Ten programs from three countries were participated and we changed 
planed alternating BW round-robin to simple one.

HappyGo was resigned after 5th round due to critical bugs.
MC_arc had troubles in time control.

Date: November 7 and 8, 2008.
Place: Surugadai-gakuen Hakone seminor house Kounso, Sengokuhara 
845, Hakone, Kanagawa, Japan.
Format: round-robin
Rules: Chinese
Komi: 6.5
Time: 15 minutes

[Result]
Pos Program  Operator  Country Hardware Win Type
  1 MoGo Arpad Rimmel  France  4x3 GHz9 MCTS
  2 Aya  Hiroshi Yamashita Japan   8x2.6 GHz  8 MC/UCT
  3 Fudo Go  Hideki Kato   Japan   4x3.4 GHz  7 MC/UCT
  4 JimmyShun-Chin Hsu Taiwan  laptop 6 MC/UCT
  5 DMC  Matsui & Noguchi  Japan   laptop 5 MC/UCT
  6 KK   Satohiro Kadowaki Japan   laptop 4 MC/UCT
  7 KatsunariShin'ich Sei  Japan   laptop 3 Classic
  8 KIDS For IGo Nozomu IkehataJapan   laptop 2 Pattern
  9 MC_arc   Nobuo Araki   Japan   4x2.4 GHz  1 MC/UCT
 10 HappyGo  Yong-Ler Wang Taiwan  laptop 0 MCTS?

[Cross table]
No Program  1  2  3  4  5  6  7  8  9 10 Point
 1 MoGo -  1  1  1  1  1  1  1  1  1 9
 2 Aya  0  -  1  1  1  1  1  1  1  1 8
 3 Fudo Go  0  0  -  1  1  1  1  1  1  1 7
 4 Jimmy0  0  0  -  1  1  1  1  1  1 6
 5 DMC  0  0  0  0  -  1  1  1  1  1 5
 6 KK   0  0  0  0  0  -  1  1  1  1 4
 7 Katsunari0  0  0  0  0  0  -  1  1  1 3
 8 KIDS For IGo 0  0  0  0  0  0  0  -  1  1 2
 9 MC_arc   0  0  0  0  0  0  0  0  -  1 1
10 HappyGo  0  0  0  0  0  *  *  *  *  - 0

Director of the tournament,
Hideki Kato

Hideki Kato: <[EMAIL PROTECTED]>:
>The 2nd GPW Cup Gomputer Go Tournament will be held as a night event 
>of Game Programming Workshop 2008.
>GPW2008:  http://sig-gi.c.u-tokyo.ac.jp/gpw/2008/ (in Japanese)
>#Those who can't read Japanese and have interests in paticipating GPW 
>Cup Computer Go Tournament, please mail me.
>
>The 13th Game Programming Workshop will be held November 7 - 9 at 
>Hakone Seminor House, Hakone, Japan.  GPW Cup Computer Go 
>Tournament will be held at the first and second nights, together with 
>the other night events, such as GPW Cup Computer Shogi Tournament, 
>using Chinese rules, round robin alternating black and white, 15 
>minutes SD, and 6.5 points komi.  Participants have to prepare 
>necessary equipments by themselves (no Internet connection is 
>available at the Seminor House, no loan PCs and/or no agents are 
>provided by the organizer).  The programs should be original.  Human 
>players can participate as well.
>
>The rules of the tournament may be changed on particular conditions if 
>necessary, ex., if there will be too many participants to keep the 
>schedule.
>
>Hideki
>--
>[EMAIL PROTECTED] (Kato)
>___
>computer-go mailing list
>computer-go@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] FW: computer-go] Monte carlo play?

[Hideki Kato]

Hello Heikki,

Heikki Levanto: <[EMAIL PROTECTED]>:
>On Sat, Nov 15, 2008 at 11:38:34PM +0100, [EMAIL PROTECTED] wrote:
>> Being a computer scientist but new to go, i can grasp some of the theory.
>> The question I was trying to get across was:
>> 
>> In a game of self play, if both parties are employing only monte carlo,
>> surely its not a good conceptual representation of a human, and if the
>> reinforcement learning is based on random simulations wouldnt it be very
>> weak when playing a real human?
>
>
>Here is another amateur answering.
>
>The way I understand it, modern Monte Carlo programs do not even try to
>emulate a human player with a random player - obviously that would not work.

I believe CrazyStone's use of patterns does so and it seems 
successful.

Hideki

>What they do is that they build a quite traditional search tree starting from
>the current position. They use a random playout as a crude way to evaluate a
>position. Based on this evaluation, they decide which branch of the tree to
>expand.
>
>This is the way I understand the random playouts: If, in a given position,
>white is clearly ahead, he will win the game if both parts play perfect
>moves. He is also likely to win if both parts play reasonably good moves
>(say, like human amateurs), but there is a bit more of a chance that one
>player hits upon a good combination which the other misses, so the result is
>not quite as reliable. If the playouts are totally random, there is still a
>better chance for white to win, because both parts make equally bad moves.
>The results have much more variation, of course. So far it does not sound
>like a very good proposal, but things change if you consider the facts that
>we don't have perfecr oracles, and good humans are slow to play out a
>position, and can not be integrated into a computer program. Whereas random
>playouts can be done awfully fast, tens of thousands of playouts in a second.
>Averaging the reuslts gives a fair indication of who is more likely to win
>from that position, just what is needed to decide which part of the search
>tree to expand.
>
>The 'random' playouts are not totally random, they include a minimum of
>tactical rules (do not fill own eyes, do not pass as long as there are valid
>moves). Even this little will produce a few blind spots, moves that the
>playouts can not see, and systematically wrong results. Adding more
>go-specific knowledge can make the results much better (more likely to be
>right), but can also add some more blind spots. And it costs time, reducing
>the number of playouts the program can make.
>
>Hope that explains something of the mystery
>
>
>Regards
>
>   Heikki
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

[computer-go] Re: Congratulations to Many Faces of Go!

[Hideki Kato]

Nick Wedd: <[EMAIL PROTECTED]>:
>My report on Sunday's KGS bot tournament is now available at
>http://www.weddslist.com/kgs/past/44/index.html
>Many Faces of Go was undefeated in both divisions.

Did Many Faces 1 and 2 share the same cluster or one for each?

Hideki
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/