home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / gnu / chess / 504 < prev    next >
Encoding:
Internet Message Format  |  1992-12-29  |  2.6 KB
  1. Xref: sparky gnu.chess:504 rec.games.chess:12114
  2. Newsgroups: gnu.chess,rec.games.chess
  3. Path: sparky!uunet!stanford.edu!nntp.Stanford.EDU!928s4
  4. From: 928s4@leland.Stanford.EDU (Benjamin Sloss)
  5. Subject: Re: GNU Chess ratings estimates...
  6. Message-ID: <1992Dec29.170710.9011@leland.Stanford.EDU>
  7. Summary: depends on the hardware
  8. Sender: ?@leland.Stanford.EDU
  9. Organization: DSG, Stanford University, CA 94305, USA
  10. Date: Tue, 29 Dec 92 17:07:10 GMT
  11. Lines: 38
  12.  
  13. Tony-Preston@cup.portal.com (ANTHONY FRANCIS PRESTON) writes:
  14. >I have the Amiga version of the GNU chess program and think it is pretty
  15. >good.  My questions are 1) what are the estimates for rating strength(USCF?)
  16. >versus the various time controls?  2) how deep will the search for moves
  17. >go versus the time controls.  I am only looking for intellegent estimates!
  18.  
  19.   To estimate the strength of the program, it is necessary to know how fast
  20. the program runs on your hardware.  Perform the following test:
  21. * With the book turned off, set the time controls to some long interval
  22. (say move/10 min) and set the search depth to 6 ('depth' <cr> '6' <cr>)
  23. Turn on 'post' and then type 'go'.  Record the time it takes your machine
  24. to calculate the 6-ply search for White's first move (it should get Nf3).
  25.  
  26.   Now, we need to make two assumptions.  The first is fairly well established:
  27. every doubling of processor speed improves the program's play by roughly 75
  28. points.  The second is a baseline rating for GNUChess, which I will 
  29. estimate as 2300 on an RS/6000.  
  30.  
  31.   The RS calculates the search in 27 sec.  Thus, you can estimate the rating
  32. of GNUChess on your Amiga by the formula 2300 - 75 * (log2(t) - log2(27))
  33. where t is the number of seconds it took your machine to calculate the
  34. search.
  35.  
  36.   In answer to your second question (depth of search vs time), the answer
  37. depends greatly on the type of position being searched.  Endgames, with their
  38. reduced piece count (and thus reduced movelist) are searched much deeper than
  39. complicated middlegames, in a given amount of time.  Perhaps a more useful 
  40. question is "my program searched n ply in time t; how long will it take
  41. to search n+1 ply?".  The answer here is about 6t for middlegames, and
  42. perhaps 3t for endgames.  This is again due to the differences in movelist
  43. size (which averages 40 in the middlegame, much less in the endgame) and
  44. the effeciency of the alpha-beta pruning algorithm.
  45.  
  46. -- 
  47. Ben Sloss        Email: ben@osc.versant.com   Work: (415) 329-7500 x172
  48. Quote:          "It's all fun and games until someone gets paid."
  49. Transportation: '83 CB650SC (straight roads) '93 CBR 900RR   (twisty roads)
  50.         '91 XR 250L (dirty    roads) '87 Mustang 5.0 (wet    roads)
  51.