Maximum possible mobility

Discussion of chess software programming and technical issues.

Moderator: Ras

bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: Maximum possible mobility

Post by bob »

pete205 wrote:Thanks to everyone for your help. Looks like 256 then -- although I might go with 192 as the max size since from Jan's data it looks as though the only way to top that is to get 9 queens(!). If my engine is cocky enough to waste time getting 9 queens it should rightly be punished by breaking. Of course, if the opponent gets 9 queens then it doesn't matter if it breaks, it has already lost.
Don't make the classic mistake "nobody ever does that..." A full width search does _everything_.,.. And if you generate more moves than your list will hold, most likely you are getting ready to crash. probably during an important game in an important tournament. :)
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: Maximum possible mobility

Post by bob »

Bill Rogers wrote:Peter
I think that somehow we got away from your original question. I once put a subroutine in one of my development chess programs to keep count of the greatest possible moves it made during a game. I actually tried this using several different openings and was supprised to see that at one point or another during the game it calculated 55 possible moves for one side. If you found 65 then I would go with that number.
The rest of the answers seem be the number of moves in a complete chess game.
Bill
No. There has been a position posted that had 219 legal moves for the side on move. Nobody has posted one with more, but that does not mean that one does not exist... 65 will cause you to overflow an array badly. A position with three queens will blow that up instantly, and 3 queens happens plenty of times in a deep endgame search.
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: Maximum possible mobility

Post by bob »

Onno Garms wrote:Some time ago I noted the following maximum numbers for real games: 71 in a serious game in an international turnament, 62 between strong GMs (Karpov vs. Kasparow). In spite of some research I was unable to find the link again.

I also found a position with 225 moves on the internet, see
http://groups.google.de/group/rec.puzzl ... febb104b36
but clearly the counting is not correct there (queen on rank 2 counted twice).

Using the fact that the maximum of the moves of all pieces is less or equal the sum of the maxima for all pieces, we get an upper bound of 321. Using the fact that bishops and queens lose 2 squares when not placed on one of the four center squares, we get 307. It's easy to reduce that a bit further.

AFAIK it is unknown is the real maximum is less then 256, but many chess programs rely on that assumption.
Using those numbers will get you into lots of trouble. The number of moves in positions reached in actual GM games is a _far_ different animal from the number of possible moves in positions reached in a deep full-width search. Rather than counting moves at each real position in a game, just instrument a real chess engine and count the number of moves generated and remember the max... You will be amazed.
User avatar
Onno Garms
Posts: 224
Joined: Mon Mar 12, 2007 7:31 pm
Location: Bonn, Germany

Re: Maximum possible mobility

Post by Onno Garms »

bob wrote:
Onno Garms wrote:Some time ago I noted the following maximum numbers for real games: 71 in a serious game in an international turnament, 62 between strong GMs (Karpov vs. Kasparow). In spite of some research I was unable to find the link again.
Using those numbers will get you into lots of trouble. The number of moves in positions reached in actual GM games is a _far_ different animal from the number of possible moves in positions reached in a deep full-width search.
I don't use these numbers of course. Just answered a question similar to the original author's request for the maximum number of queens on the board in a real game.

Btw. the latter is certainly at least 5 (GM vs. FM) and might be 6 or 7 (stange-looking "games"). See
http://www.herderschach.de/Training/Onl ... 10.html#a2
(follow the links in the section "Polygamie auf dem Schachbrett")
My personal maximum is 4.
Harald
Posts: 318
Joined: Thu Mar 09, 2006 1:07 am

Re: Maximum possible mobility

Post by Harald »

pete205 wrote:Thanks to everyone for your help. Looks like 256 then -- although I might go with 192 as the max size since from Jan's data it looks as though the only way to top that is to get 9 queens(!). If my engine is cocky enough to waste time getting 9 queens it should rightly be punished by breaking. Of course, if the opponent gets 9 queens then it doesn't matter if it breaks, it has already lost.
It is not important what your engine will do or another engine.
With a movelist array smaller than 218 moves your engine will crash
as soon as a user sets up the board with this FEN position:
3Q4/1Q4Q1/4Q3/2Q4R/Q4Q2/3Q4/1Q4Rp/1K1BBNNk w - - 0 1
Use a data structure robust enough to handle that case.

Harald
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: Maximum possible mobility

Post by bob »

Onno Garms wrote:
bob wrote:
Onno Garms wrote:Some time ago I noted the following maximum numbers for real games: 71 in a serious game in an international turnament, 62 between strong GMs (Karpov vs. Kasparow). In spite of some research I was unable to find the link again.
Using those numbers will get you into lots of trouble. The number of moves in positions reached in actual GM games is a _far_ different animal from the number of possible moves in positions reached in a deep full-width search.
I don't use these numbers of course. Just answered a question similar to the original author's request for the maximum number of queens on the board in a real game.

