Re: [computer-go] ego110_allfirst on CGOS

2007-09-29 Thread steve uurtamo
I'm glad that you found it.  seems like winRate
would end up as 0 most of the time and thus
you'd make nearly random moves?

s.




  

Shape Yahoo! in your own image.  Join our Network Research Panel today!   
http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 


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


Re: [computer-go] ego110_allfirst on CGOS

2007-09-29 Thread Don Dailey
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Excellent,  I am glad you found the issue.   I had a strong sense it
would be something like this.

This is a fairly common type of bug in software and is why I suggested
it,  however I think it's the first time I've ever directed someone to
the specific line of code without having ever seen the code!   (Of
course it was a wild stab in the dark.)

- - Don


Jason House wrote:
 On Fri, 2007-09-28 at 18:43 -0400, Don Dailey wrote:
 Somewhere in your program I am sure there is a head-slapping error you
 will find and when you do you will scream out loud!   Don't give up.
 
 Yup...  A nice little omission of casting.
 
 int nwins, nsims;
 ...
 double winRate = nwins/nsims;
 ...
 write(Picking move {} with win rate of, move, nwins*1.0/nsims);
 
 
 What kept me from seeing this immediately (AKA bot plays
 A1,A2,A3...A9,B1,B2...B9,C1...C9,...) is that there's logic that looks
 at two moves with the same winning rate and picks the one with the
 higher number of simulations.  That can really help in non-AMAF
 implementations where the number of sims are low.  
 
 It turns out that the code that I copied/pasted to make a quick AMAF bot
 used floating point numbers for nwins and nsims...  My so-called monte
 carlo transposition reuse (MCTR) where they have to be floating point
 values.
 
 I kicked off hb-amaf-1k-v2.  While it lost its first game online, it's
 play was WAY better than it has been.  It's rating will certainly settle
 much higher.
 
 I hope that was the issue and there are no more biggies like that!  This
 discussion was very helpful for me to dig up all kinds of small bugs in
 other parts of my code.  Once I confirm this is the big bug, I'll try
 variants with the different handling to see how that affects the rating
 (I'd call all past tests of variations worthless given the nature of
 this bug)
 
 While this may give an 800 ELO boost to the AMAF bot, I'm disappointed
 that it won't help my other versions like that.  The other changes dug
 up in this long discussion will likely give them some boost though.
 
 ___
 computer-go mailing list
 computer-go@computer-go.org
 http://www.computer-go.org/mailman/listinfo/computer-go/
 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG/kqFDsOllbwnSikRAlNYAJ9R4yriIDN8UleHjlK/Ex7SqsjQVgCfaeL2
8MHiz56EXGa5GLZ4hDt/QFo=
=1nFu
-END PGP SIGNATURE-
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/


Re: [computer-go] ego110_allfirst on CGOS

2007-09-29 Thread Jason House
On Sat, 2007-09-29 at 03:45 -0700, steve uurtamo wrote:
 I'm glad that you found it.  seems like winRate
 would end up as 0 most of the time and thus
 you'd make nearly random moves?

Yes, winRate would be 0.0 (unless every random simulation with that
point was a victory such as in late endgame).  The net effect is that it
was playing the move with the most simulations, which is random.

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


Re: [computer-go] ego110_allfirst on CGOS

2007-09-29 Thread Jason House
Strangely enough, it now appears that hb-amaf-1k-v2 is significantly
stronger than genAnchor-1k, defeating it 9 out of 9 times.  I still have
to wonder what the cause of the strength difference is.


On Sat, 2007-09-29 at 08:52 -0400, Don Dailey wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Excellent,  I am glad you found the issue.   I had a strong sense it
 would be something like this.
 
 This is a fairly common type of bug in software and is why I suggested
 it,  however I think it's the first time I've ever directed someone to
 the specific line of code without having ever seen the code!   (Of
 course it was a wild stab in the dark.)
 
 - - Don
 
 
 Jason House wrote:
  On Fri, 2007-09-28 at 18:43 -0400, Don Dailey wrote:
  Somewhere in your program I am sure there is a head-slapping error you
  will find and when you do you will scream out loud!   Don't give up.
  
  Yup...  A nice little omission of casting.
  
  int nwins, nsims;
  ...
  double winRate = nwins/nsims;
  ...
  write(Picking move {} with win rate of, move, nwins*1.0/nsims);
  
  
  What kept me from seeing this immediately (AKA bot plays
  A1,A2,A3...A9,B1,B2...B9,C1...C9,...) is that there's logic that looks
  at two moves with the same winning rate and picks the one with the
  higher number of simulations.  That can really help in non-AMAF
  implementations where the number of sims are low.  
  
  It turns out that the code that I copied/pasted to make a quick AMAF bot
  used floating point numbers for nwins and nsims...  My so-called monte
  carlo transposition reuse (MCTR) where they have to be floating point
  values.
  
  I kicked off hb-amaf-1k-v2.  While it lost its first game online, it's
  play was WAY better than it has been.  It's rating will certainly settle
  much higher.
  
  I hope that was the issue and there are no more biggies like that!  This
  discussion was very helpful for me to dig up all kinds of small bugs in
  other parts of my code.  Once I confirm this is the big bug, I'll try
  variants with the different handling to see how that affects the rating
  (I'd call all past tests of variations worthless given the nature of
  this bug)
  
  While this may give an 800 ELO boost to the AMAF bot, I'm disappointed
  that it won't help my other versions like that.  The other changes dug
  up in this long discussion will likely give them some boost though.
  
  ___
  computer-go mailing list
  computer-go@computer-go.org
  http://www.computer-go.org/mailman/listinfo/computer-go/
  
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.6 (GNU/Linux)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
 
 iD8DBQFG/kqFDsOllbwnSikRAlNYAJ9R4yriIDN8UleHjlK/Ex7SqsjQVgCfaeL2
 8MHiz56EXGa5GLZ4hDt/QFo=
 =1nFu
 -END PGP SIGNATURE-
 ___
 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] ego110_allfirst on CGOS

