RE: [computer-go] Re: fuego strength

[David Fotland]

I just tried again and it's working now, so Many Faces is on 19x19, running
an older version on a slow computer 1.6 Ghz Pentium M.  I don't use this
computer, so it should stay up.  Let me know if it drops off and I can
restart it.

 

David

 

From: computer-go-boun...@computer-go.org
[mailto:computer-go-boun...@computer-go.org] On Behalf Of Don Dailey
Sent: Wednesday, July 01, 2009 4:55 AM
To: computer-go
Subject: Re: [computer-go] Re: fuego strength

 

It is working.   That is pretty odd that it would not get scheduled.   

As for the new server,  I want to do a test and then a switchover soon, the
code is in a state where it is usable.It will not schedule the same
pairing twice in a row unless those are the only 2 players.   

I do not want to put it up until I can be "highly available" in case there
are troubles.  This weekend I will be out Fri-Sun and I'll be away today and
tomorrow - so it will be next week.   But I'm eager to get it going and I
hope a lot of people will help me test it.

- Don





On Wed, Jul 1, 2009 at 2:18 AM, David Fotland 
wrote:

Is cgos working?  It tried putting Many faces on 19x19 a few days ago.  It
logged it on, and told it there would be a new match later, but there were
two programs on and it kept playing them against each other over and over
without scheduling ManyFaces, so after a few hours I killed it.


David

> -Original Message-
> From: computer-go-boun...@computer-go.org [mailto:computer-go-

> boun...@computer-go.org] On Behalf Of Thomas Lavergne
> Sent: Friday, June 26, 2009 12:22 AM
> To: computer-go
> Subject: Re: [computer-go] Re: fuego strength
>

> On Wed, Jun 24, 2009 at 12:39:05PM -0400, Jason House wrote:
> > That raises an interesting point. I've also put bots up in a setup and
> > forget scenario, but inevitably the bit is off of CGOS within a few days
> > and I had no idea when it went down.
> >
> > What's the right way to solve this issue so such altruistic bots can be
> > more easilly maintained? This may also help the anchor absence issue
too.
>
> If cgosclient not only stall but really crash (due to itself, your
> program or more probably a network failure) you can just put it in
> script with a loop :
>
> runme.sh:
>   #!/bin/sh
>   while true
>   do
>   cgosclient
>   done
>
> I've done this in the past and it works well. I suppose you
> can do something similar on Windows, but as I know almost anything about
> windows I can't you for it.
>
> I recomand putting a 'mail' in the loop for sending you informations
> about the crash. And to be gently with the server, adding a 'sleep x' in
> order to wait a bit before reconnecting.
>
> Tom
>
> --
> Thomas Lavergne"Entia non sunt multiplicanda praeter
>  necessitatem." (Guillaume d'Ockham)
> thomas.laver...@reveurs.orghttp://oniros.org
> ___
> 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/

Re: [computer-go] Re: fuego strength

[Don Dailey]

It is working.   That is pretty odd that it would not get scheduled.

As for the new server,  I want to do a test and then a switchover soon, the
code is in a state where it is usable.It will not schedule the same
pairing twice in a row unless those are the only 2 players.

I do not want to put it up until I can be "highly available" in case there
are troubles.  This weekend I will be out Fri-Sun and I'll be away today and
tomorrow - so it will be next week.   But I'm eager to get it going and I
hope a lot of people will help me test it.

- Don




On Wed, Jul 1, 2009 at 2:18 AM, David Fotland wrote:

> Is cgos working?  It tried putting Many faces on 19x19 a few days ago.  It
> logged it on, and told it there would be a new match later, but there were
> two programs on and it kept playing them against each other over and over
> without scheduling ManyFaces, so after a few hours I killed it.
>
> David
>
> > -Original Message-
> > From: computer-go-boun...@computer-go.org [mailto:computer-go-
> > boun...@computer-go.org] On Behalf Of Thomas Lavergne
> > Sent: Friday, June 26, 2009 12:22 AM
> > To: computer-go
> > Subject: Re: [computer-go] Re: fuego strength
> >
> > On Wed, Jun 24, 2009 at 12:39:05PM -0400, Jason House wrote:
> > > That raises an interesting point. I've also put bots up in a setup and
> > > forget scenario, but inevitably the bit is off of CGOS within a few
> days
> > > and I had no idea when it went down.
> > >
> > > What's the right way to solve this issue so such altruistic bots can be
> > > more easilly maintained? This may also help the anchor absence issue
> too.
> >
> > If cgosclient not only stall but really crash (due to itself, your
> > program or more probably a network failure) you can just put it in
> > script with a loop :
> >
> > runme.sh:
> >   #!/bin/sh
> >   while true
> >   do
> >   cgosclient
> >   done
> >
> > I've done this in the past and it works well. I suppose you
> > can do something similar on Windows, but as I know almost anything about
> > windows I can't you for it.
> >
> > I recomand putting a 'mail' in the loop for sending you informations
> > about the crash. And to be gently with the server, adding a 'sleep x' in
> > order to wait a bit before reconnecting.
> >
> > Tom
> >
> > --
> > Thomas Lavergne"Entia non sunt multiplicanda praeter
> >  necessitatem." (Guillaume d'Ockham)
> > thomas.laver...@reveurs.orghttp://oniros.org
> > ___
> > 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/

RE: [computer-go] Re: fuego strength

[David Fotland]

Is cgos working?  It tried putting Many faces on 19x19 a few days ago.  It
logged it on, and told it there would be a new match later, but there were
two programs on and it kept playing them against each other over and over
without scheduling ManyFaces, so after a few hours I killed it.

David

> -Original Message-
> From: computer-go-boun...@computer-go.org [mailto:computer-go-
> boun...@computer-go.org] On Behalf Of Thomas Lavergne
> Sent: Friday, June 26, 2009 12:22 AM
> To: computer-go
> Subject: Re: [computer-go] Re: fuego strength
> 
> On Wed, Jun 24, 2009 at 12:39:05PM -0400, Jason House wrote:
> > That raises an interesting point. I've also put bots up in a setup and
> > forget scenario, but inevitably the bit is off of CGOS within a few days
> > and I had no idea when it went down.
> >
> > What's the right way to solve this issue so such altruistic bots can be
> > more easilly maintained? This may also help the anchor absence issue
too.
> 
> If cgosclient not only stall but really crash (due to itself, your
> program or more probably a network failure) you can just put it in
> script with a loop :
> 
> runme.sh:
>   #!/bin/sh
>   while true
>   do
>   cgosclient
>   done
> 
> I've done this in the past and it works well. I suppose you
> can do something similar on Windows, but as I know almost anything about
> windows I can't you for it.
> 
> I recomand putting a 'mail' in the loop for sending you informations
> about the crash. And to be gently with the server, adding a 'sleep x' in
> order to wait a bit before reconnecting.
> 
> Tom
> 
> --
> Thomas Lavergne"Entia non sunt multiplicanda praeter
>  necessitatem." (Guillaume d'Ockham)
> thomas.laver...@reveurs.orghttp://oniros.org
> ___
> 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/

Re: [computer-go] Re: fuego strength

[Thomas Lavergne]

On Wed, Jun 24, 2009 at 12:39:05PM -0400, Jason House wrote:
> That raises an interesting point. I've also put bots up in a setup and  
> forget scenario, but inevitably the bit is off of CGOS within a few days 
> and I had no idea when it went down.
>
> What's the right way to solve this issue so such altruistic bots can be 
> more easilly maintained? This may also help the anchor absence issue too.

If cgosclient not only stall but really crash (due to itself, your
program or more probably a network failure) you can just put it in
script with a loop :

runme.sh:
#!/bin/sh
while true
do
cgosclient
done

I've done this in the past and it works well. I suppose you
can do something similar on Windows, but as I know almost anything about
windows I can't you for it.