Btw. the latter is certainly at least 5 (GM vs. FM) and might be 6 or 7 (stange-looking "games"). See
http://www.herderschach.de/Training/Onl ... 10.html#a2
(follow the links in the section "Polygamie auf dem Schachbrett")
My personal maximum is 4.
The problem is that the number of queens (or anything) else that could/did happen in a GM game is a wildly different number than what could/will happen in a full-width brute-force search in a computer endgame...
Sven
Posts: 4052
Joined: Thu May 15, 2008 9:57 pm
Location: Berlin, Germany
Full name: Sven Schüle

Re: Maximum possible mobility

Post by Sven »

I also use "nearly" unlimited move lists since I push all generated moves on top of a move stack. Each move list has its own segment of the move stack and stores a pointer to the beginning of that segment and one to the stack top. The move list itself is part of a "position" data structure for which there is a separate stack with one entry per ply of the whole game, including the search. When making a move, the move list of the newly reached position gets initialized by setting both "beginning" and "top" pointers to the "top" of the previous position's move list (thereby having an empty list initially). When unmaking, the previous move list is available immediately since the old "top" had been stored.

Overflow of the move stack could be checked easily but with the chosen limit of the move stack an overflow should never happen in practice. An important detail here is that the position stack contains all positions from the beginning of the game but the move stack only contains moves belonging to move lists from the root of the search. This is because the root move list can always be reproduced very quickly when needed. Otherwise the size limit of the move stack would somehow also depend on the maximum possible length of the game. Access to move list contents of previous moves is never required for me, so I accept to have "invalid" move lists for all positions above the current search root.

Doing it this way uses less memory than maintaining for instance an array of 256 moves for each level of search, either on the stack of the recursive search function or in some data structure. This in turn allows to avoid having a fixed maximum search depth which can never be exceeded by a program due to its internal data structure limits. Given my flexible approach, only the move stack overflow and the maximum number of total moves in a game must be observed.

I think this is mostly well-known and nothing very special or tricky. Nevertheless, for those interested I can post a part of my data structures here, reduced to relevant stuff only:

Code: Select all

class MoveList
{
    // ...
    Move *      m_first;     // the beginning of this move list's stack segment
    Move *      m_top;       // the entry where the next generated move would be written to, like in:
                             // *m_top++ = some_move;
};

class Position
{
    // ...
    MoveList    m_moveList;
    Move        m_move;      // the move that was made on the board from here
    // ... and some more status info like hash key, ep target, castling rights, fifty, ...
};

class Game
{
    // ...
    Move        m_moveStack     [5000];
    Position    m_positionStack [1000];
};
Sven
Sven
Posts: 4052
Joined: Thu May 15, 2008 9:57 pm
Location: Berlin, Germany
Full name: Sven Schüle

Re: Maximum possible mobility

Post by Sven »

Sven Schüle wrote:Access to move list contents of previous moves is never required for me,
should be "of previous positions" of course (could not edit the post anymore).
Sven
mathmoi
Posts: 290
Joined: Mon Mar 13, 2006 5:23 pm
Location: Québec
Full name: Mathieu Pagé

Re: Maximum possible mobility

Post by mathmoi »

[d]3Q4/1Q4Q1/4Q3/2Q4R/Q4Q2/3Q4/1Q4Rp/1K1BBNNk w - - 0 1
Steelman

Re: Maximum possible mobility

Post by Steelman »

Interesting the max number of moves is so high? I did not look at the positions but they must be fantasy positions to have that many possible moves.

However the data structure my engine uses for move storage is a single linked list. Even if there are 500 possible moves for the side the moves would be stored sequentially in the structure. I have pointers for the move parent, the move child, and the move sibling. I need however to also remember the next available open link pointer.
When the my engine is ready to generate the reply moves for the first move in the list (next ply) they get stored starting at that "next available link pointer".
That means I do not have a "MAX_NUMBER_MOVES" definition anywhere in program but I do have MAX_MOVE_STORAGE. The max number of moves that can be stored in the move structure list.

So my question is:
What should MAX_MOVE_STORAGE be set at?

Number of max plies your engine is set at * (max number of moves at each ply)?

I am not even going there!
I have seen my engine go about 22 ply deep. I estimated about 50 moves each ply max. Thats a little over a thousand. No problem. Then I added a big safety factor. Now since I have no idea what the real answer is i have MAX_MOVE_STORAGE set to 5000.

Problem solved!?