Author: Bob Durrett
Date: 05:42:14 11/17/02
Go up one level in this thread
On November 17, 2002 at 05:07:01, Ricardo Gibert wrote: >On November 17, 2002 at 03:15:15, Frank Schneider wrote: > >>On November 16, 2002 at 22:08:55, Christophe Theron wrote: >> >>>On November 16, 2002 at 22:00:27, Bob Durrett wrote: >>> >>>> >>>>I was thinking it might be *fun* to create a machine which does nothing more >>>>than create legal move sequences from some preset legal chess position. These >>>>sequences might be dumped into a large part of RAM for later copy to a hard disk >>>>or printout. >>>> >>>>The key idea I'm toying with is to represent a chess position by a listing of >>>>legal moves. Whenever a new move is made [by the person (or thing) playing >>>>against the machine, or by the machine if it's playing against itself,] then the >>>>machine would do nothing more than modify that listing (plus copy the move >>>>representation to a temporary storage place in RAM). The new listing of legal >>>>moves would then represent the new position. The key idea is to represent a >>>>position by a listing of legal moves. When a move is made, there is a "from" >>>>square and a "to" square. Only consequences of changes made on these two >>>>squares would have to be considered to modify the legal move list. >>>> >>>>Then, to make it more interesting, a really fast random number generator would >>>>be used to select one of the resulting legal moves. If the machine were playing >>>>against itself, the sequences of moves should be generated very quickly. How >>>>quickly? >>>> >>>>In the beginning, I am only interested in the time it would take to modify that >>>>listing. The machine could play both sides, removing the need for >>>>time-consuming input/output. After generating a legal move sequence ending in >>>>mate, it would then start working on the next legal move sequence. After a >>>>million or so moves were made, then the time required could be divided by the >>>>number of moves. That resulting time per move that I'm asking about. Rather >>>>than worry about the fact that some computers are faster than others, maybe the >>>>best bet would be to express it as number of clock cycles per move. A modern >>>>high-end processor should be assumed. >>>> >>>>Each sequence would be what two "really dumb" chessplayers would produce if they >>>>knew how to produce legal moves but knew NOTHING at all else about chess. >>>> >>>>P.S. Is there a better way? >>>> >>>>Bob D. >>> >>> >>> >>>Don't you need to prove first that two different chess positions will always >>>have a different legal moves list? >> >>Hi Bob, >> >>there are many different positions with the same move list, e.g. >>all stalemate-positions, all positions where e.g. Ke1xqf2 is the >>only legal move, ... >> >>Frank > > >He knows that. He wasn't asking the question for his own benefit. Christophe, you read me wrong. I really WAS asking the question for my own benefit. I wanted to understand something. At the time I wrote that, I didn't realize that the same legal move list could have multiple positions. However, that doesn't matter (!!) in the application I was asking about. What I was trying to do was to produce a machine which would generate sequences of legal moves. A move generator, if you wish. I wanted to know whether or not the method I was thinking about would be efficient. I would like to know how much time [expressed as processor clock cycles] a legal move generator ought to take, on average, to produce one legal move, i.e. if it were efficient. With that information, I could compare my method to determine it's efficiency. Sometimes I don't communicate very well. I apologize for that. : ) Bob D. > > >> >>> And that there exist no move list that could >>>be associated with two different chess positions? >>> >>> >>> >>> Christophe
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.