I recomand putting a 'mail' in the loop for sending you informations
about the crash. And to be gently with the server, adding a 'sleep x' in
order to wait a bit before reconnecting.

Tom

-- 
Thomas Lavergne"Entia non sunt multiplicanda praeter
 necessitatem." (Guillaume d'Ockham)
thomas.laver...@reveurs.orghttp://oniros.org
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Re: fuego strength

[Don Dailey]

There is no provision as such - but it could be added externally.  I briefly
considered making authors register their bots in a separate step and that
would have been the natural place to add this.But I decided against
adding extra procedure.

So I will put this on the wish-list of things to add to the web-side of
things.

- Don


2009/6/24 Jason House 

> Will the new server handle small description strings about the bots? It'd
> be great if we could provide/lookup basic data on bots. Example data would
> be a homepage or a 1-2 sentence summary. For example "John Smith's
> experimental Fuego 0.4 with heavy playout for reading semeai"
>
> Sent from my iPhone
>
> On Jun 24, 2009, at 1:12 PM, Don Dailey  wrote:
>
>
>
> On Wed, Jun 24, 2009 at 12:52 PM, Michael Williams 
> <
> michaelwilliam...@gmail.com> wrote:
>
>> A while back, I wrote a general purpose monitor tool that checks a
>> specified URL for a specified RegEx and takes a specified action based on
>> the result.  The action can be play a sound or send an email or flash the
>> tray icon.  Something like that might work (it would be much easier if the
>> CGOS page gave a simple list of all connected clients).
>
>
> When I get the new CGOS pages up,  I will provide a list of clients and
> their status.  A bot can be connected but busy playing a game,  waiting for
> a game,  or in limbo - where it has not agreed to play the next game yet.
> It can also be non-responsive.
>
> I noticed that there are still cases where there server THINKS a bot is
> connected but it isn't - so I need to solve that problem before bringing the
> server up - although it's currently functional.I am hoping that tomorrow
> we can bring it up although most of the web stuff won't be working yet.
>
> I've considered the idea of having a network of anchors - bots that are
> extremely active and who's ratings would be based solely on their
> performance rating (not incremental rating) against each other.
> Performance ratings are more accurate and stable if the entity is fixed.
> This would serve as a stable backbone for the rating system and incremental
> ratings would be more trustworthy as a result.
>
> - Don
>
>
> ___
> 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/

Re: [computer-go] Re: fuego strength

[Jason House]

Will the new server handle small description strings about the bots?  
It'd be great if we could provide/lookup basic data on bots. Example  
data would be a homepage or a 1-2 sentence summary. For example "John  
Smith's experimental Fuego 0.4 with heavy playout for reading semeai"


Sent from my iPhone

On Jun 24, 2009, at 1:12 PM, Don Dailey  wrote:




On Wed, Jun 24, 2009 at 12:52 PM, Michael Williams > wrote:
A while back, I wrote a general purpose monitor tool that checks a  
specified URL for a specified RegEx and takes a specified action  
based on the result.  The action can be play a sound or send an  
email or flash the tray icon.  Something like that might work (it  
would be much easier if the CGOS page gave a simple list of all  
connected clients).


When I get the new CGOS pages up,  I will provide a list of clients  
and their status.  A bot can be connected but busy playing a game,   
waiting for a game,  or in limbo - where it has not agreed to play  
the next game yet.   It can also be non-responsive.


I noticed that there are still cases where there server THINKS a bot  
is connected but it isn't - so I need to solve that problem before  
bringing the server up - although it's currently functional.I am  
hoping that tomorrow we can bring it up although most of the web  
stuff won't be working yet.


I've considered the idea of having a network of anchors - bots that  
are extremely active and who's ratings would be based solely on  
their performance rating (not incremental rating) against each  
other.   Performance ratings are more accurate and stable if the  
entity is fixed.   This would serve as a stable backbone for the  
rating system and incremental ratings would be more trustworthy as a  
result.


- Don
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Re: fuego strength

[Michael Williams]

Yeah, it's a little roundabout, but like I said, I already have the tool.  Plus, it can (and should) be run from a different machine.  If you put something in 
the client and the client is in your closet and loses power, it cannot phone home.  Heartbeats solve that, but then you need something to monitor the heartbeats 
(unless you want to receive an "all's well" email every 6 hours (would you even notice when the email stops coming?)).




Christian Nentwich wrote:
Don has already indicated he would do something around listing clients 
that are online.


However, monitoring the server to see if your client is online seems 
very roundabout. I've been wanting to put e-mail notification in the 
client anyway. This can either take the form of sending mails when the 
server or engine is down, or heartbeats mails every six/twelve or 24 hours.


If people are interested in that sort of feature, I'll put it in.

p.s. server crashes and disconnects are already handled by the clients. 
Severe engine crashes are a different story. Some of those can't be 
handled, hence the heartbeat messages idea.



On 24/06/2009 17:52, Michael Williams wrote:
A while back, I wrote a general purpose monitor tool that checks a 
specified URL for a specified RegEx and takes a specified action based 
on the result.  The action can be play a sound or send an email or 
flash the tray icon.  Something like that might work (it would be much 
easier if the CGOS page gave a simple list of all connected clients).



Jason House wrote:
That raises an interesting point. I've also put bots up in a setup 
and forget scenario, but inevitably the bit is off of CGOS within a 
few days and I had no idea when it went down.


What's the right way to solve this issue so such altruistic bots can 
be more easilly maintained? This may also help the anchor absence 
issue too.


Sent from my iPhone

On Jun 24, 2009, at 12:14 PM, "David Fotland" 
 wrote:



I can have a reduced version of Many Faces up all the time on an old
computer, but I don't monitor it, so someone would have to email and 
remind
me when it goes down (usually because of a Microsoft automatic 
reboot :( )


David


-Original Message-
From: computer-go-boun...@computer-go.org [mailto:computer-go-
boun...@computer-go.org] On Behalf Of Magnus Persson
Sent: Wednesday, June 24, 2009 5:55 AM
To: computer-go; Don Dailey
Subject: Re: [computer-go] Re: fuego strength

On 9x9 I have been worrying of the lack of strong anchors but not
enough to complain about. What I think is more important is that
stronger programs are actually active on CGOS for longer periods of
time. I tried to contribute more by having versions of Valkyria online
with a fixed number of playouts. The nice part of that is that I can
then run other tests on the same machine that all uses fixed number of
playouts and still get proper results. If I run a full strength
version of Valkyria on CGOS I cannot have anything else running.

So, I think if more people with strong programs had reduced versions
running, we could have many middle strength programs it would also
become more meaningful to play with full strength programs.

I am looking forward to the new server because I think everyone
would/should be eager to login to it.

Magnus

Quoting Don Dailey :


2009/6/24 Christian Nentwich 


Don,

you might have your work cut out if you try to control inflation

directly,
that can turn into a black art very quickly. Multiple anchors 
would be
preferable. An offline, X * 1000 game playoff between gnugo and 
another

candidate anchor would be enough to fix their rating difference. If

their
bilateral winnings drift away during continuous play, the anchor 
rating

could be tweaked.



It's all a black art anyway.  The anchor itself absorbs (or gives 
away)
rating points into the pool.  There is not much difference if I 
just use

it
to monitor the inflation/deflation and control it directly - 
except that

I
have the ability to control the magnitude of this adjustment.   
And the
advantage is that the anchor player becomes a monitor of the 
inflation

level.

Don't worry, I don't plan to change it from what I'm doing.The

anchor
can still monitor inflation if I track what adjustment I would 
normally

make

to it if it were not an anchor.   For instance if the opponent

adjustments

tended to be more negative than positive it would indicate that the

entire
pool was overrated.   A way to help compensate is to adjust the 
initial

rating of new players.  However, the first game against a brand new

player

is not rated for the established player and the K constant is so low

(for

the new players opponents) that it hardly matters. Each player

starts
with a high K and it gradually drops to 3.   But this K is 
modified from

