Author: Gordon Rattray
Date: 11:14:56 08/01/01
Go up one level in this thread
On August 01, 2001 at 14:05:18, Uri Blass wrote: >On August 01, 2001 at 11:53:55, José de Jesús García Ruvalcaba wrote: > >>On August 01, 2001 at 09:08:08, Gordon Rattray wrote: >> >>>On July 31, 2001 at 22:35:26, Christophe Theron wrote: >>> >>>>On July 31, 2001 at 19:18:36, Roy Eassa wrote: >>>> >>>>>On July 31, 2001 at 15:26:08, Ed Panek wrote: >>>>> >>>>>>On July 31, 2001 at 15:24:48, Roy Eassa wrote: >>>>>> >>>>>>>On July 31, 2001 at 15:21:17, Ed Panek wrote: >>>>>>> >>>>>>>>Lets say I have a move generator that selects a random move every time it is its >>>>>>>>turn. What are the odds against it drawing/winning a game? Is it less likely >>>>>>>>than winning a game of Keno with all the correct numbers picked? >>>>>>>> >>>>>>> >>>>>>>Is the opponent Kramnik or Deeper Blue? Or a human rated 400? Or another such >>>>>>>"random" program? I think this matters. >>>>>> >>>>>>Lets try a random opponent first...and then Kramnik >>>>>> >>>>>>Ed >>>>> >>>>> >>>>>Obviously, the chance of beating another random-playing program is 50% (not >>>>>counting draws). >>>> >>>> >>>>It depends how is programmed the random opponent. >>>> >>>>If the opponent just picks a move at random, odds are 50%. >>>> >>>>If the opponent is a program that does some sort of of alpha beta on a tree >>>>where the leaves receive random numbers, this opponent will win very often. >>>> >>>>That means: a random evaluation function is much stronger than a program >>>>choosing a move at random. >>> >>>Do you assume that a move leading immediately to checkmate, stalemate, etc. >>>returns a meaningful (non-random) value? If not, I don't understand why your >>>claim holds true? I assume a "random evaluation function" to be random for >>>*all* positions. >>> >>>Gordon >>> >> >>Even with a pure random non-constant evaluation, deeper search helps (but I >>would assume that checkmates and other ways to end the game are recognised and >>properly evaluated). The reason is that even a random evaluation will favour >>moves which increase the own mobility (as long as the search depth is bigger >>than two) > >Why? >If the evaluation is a random number I see no reason for prefering moves that >increase the mobility. If you consider the basic mini-max algorithm, then for the side trying to maximise the value, this will be easier if more random values are available (better chance of a high value). Likewise, we'd want to restrict the choices available to the minimising side. Hence, the number of moves available (mobility) does have an affect. I failed to consider this initially. Gordon > >If you assume that the program evaluates checkmates correctly then it s clear >that it plays better than rabdom moves because it is going to never miss a >simple forced mate so you do not need to use mobility. > >Uri
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.