2007-09-29 Thread steve uurtamo
i don't mean necessarily that it isn't stronger, just that
now is the time to not worry so much about things.

if anything, try to make it even stronger!

you've got another 1200 ELO to go, after all.

s.

- Original Message 
From: Jason House [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Saturday, September 29, 2007 10:44:55 AM
Subject: Re: [computer-go] ego110_allfirst on CGOS

Statistically speaking, I can say with 99.9% confidence that
hb-amaf-1k-v2 is stronger than genAnchor-1k.  No need to wait any longer
to conclude that :)  The math to compute the one-tailed p-value for
rejecting the null hypothesis that the bots are the same strength is
left as an exercise for the reader ;)

On Sat, 2007-09-29 at 07:20 -0700, steve uurtamo wrote:
  Strangely enough, it now appears that hb-amaf-1k-v2 is significantly
  stronger than genAnchor-1k, defeating it 9 out of 9 times.  I still have
  to wonder what the cause of the strength difference is.
 
 now is the time to just let it run for a few weeks and check on the
 stats later.
 
 s.
 
 
 
 
 
   
 
 Tonight's top picks. What will you watch tonight? Preview the hottest shows 
 on Yahoo! TV.
 http://tv.yahoo.com/ 
 
 ___
 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/





  

Catch up on fall's hot new shows on Yahoo! TV. Watch previews, get listings, 
and more!
http://tv.yahoo.com/collections/3658
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/


[computer-go] Games Database

2007-09-29 Thread Joshua Shriver
Good Evening,

Sorry, I think this may have been asked but can't find it
anywhere in the list archives. Anyone know of a good place to get a
large sgf game database?

Preferably master games or at least 1dan level or higher?

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


Re: [computer-go] ego110_allfirst on CGOS

2007-09-29 Thread Don Dailey
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I'm starting to get curious.  What are you doing that is causing it to
win 11 out of 11 against genAnchor_1k and yet it's only 113 ELO
stronger?And it's supposedly an identical program?I don't think
it's actually identical and I don't trust that you did everything the
same.   Of course I could have a bug too,  but it doesn't explain why
your program is much weaker than the results against genAnchor would
indicate.

How many all-as-first moves are you considering?   What are the possible
differences?

  1. eye rule
  2. number of all-as-first moves  (7/8 for me + 1)
  3. quality of RNG
  4. correctness of random move selection strategy.
  5. depth at which you stop a game.  (about 1000 moves for me.)
  6. stopping rule.  (both program have no non-eye filling moves.)

I just thought of something.   I think I initialize the statistics array
with 1 draw per move as a cheesy way to avoid divide by zero error.
Could this be affecting the performance?   Perhaps at low levels like
this it has a noticeable effect?Would it make the program especially
vulnerable to an identical program that doesn't do this?


- - Don






Jason House wrote:
 Statistically speaking, I can say with 99.9% confidence that
 hb-amaf-1k-v2 is stronger than genAnchor-1k.  No need to wait any longer
 to conclude that :)  The math to compute the one-tailed p-value for
 rejecting the null hypothesis that the bots are the same strength is
 left as an exercise for the reader ;)
 
 On Sat, 2007-09-29 at 07:20 -0700, steve uurtamo wrote:
 Strangely enough, it now appears that hb-amaf-1k-v2 is significantly
 stronger than genAnchor-1k, defeating it 9 out of 9 times.  I still have
 to wonder what the cause of the strength difference is.
 now is the time to just let it run for a few weeks and check on the
 stats later.

 s.





   
 
 Tonight's top picks. What will you watch tonight? Preview the hottest shows 
 on Yahoo! TV.
 http://tv.yahoo.com/ 

 ___
 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/
 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG/wSKDsOllbwnSikRAm+EAJ4+PrLMO7Uyf3ejn61nzZcwOgyvnACeL0tD
acGx8Fhu1Co5fk8OMvDFuhE=
=fFvv
-END PGP SIGNATURE-
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/