0%

to 100% depending on the opponents K - so the first game against a

player

a
new player is effectively not rated for 

Re: [computer-go] Re: fuego strength

[Christian Nentwich]

Don has already indicated he would do something around listing clients 
that are online.


However, monitoring the server to see if your client is online seems 
very roundabout. I've been wanting to put e-mail notification in the 
client anyway. This can either take the form of sending mails when the 
server or engine is down, or heartbeats mails every six/twelve or 24 hours.


If people are interested in that sort of feature, I'll put it in.

p.s. server crashes and disconnects are already handled by the clients. 
Severe engine crashes are a different story. Some of those can't be 
handled, hence the heartbeat messages idea.



On 24/06/2009 17:52, Michael Williams wrote:
A while back, I wrote a general purpose monitor tool that checks a 
specified URL for a specified RegEx and takes a specified action based 
on the result.  The action can be play a sound or send an email or 
flash the tray icon.  Something like that might work (it would be much 
easier if the CGOS page gave a simple list of all connected clients).



Jason House wrote:
That raises an interesting point. I've also put bots up in a setup 
and forget scenario, but inevitably the bit is off of CGOS within a 
few days and I had no idea when it went down.


What's the right way to solve this issue so such altruistic bots can 
be more easilly maintained? This may also help the anchor absence 
issue too.


Sent from my iPhone

On Jun 24, 2009, at 12:14 PM, "David Fotland" 
 wrote:



I can have a reduced version of Many Faces up all the time on an old
computer, but I don't monitor it, so someone would have to email and 
remind
me when it goes down (usually because of a Microsoft automatic 
reboot :( )


David


-Original Message-
From: computer-go-boun...@computer-go.org [mailto:computer-go-
boun...@computer-go.org] On Behalf Of Magnus Persson
Sent: Wednesday, June 24, 2009 5:55 AM
To: computer-go; Don Dailey
Subject: Re: [computer-go] Re: fuego strength

On 9x9 I have been worrying of the lack of strong anchors but not
enough to complain about. What I think is more important is that
stronger programs are actually active on CGOS for longer periods of
time. I tried to contribute more by having versions of Valkyria online
with a fixed number of playouts. The nice part of that is that I can
then run other tests on the same machine that all uses fixed number of
playouts and still get proper results. If I run a full strength
version of Valkyria on CGOS I cannot have anything else running.

So, I think if more people with strong programs had reduced versions
running, we could have many middle strength programs it would also
become more meaningful to play with full strength programs.

I am looking forward to the new server because I think everyone
would/should be eager to login to it.

Magnus

Quoting Don Dailey :


2009/6/24 Christian Nentwich 


Don,

you might have your work cut out if you try to control inflation

directly,
that can turn into a black art very quickly. Multiple anchors 
would be
preferable. An offline, X * 1000 game playoff between gnugo and 
another

candidate anchor would be enough to fix their rating difference. If

their
bilateral winnings drift away during continuous play, the anchor 
rating

could be tweaked.



It's all a black art anyway.  The anchor itself absorbs (or gives 
away)
rating points into the pool.  There is not much difference if I 
just use

it
to monitor the inflation/deflation and control it directly - 
except that

I
have the ability to control the magnitude of this adjustment.   
And the
advantage is that the anchor player becomes a monitor of the 
inflation

level.

Don't worry, I don't plan to change it from what I'm doing.The

anchor
can still monitor inflation if I track what adjustment I would 
normally

make

to it if it were not an anchor.   For instance if the opponent

adjustments

tended to be more negative than positive it would indicate that the

entire
pool was overrated.   A way to help compensate is to adjust the 
initial

rating of new players.  However, the first game against a brand new

player

is not rated for the established player and the K constant is so low

(for

the new players opponents) that it hardly matters. Each player

starts
with a high K and it gradually drops to 3.   But this K is 
modified from

0%

to 100% depending on the opponents K - so the first game against a

player

a
new player is effectively not rated for his opponent.But I 
think the
initial value does have an impact on deflation/inflation of the 
entire

pool.







I'm not sure if the worries voiced on this list about anchors are 
not

somewhat overdone.



I'm pretty sure it's overdone, but I reserve judgment.  I know the
phenomenon of self-play intransitivity exists,  but it's minor.   
This

is
something that can easily be tested privately with a 100,000 games 
or so

to

get the amount nailed down - 

Re: [computer-go] Re: fuego strength

[Michael Williams]

A while back, I wrote a general purpose monitor tool that checks a specified URL for a specified RegEx and takes a specified action based on the result.  The 
action can be play a sound or send an email or flash the tray icon.  Something like that might work (it would be much easier if the CGOS page gave a simple list 
of all connected clients).



Jason House wrote:
That raises an interesting point. I've also put bots up in a setup and 
forget scenario, but inevitably the bit is off of CGOS within a few days 
and I had no idea when it went down.


What's the right way to solve this issue so such altruistic bots can be 
more easilly maintained? This may also help the anchor absence issue too.


Sent from my iPhone

On Jun 24, 2009, at 12:14 PM, "David Fotland"  
wrote:



I can have a reduced version of Many Faces up all the time on an old
computer, but I don't monitor it, so someone would have to email and 
remind
me when it goes down (usually because of a Microsoft automatic reboot 
:( )


David


-Original Message-
From: computer-go-boun...@computer-go.org [mailto:computer-go-
boun...@computer-go.org] On Behalf Of Magnus Persson
Sent: Wednesday, June 24, 2009 5:55 AM
To: computer-go; Don Dailey
Subject: Re: [computer-go] Re: fuego strength

On 9x9 I have been worrying of the lack of strong anchors but not
enough to complain about. What I think is more important is that
stronger programs are actually active on CGOS for longer periods of
time. I tried to contribute more by having versions of Valkyria online
with a fixed number of playouts. The nice part of that is that I can
then run other tests on the same machine that all uses fixed number of
playouts and still get proper results. If I run a full strength
version of Valkyria on CGOS I cannot have anything else running.

So, I think if more people with strong programs had reduced versions
running, we could have many middle strength programs it would also
become more meaningful to play with full strength programs.

I am looking forward to the new server because I think everyone
would/should be eager to login to it.

Magnus

Quoting Don Dailey :


2009/6/24 Christian Nentwich 


Don,

you might have your work cut out if you try to control inflation

directly,

that can turn into a black art very quickly. Multiple anchors would be
preferable. An offline, X * 1000 game playoff between gnugo and 
another

candidate anchor would be enough to fix their rating difference. If

their
bilateral winnings drift away during continuous play, the anchor 
rating

could be tweaked.



It's all a black art anyway.  The anchor itself absorbs (or gives away)
rating points into the pool.  There is not much difference if I just 
use

it
to monitor the inflation/deflation and control it directly - except 
that

I

have the ability to control the magnitude of this adjustment.   And the
advantage is that the anchor player becomes a monitor of the inflation
level.

Don't worry, I don't plan to change it from what I'm doing.The

anchor

can still monitor inflation if I track what adjustment I would normally

make

to it if it were not an anchor.   For instance if the opponent

adjustments

tended to be more negative than positive it would indicate that the

entire

pool was overrated.   A way to help compensate is to adjust the initial
rating of new players.  However, the first game against a brand new

player

is not rated for the established player and the K constant is so low

(for

the new players opponents) that it hardly matters. Each player

starts
with a high K and it gradually drops to 3.   But this K is modified 
from

0%

to 100% depending on the opponents K - so the first game against a

player

a
new player is effectively not rated for his opponent.But I think 
the

initial value does have an impact on deflation/inflation of the entire

pool.







I'm not sure if the worries voiced on this list about anchors are not
somewhat overdone.



I'm pretty sure it's overdone, but I reserve judgment.  I know the
phenomenon of self-play intransitivity exists,  but it's minor.   This

is
something that can easily be tested privately with a 100,000 games 
or so

to

get the amount nailed down - at least for specific trio's of players.

I

think I may try gnugo vs fuego at 2 different levels.

I think that MCTS are all similar and that this is the bigger issue.

And

as you say,  gnugo introduces bias too, it's unavoidable.



Other bots, with improvements, may do just as well against an old

version

of Fuego as the full Fuego does, we don't know. Maybe they would do

better
than new versions of Fuego. All this reliance on gnugo introduces 
bias,

too,

and after all the anchor player is not a single control variable that
determines the destiny of the server. Players will still play many

different

opponents. If Fuego keeps beating the anchor player but losing to

everybody

e

Re: [computer-go] Re: fuego strength

[Jason House]

That raises an interesting point. I've also put bots up in a setup and  
forget scenario, but inevitably the bit is off of CGOS within a few  
days and I had no idea when it went down.


What's the right way to solve this issue so such altruistic bots can  
be more easilly maintained? This may also help the anchor absence  
issue too.


Sent from my iPhone

On Jun 24, 2009, at 12:14 PM, "David Fotland" games.com> wrote:



I can have a reduced version of Many Faces up all the time on an old
computer, but I don't monitor it, so someone would have to email and  
remind
me when it goes down (usually because of a Microsoft automatic  
reboot :( )


David


-Original Message-
From: computer-go-boun...@computer-go.org [mailto:computer-go-
boun...@computer-go.org] On Behalf Of Magnus Persson
Sent: Wednesday, June 24, 2009 5:55 AM
To: computer-go; Don Dailey
Subject: Re: [computer-go] Re: fuego strength

On 9x9 I have been worrying of the lack of strong anchors but not
enough to complain about. What I think is more important is that
stronger programs are actually active on CGOS for longer periods of
time. I tried to contribute more by having versions of Valkyria  
online

with a fixed number of playouts. The nice part of that is that I can
then run other tests on the same machine that all uses fixed number  
of

playouts and still get proper results. If I run a full strength
version of Valkyria on CGOS I cannot have anything else running.

So, I think if more people with strong programs had reduced versions
running, we could have many middle strength programs it would also
become more meaningful to play with full strength programs.

I am looking forward to the new server because I think everyone
would/should be eager to login to it.

Magnus

Quoting Don Dailey :


2009/6/24 Christian Nentwich 


Don,

you might have your work cut out if you try to control inflation

directly,
that can turn into a black art very quickly. Multiple anchors  
would be
preferable. An offline, X * 1000 game playoff between gnugo and  
another

candidate anchor would be enough to fix their rating difference. If

their
bilateral winnings drift away during continuous play, the anchor  
rating

could be tweaked.



It's all a black art anyway.  The anchor itself absorbs (or gives  
away)
rating points into the pool.  There is not much difference if I  
just use

it
to monitor the inflation/deflation and control it directly -  
except that

I
have the ability to control the magnitude of this adjustment.
And the
advantage is that the anchor player becomes a monitor of the  
inflation

level.

Don't worry, I don't plan to change it from what I'm doing.The

anchor
can still monitor inflation if I track what adjustment I would  
normally

make

to it if it were not an anchor.   For instance if the opponent

adjustments

tended to be more negative than positive it would indicate that the

entire
pool was overrated.   A way to help compensate is to adjust the  
initial

rating of new players.  However, the first game against a brand new

player

is not rated for the established player and the K constant is so low

(for

the new players opponents) that it hardly matters. Each player

starts
with a high K and it gradually drops to 3.   But this K is  
modified from

0%

to 100% depending on the opponents K - so the first game against a

player

a
new player is effectively not rated for his opponent.But I  
think the
initial value does have an impact on deflation/inflation of the  
entire

pool.







I'm not sure if the worries voiced on this list about anchors are  
not

somewhat overdone.



I'm pretty sure it's overdone, but I reserve judgment.  I know the
phenomenon of self-play intransitivity exists,  but it's minor.
This

is
something that can easily be tested privately with a 100,000 games  
or so

to
get the amount nailed down - at least for specific trio's of  
players.

I

think I may try gnugo vs fuego at 2 different levels.

I think that MCTS are all similar and that this is the bigger issue.

And

as you say,  gnugo introduces bias too, it's unavoidable.



Other bots, with improvements, may do just as well against an old

version

of Fuego as the full Fuego does, we don't know. Maybe they would do

better
than new versions of Fuego. All this reliance on gnugo introduces  
bias,

too,
and after all the anchor player is not a single control variable  
that

determines the destiny of the server. Players will still play many

different

opponents. If Fuego keeps beating the anchor player but losing to

everybody

else, it still won't get a higher rank.

For me, gnugo as an anchor is fine, as I am still experimenting  
around

a

low ELO level. For authors of strong programs: I am quite surprised

that

you
are not insisting on a much more highly rated anchor. I remember  
when

KGS
was anchored in the kyu ranks, many 

Re: [computer-go] Re: fuego strength

[Michael Williams]

Turn off Windows update or put the CGOS connect script in the startup folder 
and set an automatic login.


David Fotland wrote:

I can have a reduced version of Many Faces up all the time on an old
computer, but I don't monitor it, so someone would have to email and remind
me when it goes down (usually because of a Microsoft automatic reboot :( )

David


-Original Message-
From: computer-go-boun...@computer-go.org [mailto:computer-go-
boun...@computer-go.org] On Behalf Of Magnus Persson
Sent: Wednesday, June 24, 2009 5:55 AM
To: computer-go; Don Dailey
Subject: Re: [computer-go] Re: fuego strength

On 9x9 I have been worrying of the lack of strong anchors but not
enough to complain about. What I think is more important is that
stronger programs are actually active on CGOS for longer periods of
time. I tried to contribute more by having versions of Valkyria online
with a fixed number of playouts. The nice part of that is that I can
then run other tests on the same machine that all uses fixed number of
playouts and still get proper results. If I run a full strength
version of Valkyria on CGOS I cannot have anything else running.

So, I think if more people with strong programs had reduced versions
running, we could have many middle strength programs it would also
become more meaningful to play with full strength programs.

I am looking forward to the new server because I think everyone
would/should be eager to login to it.

Magnus

Quoting Don Dailey :


2009/6/24 Christian Nentwich 


 Don,

you might have your work cut out if you try to control inflation

directly,

that can turn into a black art very quickly. Multiple anchors would be
preferable. An offline, X * 1000 game playoff between gnugo and another
candidate anchor would be enough to fix their rating difference. If

their

bilateral winnings drift away during continuous play, the anchor rating
could be tweaked.


It's all a black art anyway.  The anchor itself absorbs (or gives away)
rating points into the pool.  There is not much difference if I just use

it

to monitor the inflation/deflation and control it directly - except that

I

have the ability to control the magnitude of this adjustment.   And the
advantage is that the anchor player becomes a monitor of the inflation
level.

Don't worry, I don't plan to change it from what I'm doing.The

anchor

can still monitor inflation if I track what adjustment I would normally

make

to it if it were not an anchor.   For instance if the opponent

adjustments

tended to be more negative than positive it would indicate that the

entire

pool was overrated.   A way to help compensate is to adjust the initial
rating of new players.  However, the first game against a brand new

player

is not rated for the established player and the K constant is so low

(for

the new players opponents) that it hardly matters. Each player

starts

with a high K and it gradually drops to 3.   But this K is modified from

0%

to 100% depending on the opponents K - so the first game against a

player

a

new player is effectively not rated for his opponent.But I think the
initial value does have an impact on deflation/inflation of the entire

pool.





I'm not sure if the worries voiced on this list about anchors are not
somewhat overdone.


I'm pretty sure it's overdone, but I reserve judgment.  I know the
phenomenon of self-play intransitivity exists,  but it's minor.   This

is

something that can easily be tested privately with a 100,000 games or so

to

get the amount nailed down - at least for specific trio's of players.

I

think I may try gnugo vs fuego at 2 different levels.

I think that MCTS are all similar and that this is the bigger issue.

And

as you say,  gnugo introduces bias too, it's unavoidable.



Other bots, with improvements, may do just as well against an old

version

of Fuego as the full Fuego does, we don't know. Maybe they would do

better

than new versions of Fuego. All this reliance on gnugo introduces bias,

too,

and after all the anchor player is not a single control variable that
determines the destiny of the server. Players will still play many

different

opponents. If Fuego keeps beating the anchor player but losing to

everybody

else, it still won't get a higher rank.

For me, gnugo as an anchor is fine, as I am still experimenting around

a

low ELO level. For authors of strong programs: I am quite surprised

that

you

are not insisting on a much more highly rated anchor. I remember when

KGS

was anchored in the kyu ranks, many years ago. I found myself 7 dan one

day,

until somebody intervened and reanchored the server. The territory far

above

a single anchor player is unsafe.


The thought has occured to me that I should not worry about low resource
anchors and that I should simply bite the bullet and insist, as you say,

on

much stronger anchor players. But the tone of these discuss

RE: [computer-go] Re: fuego strength

[David Fotland]

I can have a reduced version of Many Faces up all the time on an old
computer, but I don't monitor it, so someone would have to email and remind
me when it goes down (usually because of a Microsoft automatic reboot :( )

David

> -Original Message-
> From: computer-go-boun...@computer-go.org [mailto:computer-go-
> boun...@computer-go.org] On Behalf Of Magnus Persson
> Sent: Wednesday, June 24, 2009 5:55 AM
> To: computer-go; Don Dailey
> Subject: Re: [computer-go] Re: fuego strength
> 
> On 9x9 I have been worrying of the lack of strong anchors but not
> enough to complain about. What I think is more important is that
> stronger programs are actually active on CGOS for longer periods of
> time. I tried to contribute more by having versions of Valkyria online
> with a fixed number of playouts. The nice part of that is that I can
> then run other tests on the same machine that all uses fixed number of
> playouts and still get proper results. If I run a full strength
> version of Valkyria on CGOS I cannot have anything else running.
> 
> So, I think if more people with strong programs had reduced versions
> running, we could have many middle strength programs it would also
> become more meaningful to play with full strength programs.
> 
> I am looking forward to the new server because I think everyone
> would/should be eager to login to it.
> 
> Magnus
> 
> Quoting Don Dailey :
> 
> > 2009/6/24 Christian Nentwich 
> >
> >>  Don,
> >>
> >> you might have your work cut out if you try to control inflation
> directly,
> >> that can turn into a black art very quickly. Multiple anchors would be
> >> preferable. An offline, X * 1000 game playoff between gnugo and another
> >> candidate anchor would be enough to fix their rating difference. If
> their
> >> bilateral winnings drift away during continuous play, the anchor rating
> >> could be tweaked.
> >>
> >
> > It's all a black art anyway.  The anchor itself absorbs (or gives away)
> > rating points into the pool.  There is not much difference if I just use
> it
> > to monitor the inflation/deflation and control it directly - except that
> I
> > have the ability to control the magnitude of this adjustment.   And the
> > advantage is that the anchor player becomes a monitor of the inflation
> > level.
> >
> > Don't worry, I don't plan to change it from what I'm doing.The
anchor
> > can still monitor inflation if I track what adjustment I would normally
> make
> > to it if it were not an anchor.   For instance if the opponent
> adjustments
> > tended to be more negative than positive it would indicate that the
> entire
> > pool was overrated.   A way to help compensate is to adjust the initial
> > rating of new players.  However, the first game against a brand new
> player
> > is not rated for the established player and the K constant is so low
(for
> > the new players opponents) that it hardly matters. Each player
starts
> > with a high K and it gradually drops to 3.   But this K is modified from
> 0%
> > to 100% depending on the opponents K - so the first game against a
player
> a
> > new player is effectively not rated for his opponent.But I think the
> > initial value does have an impact on deflation/inflation of the entire
> pool.
> >
> >
> >
> >>
> >>
> >> I'm not sure if the worries voiced on this list about anchors are not
> >> somewhat overdone.
> >>
> >
> > I'm pretty sure it's overdone, but I reserve judgment.  I know the
> > phenomenon of self-play intransitivity exists,  but it's minor.   This
is
> > something that can easily be tested privately with a 100,000 games or so
> to
> > get the amount nailed down - at least for specific trio's of players.
> I
> > think I may try gnugo vs fuego at 2 different levels.
> >
> > I think that MCTS are all similar and that this is the bigger issue.
> And
> > as you say,  gnugo introduces bias too, it's unavoidable.
> >
> >
> >> Other bots, with improvements, may do just as well against an old
> version
> >> of Fuego as the full Fuego does, we don't know. Maybe they would do
> better
> >> than new versions of Fuego. All this reliance on gnugo introduces bias,
> too,
> >> and after all the anchor player is not a single control variable that
> >> determines the destiny of the server. Players will still play many
> different
> >> opponents. If Fuego keeps beating the anchor player but losing to
> everybody
> >>

Re: [computer-go] Re: fuego strength

[Magnus Persson]

On 9x9 I have been worrying of the lack of strong anchors but not  
enough to complain about. What I think is more important is that  
stronger programs are actually active on CGOS for longer periods of  
time. I tried to contribute more by having versions of Valkyria online  
with a fixed number of playouts. The nice part of that is that I can  
then run other tests on the same machine that all uses fixed number of  
playouts and still get proper results. If I run a full strength  
version of Valkyria on CGOS I cannot have anything else running.


So, I think if more people with strong programs had reduced versions  
running, we could have many middle strength programs it would also  
become more meaningful to play with full strength programs.


I am looking forward to the new server because I think everyone  
would/should be eager to login to it.


Magnus

Quoting Don Dailey :


2009/6/24 Christian Nentwich 


 Don,

you might have your work cut out if you try to control inflation directly,
that can turn into a black art very quickly. Multiple anchors would be
preferable. An offline, X * 1000 game playoff between gnugo and another
candidate anchor would be enough to fix their rating difference. If their
bilateral winnings drift away during continuous play, the anchor rating
could be tweaked.



It's all a black art anyway.  The anchor itself absorbs (or gives away)
rating points into the pool.  There is not much difference if I just use it
to monitor the inflation/deflation and control it directly - except that I
have the ability to control the magnitude of this adjustment.   And the
advantage is that the anchor player becomes a monitor of the inflation
level.

Don't worry, I don't plan to change it from what I'm doing.The anchor
can still monitor inflation if I track what adjustment I would normally make
to it if it were not an anchor.   For instance if the opponent adjustments
tended to be more negative than positive it would indicate that the entire
pool was overrated.   A way to help compensate is to adjust the initial
rating of new players.  However, the first game against a brand new player
is not rated for the established player and the K constant is so low (for
the new players opponents) that it hardly matters. Each player starts
with a high K and it gradually drops to 3.   But this K is modified from 0%
to 100% depending on the opponents K - so the first game against a player a
new player is effectively not rated for his opponent.But I think the
initial value does have an impact on deflation/inflation of the entire pool.






I'm not sure if the worries voiced on this list about anchors are not
somewhat overdone.



I'm pretty sure it's overdone, but I reserve judgment.  I know the
phenomenon of self-play intransitivity exists,  but it's minor.   This is
something that can easily be tested privately with a 100,000 games or so to
get the amount nailed down - at least for specific trio's of players.I
think I may try gnugo vs fuego at 2 different levels.

I think that MCTS are all similar and that this is the bigger issue.And
as you say,  gnugo introduces bias too, it's unavoidable.



Other bots, with improvements, may do just as well against an old version
of Fuego as the full Fuego does, we don't know. Maybe they would do better
than new versions of Fuego. All this reliance on gnugo introduces bias, too,
and after all the anchor player is not a single control variable that
determines the destiny of the server. Players will still play many different
opponents. If Fuego keeps beating the anchor player but losing to everybody
else, it still won't get a higher rank.

For me, gnugo as an anchor is fine, as I am still experimenting around a
low ELO level. For authors of strong programs: I am quite surprised that you
are not insisting on a much more highly rated anchor. I remember when KGS
was anchored in the kyu ranks, many years ago. I found myself 7 dan one day,
until somebody intervened and reanchored the server. The territory far above
a single anchor player is unsafe.



The thought has occured to me that I should not worry about low resource
anchors and that I should simply bite the bullet and insist, as you say, on
much stronger anchor players. But the tone of these discussions indicate
that few consider that very important.   I'm glad to hear that I am not the
only one. If I did do this it would not need to disrupt the pool - I would
still run the standard gnugo player that I currently use as an anchor and
use it as a way to monitor the "new" anchor - at least for the first 100,000
games of the new anchor.

I have no problem using programs under heavy development either.   What
people are missing is that I don't use the latest version,  I simply pick a
good version and stick with that.   For instance I do not upgrade gnugo - I
continue to use the same version I started with. So the anchor is not
continuously improving - it is a constant.

- Don







Christian

Re: [computer-go] Re: fuego strength

[Don Dailey]

2009/6/24 Christian Nentwich 

>  Don,
>
> you might have your work cut out if you try to control inflation directly,
> that can turn into a black art very quickly. Multiple anchors would be
> preferable. An offline, X * 1000 game playoff between gnugo and another
> candidate anchor would be enough to fix their rating difference. If their
> bilateral winnings drift away during continuous play, the anchor rating
> could be tweaked.
>

It's all a black art anyway.  The anchor itself absorbs (or gives away)
rating points into the pool.  There is not much difference if I just use it
to monitor the inflation/deflation and control it directly - except that I
have the ability to control the magnitude of this adjustment.   And the
advantage is that the anchor player becomes a monitor of the inflation
level.

Don't worry, I don't plan to change it from what I'm doing.The anchor
can still monitor inflation if I track what adjustment I would normally make
to it if it were not an anchor.   For instance if the opponent adjustments
tended to be more negative than positive it would indicate that the entire
pool was overrated.   A way to help compensate is to adjust the initial
rating of new players.  However, the first game against a brand new player
is not rated for the established player and the K constant is so low (for
the new players opponents) that it hardly matters. Each player starts
with a high K and it gradually drops to 3.   But this K is modified from 0%
to 100% depending on the opponents K - so the first game against a player a
new player is effectively not rated for his opponent.But I think the
initial value does have an impact on deflation/inflation of the entire pool.



>
>
> I'm not sure if the worries voiced on this list about anchors are not
> somewhat overdone.
>

I'm pretty sure it's overdone, but I reserve judgment.  I know the
phenomenon of self-play intransitivity exists,  but it's minor.   This is
something that can easily be tested privately with a 100,000 games or so to
get the amount nailed down - at least for specific trio's of players.I
think I may try gnugo vs fuego at 2 different levels.

I think that MCTS are all similar and that this is the bigger issue.And
as you say,  gnugo introduces bias too, it's unavoidable.


> Other bots, with improvements, may do just as well against an old version
> of Fuego as the full Fuego does, we don't know. Maybe they would do better
> than new versions of Fuego. All this reliance on gnugo introduces bias, too,
> and after all the anchor player is not a single control variable that
> determines the destiny of the server. Players will still play many different
> opponents. If Fuego keeps beating the anchor player but losing to everybody
> else, it still won't get a higher rank.
>
> For me, gnugo as an anchor is fine, as I am still experimenting around a
> low ELO level. For authors of strong programs: I am quite surprised that you
> are not insisting on a much more highly rated anchor. I remember when KGS
> was anchored in the kyu ranks, many years ago. I found myself 7 dan one day,
> until somebody intervened and reanchored the server. The territory far above
> a single anchor player is unsafe.
>

The thought has occured to me that I should not worry about low resource
anchors and that I should simply bite the bullet and insist, as you say, on
much stronger anchor players. But the tone of these discussions indicate
that few consider that very important.   I'm glad to hear that I am not the
only one. If I did do this it would not need to disrupt the pool - I would
still run the standard gnugo player that I currently use as an anchor and
use it as a way to monitor the "new" anchor - at least for the first 100,000
games of the new anchor.

I have no problem using programs under heavy development either.   What
people are missing is that I don't use the latest version,  I simply pick a
good version and stick with that.   For instance I do not upgrade gnugo - I
continue to use the same version I started with. So the anchor is not
continuously improving - it is a constant.

- Don




>
>
> Christian
>
>
>
>
> On 24/06/2009 05:28, Don Dailey wrote:
>
> >From what I have discovered so far, there is no compelling reason to
> change anchors.   What I really was hoping we could do is UPGRADE the
> anchor, since many programs are now far stronger than 1800.
>
> Fuego is pretty strong, but not when it plays at the same CPU intensity as
> gnugo.   I went up to 5000 simulations and the match is fairly close and the
> time is about the same.Going from 3000 to 5000 was quite a remarkable
> jump in strength and no doubt we could run at 10,000 and have substantial
> superiority - but that's not really what I had in mind.
>
> So I think I agree with all the comments I have received so far - and my
> own observations and testing, there is no compelling reasons to change.
>
> Now if fuego was substantially stronger using less resources, I would

Re: [computer-go] Re: fuego strength

[Christian Nentwich]

Don,

you might have your work cut out if you try to control inflation 
directly, that can turn into a black art very quickly. Multiple anchors 
would be preferable. An offline, X * 1000 game playoff between gnugo and 
another candidate anchor would be enough to fix their rating difference. 
If their bilateral winnings drift away during continuous play, the 
anchor rating could be tweaked.


I'm not sure if the worries voiced on this list about anchors are not 
somewhat overdone. Other bots, with improvements, may do just as well 
against an old version of Fuego as the full Fuego does, we don't know. 
Maybe they would do better than new versions of Fuego. All this reliance 
on gnugo introduces bias, too, and after all the anchor player is not a 
single control variable that determines the destiny of the server. 
Players will still play many different opponents. If Fuego keeps beating 
the anchor player but losing to everybody else, it still won't get a 
higher rank.


For me, gnugo as an anchor is fine, as I am still experimenting around a 
low ELO level. For authors of strong programs: I am quite surprised that 
you are not insisting on a much more highly rated anchor. I remember 
when KGS was anchored in the kyu ranks, many years ago. I found myself 7 
dan one day, until somebody intervened and reanchored the server. The 
territory far above a single anchor player is unsafe.


Christian



On 24/06/2009 05:28, Don Dailey wrote:
>From what I have discovered so far, there is no compelling reason to 
change anchors.   What I really was hoping we could do is UPGRADE the 
anchor, since many programs are now far stronger than 1800.


Fuego is pretty strong, but not when it plays at the same CPU 
intensity as gnugo.   I went up to 5000 simulations and the match is 
fairly close and the time is about the same.Going from 3000 to 
5000 was quite a remarkable jump in strength and no doubt we could run 
at 10,000 and have substantial superiority - but that's not really 
what I had in mind.


So I think I agree with all the comments I have received so far - and 
my own observations and testing, there is no compelling reasons to 
change.


Now if fuego was substantially stronger using less resources, I would 
be more eager to change after carefully calibrating the difference,  
but that is not the case, at least not at 19x19.


There is another way to keep ratings stable and that is to monitor key 
players over time and build a deflation/inflation mechanism into the 
server to keep it in tune.For instance if there were no anchors,   
the server could monitor gnugo and if it were to gradually drop in 
rating, I could make minor adjustments to the ratings of winners and 
losers to compensate gradually over time.  For example the winner 
could get 1% more ELO and the loser could lose 1% less ELO when in 
inflation mode and just the opposite when in deflation mode.   In this 
way I could feed points into the rating pool, or gradually extract 
them as needed.   I don't plan to do this, but there is more than one 
way to skin a cat.


If we use more than one player as anchors,  I would still pick one 
player as the standard, and periodically adjust the "other" anchors 
based on their global perormance rating - since they will all tend to 
drift around relative to each other and I would not want to make any 
assumptions about what the other anchors should be. We cannot just 
say gnugo is 1800, fuego is 2000, etc because we don't really know the 
exact difference between the 2.   But we could refine this over time.


- Don





On Tue, Jun 23, 2009 at 11:34 PM, David Fotland 
mailto:fotl...@smart-games.com>> wrote:


I'd also prefer to use gnugo as an anchor.  Since fuego is under
development, new versions will be playing with an odler version of
itself.
Fuego will win more often against its old version.  I don't care
about it
distorting Fuego's rating, but it will distort the rating system.
 If new
fuego is on with few other programs it will gain rating points,
then when
other programs come new fuego will give them the other program as
its rating
drops.  The effect will be to make the rating system less stable,
so it's
hard to use cgos to evaluate new versions of programs to see if
they are
stronger.

I think it's best to use an anchor that's not under active
development.  I
like gnugo since there is lots of published results against it,
and it is
not changing rapidly.  Also it has a different style than the
monte carlo
programs, so it's more likely to expose bugs in the monte carlo
programs.

David

> -Original Message-
> From: computer-go-boun...@computer-go.org
 [mailto:computer-go-

> boun...@computer-go.org ] On
Behalf Of Hideki Kato
> Sent: Tuesday, June 23, 2009 5:15 PM
> 

Re: [computer-go] Re: fuego strength

[Don Dailey]

>From what I have discovered so far, there is no compelling reason to change
anchors.   What I really was hoping we could do is UPGRADE the anchor, since
many programs are now far stronger than 1800.

Fuego is pretty strong, but not when it plays at the same CPU intensity as
gnugo.   I went up to 5000 simulations and the match is fairly close and the
time is about the same.Going from 3000 to 5000 was quite a remarkable
jump in strength and no doubt we could run at 10,000 and have substantial
superiority - but that's not really what I had in mind.

So I think I agree with all the comments I have received so far - and my own
observations and testing, there is no compelling reasons to change.

Now if fuego was substantially stronger using less resources, I would be
more eager to change after carefully calibrating the difference,  but that
is not the case, at least not at 19x19.

There is another way to keep ratings stable and that is to monitor key
players over time and build a deflation/inflation mechanism into the server
to keep it in tune.For instance if there were no anchors,   the server
could monitor gnugo and if it were to gradually drop in rating, I could make
minor adjustments to the ratings of winners and losers to compensate
gradually over time.  For example the winner could get 1% more ELO and the
loser could lose 1% less ELO when in inflation mode and just the opposite
when in deflation mode.   In this way I could feed points into the rating
pool, or gradually extract them as needed.   I don't plan to do this, but
there is more than one way to skin a cat.

If we use more than one player as anchors,  I would still pick one player as
the standard, and periodically adjust the "other" anchors based on their
global perormance rating - since they will all tend to drift around relative
to each other and I would not want to make any assumptions about what the
other anchors should be. We cannot just say gnugo is 1800, fuego is
2000, etc because we don't really know the exact difference between the 2.
But we could refine this over time.

- Don





On Tue, Jun 23, 2009 at 11:34 PM, David Fotland wrote:

> I'd also prefer to use gnugo as an anchor.  Since fuego is under
> development, new versions will be playing with an odler version of itself.
> Fuego will win more often against its old version.  I don't care about it
> distorting Fuego's rating, but it will distort the rating system.  If new
> fuego is on with few other programs it will gain rating points, then when
> other programs come new fuego will give them the other program as its
> rating
> drops.  The effect will be to make the rating system less stable, so it's
> hard to use cgos to evaluate new versions of programs to see if they are
> stronger.
>
> I think it's best to use an anchor that's not under active development.  I
> like gnugo since there is lots of published results against it, and it is
> not changing rapidly.  Also it has a different style than the monte carlo
> programs, so it's more likely to expose bugs in the monte carlo programs.
>
> David
>
> > -Original Message-
> > From: computer-go-boun...@computer-go.org [mailto:computer-go-
> > boun...@computer-go.org] On Behalf Of Hideki Kato
> > Sent: Tuesday, June 23, 2009 5:15 PM
> > To: computer-go
> > Subject: [computer-go] Re: fuego strength
> >
> > I'm running Fatman1, GNU Go and GNU Go MC version for 9x9 and two
> > instances of GNU Go for 13x13, five programs in total, on a dual-core
> > Athlon at home.
> >
> > I strongly believe current anchors are resource friendly enough for
> > older pentium 3, 4 or even Celeron processors and not necessary being
> > changed.
> >
> > Changing anchors is a big problem, similar to changing the
> > International prototypes.  Also, GNU Go is used as a reference in
> > almost every computer-go research these days.
> >
> > I'm against that idea, especially for 19x19.
> >
> > Hideki
> >
> > Don Dailey: <5212e61a0906231524k4f068be1q50a2f2806b678...@mail.gmail.com
> >:
> > >I'm trying now to get a rough idea about the strength of fuego and it's
> > >suitablity as the anchor player.
> > >
> > >Right now the numbers are very rough as I need more samples.   I'm
> > currently
> > >looking at:
> > >
> > >  1.  9x9 fuego at 1000 simulations
> > >
> > >  2. 19x19 fuego at 3000 simulations.
> > >
> > >
> > >I'm testing against the current CGOS anchors,  so FatMan vs fuego at 9x9
> > and
> > >gnugo-3.7.10 at 19x19.
> > >
> > >
> > >At 9x9 fuego appears to be substantially stronger than FatMan, perhaps
> > >100-200 ELO.   It also is far faster at 1000 simulation than fatman
> which
> > >requires many more simulations to reach anchor strength.   So there is
> no
> > >questions about fuego being a capable anchor for small boards.  At this
> > >level on 9x9 FatMan is also stronger than gnugo, so fuego is far
> stronger
> > >than gnugo on 9x9 and is very resource friendly too.
> > >
> > >At 19x19 the story is a bit different.  gnugo appears to 

Re: [computer-go] Re: fuego strength

[Don Dailey]

If I were to change anchors I would of course carefully calibrate them.
But I don't see that fuego is stronger than Gnugo at the low CPU levels I
was hoping to run at.   So there is no compelling reason right now to change
anchors.

- Don


On Tue, Jun 23, 2009 at 8:18 PM, Michael Williams <
michaelwilliam...@gmail.com> wrote:

> If it were me, I'd run all anchor candidates against the current CGOS to
> determine the anchor value to use for that anchor candidate.
>
>
>
> Hideki Kato wrote:
>
>> I'm running Fatman1, GNU Go and GNU Go MC version for 9x9 and two
>> instances of GNU Go for 13x13, five programs in total, on a dual-core Athlon
>> at home.
>>
>> I strongly believe current anchors are resource friendly enough for older
>> pentium 3, 4 or even Celeron processors and not necessary being changed.
>>
>> Changing anchors is a big problem, similar to changing the International
>> prototypes.  Also, GNU Go is used as a reference in almost every computer-go
>> research these days.
>>
>> I'm against that idea, especially for 19x19.
>>
>> Hideki
>>
>> Don Dailey: <5212e61a0906231524k4f068be1q50a2f2806b678...@mail.gmail.com
>> >:
>>
>>> I'm trying now to get a rough idea about the strength of fuego and it's
>>> suitablity as the anchor player.
>>>
>>> Right now the numbers are very rough as I need more samples.   I'm
>>> currently
>>> looking at:
>>>
>>>  1.  9x9 fuego at 1000 simulations
>>>
>>>  2. 19x19 fuego at 3000 simulations.
>>>
>>>
>>> I'm testing against the current CGOS anchors,  so FatMan vs fuego at 9x9
>>> and
>>> gnugo-3.7.10 at 19x19.
>>>
>>>
>>> At 9x9 fuego appears to be substantially stronger than FatMan, perhaps
>>> 100-200 ELO.   It also is far faster at 1000 simulation than fatman which
>>> requires many more simulations to reach anchor strength.   So there is no
>>> questions about fuego being a capable anchor for small boards.  At this
>>> level on 9x9 FatMan is also stronger than gnugo, so fuego is far stronger
>>> than gnugo on 9x9 and is very resource friendly too.
>>>
>>> At 19x19 the story is a bit different.  gnugo appears to be significantly
>>> stronger, but about twice as slow.   There is not enough data to narrow
>>> this
>>> down much, but it appears to be over 200 ELO weaker at this level.
>>>
>>> Since fuego is using only about half the CPU resources of gnugo,  I can
>>> increase the level.I've only played 30 games at 19x19, so this
>>> conclusion is subject to signficant error, but it's enough to conclude
>>> that
>>> it's almost certainly weaker at this level but perhaps not when run at
>>> the
>>> same CPU intensity as gnugo.
>>>
>>> Of course at higher levels yet, fuego would be far stronger than
>>> gnugo-3.7.10 as seen in the 19x19 cgos tables.   But I'm hoping not to
>>> push
>>> the anchors too hard - hopefully they can be run on someones older spare
>>> computer or set unobtrusively in the background on someones desktop
>>> machine.
>>>
>>>
>>> - Don
>>>  inline file
>>> ___
>>> computer-go mailing list
>>> computer-go@computer-go.org
>>> http://www.computer-go.org/mailman/listinfo/computer-go/
>>>
>> --
>> g...@nue.ci.i.u-tokyo.ac.jp (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/
>
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

RE: [computer-go] Re: fuego strength

[David Fotland]

I'd also prefer to use gnugo as an anchor.  Since fuego is under
development, new versions will be playing with an odler version of itself.
Fuego will win more often against its old version.  I don't care about it
distorting Fuego's rating, but it will distort the rating system.  If new
fuego is on with few other programs it will gain rating points, then when
other programs come new fuego will give them the other program as its rating
drops.  The effect will be to make the rating system less stable, so it's
hard to use cgos to evaluate new versions of programs to see if they are
stronger.

I think it's best to use an anchor that's not under active development.  I
like gnugo since there is lots of published results against it, and it is
not changing rapidly.  Also it has a different style than the monte carlo
programs, so it's more likely to expose bugs in the monte carlo programs.

David

> -Original Message-
> From: computer-go-boun...@computer-go.org [mailto:computer-go-
> boun...@computer-go.org] On Behalf Of Hideki Kato
> Sent: Tuesday, June 23, 2009 5:15 PM
> To: computer-go
> Subject: [computer-go] Re: fuego strength
> 
> I'm running Fatman1, GNU Go and GNU Go MC version for 9x9 and two
> instances of GNU Go for 13x13, five programs in total, on a dual-core
> Athlon at home.
> 
> I strongly believe current anchors are resource friendly enough for
> older pentium 3, 4 or even Celeron processors and not necessary being
> changed.
> 
> Changing anchors is a big problem, similar to changing the
> International prototypes.  Also, GNU Go is used as a reference in
> almost every computer-go research these days.
> 
> I'm against that idea, especially for 19x19.
> 
> Hideki
> 
> Don Dailey: <5212e61a0906231524k4f068be1q50a2f2806b678...@mail.gmail.com>:
> >I'm trying now to get a rough idea about the strength of fuego and it's
> >suitablity as the anchor player.
> >
> >Right now the numbers are very rough as I need more samples.   I'm
> currently
> >looking at:
> >
> >  1.  9x9 fuego at 1000 simulations
> >
> >  2. 19x19 fuego at 3000 simulations.
> >
> >
> >I'm testing against the current CGOS anchors,  so FatMan vs fuego at 9x9
> and
> >gnugo-3.7.10 at 19x19.
> >
> >
> >At 9x9 fuego appears to be substantially stronger than FatMan, perhaps
> >100-200 ELO.   It also is far faster at 1000 simulation than fatman which
> >requires many more simulations to reach anchor strength.   So there is no
> >questions about fuego being a capable anchor for small boards.  At this
> >level on 9x9 FatMan is also stronger than gnugo, so fuego is far stronger
> >than gnugo on 9x9 and is very resource friendly too.
> >
> >At 19x19 the story is a bit different.  gnugo appears to be significantly
> >stronger, but about twice as slow.   There is not enough data to narrow
> this
> >down much, but it appears to be over 200 ELO weaker at this level.
> >
> >Since fuego is using only about half the CPU resources of gnugo,  I can
> >increase the level.I've only played 30 games at 19x19, so this
> >conclusion is subject to signficant error, but it's enough to conclude
> that
> >it's almost certainly weaker at this level but perhaps not when run at
the
> >same CPU intensity as gnugo.
> >
> >Of course at higher levels yet, fuego would be far stronger than
> >gnugo-3.7.10 as seen in the 19x19 cgos tables.   But I'm hoping not to
> push
> >the anchors too hard - hopefully they can be run on someones older spare
> >computer or set unobtrusively in the background on someones desktop
> >machine.
> >
> >
> >- Don
> > inline file
> >___
> >computer-go mailing list
> >computer-go@computer-go.org
> >http://www.computer-go.org/mailman/listinfo/computer-go/
> --
> g...@nue.ci.i.u-tokyo.ac.jp (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/

Re: [computer-go] Re: fuego strength

[Michael Williams]

If it were me, I'd run all anchor candidates against the current CGOS to 
determine the anchor value to use for that anchor candidate.


Hideki Kato wrote:
I'm running Fatman1, GNU Go and GNU Go MC version for 9x9 and two 
instances of GNU Go for 13x13, five programs in total, on a dual-core 
Athlon at home.


I strongly believe current anchors are resource friendly enough for 
older pentium 3, 4 or even Celeron processors and not necessary being 
changed.


Changing anchors is a big problem, similar to changing the 
International prototypes.  Also, GNU Go is used as a reference in 
almost every computer-go research these days.


I'm against that idea, especially for 19x19.

Hideki

Don Dailey: <5212e61a0906231524k4f068be1q50a2f2806b678...@mail.gmail.com>:

I'm trying now to get a rough idea about the strength of fuego and it's
suitablity as the anchor player.

Right now the numbers are very rough as I need more samples.   I'm currently
looking at:

 1.  9x9 fuego at 1000 simulations

 2. 19x19 fuego at 3000 simulations.


I'm testing against the current CGOS anchors,  so FatMan vs fuego at 9x9 and
gnugo-3.7.10 at 19x19.


At 9x9 fuego appears to be substantially stronger than FatMan, perhaps
100-200 ELO.   It also is far faster at 1000 simulation than fatman which
requires many more simulations to reach anchor strength.   So there is no
questions about fuego being a capable anchor for small boards.  At this
level on 9x9 FatMan is also stronger than gnugo, so fuego is far stronger
than gnugo on 9x9 and is very resource friendly too.

At 19x19 the story is a bit different.  gnugo appears to be significantly
stronger, but about twice as slow.   There is not enough data to narrow this
down much, but it appears to be over 200 ELO weaker at this level.

Since fuego is using only about half the CPU resources of gnugo,  I can
increase the level.I've only played 30 games at 19x19, so this
conclusion is subject to signficant error, but it's enough to conclude that
it's almost certainly weaker at this level but perhaps not when run at the
same CPU intensity as gnugo.

Of course at higher levels yet, fuego would be far stronger than
gnugo-3.7.10 as seen in the 19x19 cgos tables.   But I'm hoping not to push
the anchors too hard - hopefully they can be run on someones older spare
computer or set unobtrusively in the background on someones desktop
machine.


- Don
 inline file
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

--
g...@nue.ci.i.u-tokyo.ac.jp (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/