Author: Robert Hyatt
Date: 11:32:24 06/04/98
Go up one level in this thread
On June 04, 1998 at 12:13:25, Guido Schimmels wrote:
>
>On June 04, 1998 at 10:29:52, Robert Hyatt wrote:
>
>>On June 04, 1998 at 07:05:03, Guido Schimmels wrote:
>>
>
>>>
>>>move:
>>>While storing moves as indexes allows the highest possible compression
>>>I can think of, it has two big disadvantages:
>>> 1. terribly slow
>>> 2. other representations help to detect collisions by failed
>>> move validations, equivalent to a few bits of hash signature (how
>>>many ?),
>>> an index provides zero information about the position,
>>> making the compression worthless
>>>
>>>...but there is an easy way to store moves as 9 bits, which is what I'm
>>>doing:
>>>sliding pieces: to-square (6bits) | direction (3bits)
>>>king, pawns, knights: from-square | direction
>>>extraction+validation: switch(PieceOnSquare(square)) {...}
>>>
>>
>>while that will work, the "index" approach and your approach will miss
>>many errors. IE for sliding pieces, "to" is not nearly enough to really
>>validate the move. And if you do as I do, and make the hash move before
>>*any* move generation is done, you invite trouble by making illegal
>>moves
>>that will corrupt the board and the search itself... All of the above
>>will fail as often as they work. Even omitting the actual piece being
>>moved causes many errors,
>
>I don't see any problems here. I always do a complete validation of
>hashtable moves before I use them, including pins... to make sure
>not to make illegal moves and to detect some collisions. A move
>that may corrupt data structures will _always_ be detected.
>Maybe I give you some more code how it works for me:
>
If I interpret your prior post correctly, you have a problem. Because
in your hash table you don't store the piece that is moving. Which
means you could have a queen on e4 in the original position, and a
bishop
on e4 now, and you assume that the same diagonal-move is legal. And
that
is wrong... it would be legal... but it would be the wrong move in the
wrong position... that's why I store the full 21-bit move format in my
hash entries, 6bit from, 6bit to, 3bit moving piece, 3bit captured piece
and 3bit promote-to piece.
>ValidateWhiteMove()
>(
> to = from = square;
>switch(PieceOnSquare(square)) {
there is the problem I see... you are using the piece on the real board,
which might not be the piece on the board in the hashed position. So
while you won't look at illegal moves, you might not be looking at the
right move, and using this to "validate" the hashing can overlook
collisions..
>
> /* sliding pieces */
> case EMPTY:
> case b_pawn:
> case b knight:
> case b_bishop:
> case b_rook:
> case b_Queen:
> dir = SlideDirection [direction];
> while(Board[from += dir] == 0);
> if(Board[from] == w_queen) {
> ...
> }
> else if(direction <= 3) {
> if(Board[from] != w_bishop) goto badmove;
> ...
> }
> else {
> if (Board[from] != w_rook) goto badmove;
> ...
> }
> break;
> case w_pawn:
> ...
> break;
> case w_knight:
> ...
> break;
> case w_king:
> ...
> break;
> case w_bishop:
> case w_rook;
> case w_queen:
> case b_king:
> goto badmove;
>}
>
> if(Pinned(from,to)) goto badmove;
>
>}
>
>Of course more bits for the move will let you detect some more
>collisions, but you can't have the cake and eat it.
>
>
>>>draft: (I always call it this way, cause "depth" is a tounge twister for
>>>me as a German :-) )
>>>6 bits should be sufficient, even if you use fractional plies.
>>>You can have a resolution of 1/4 ply for iterations up to 15,
>>>then you reduce the resolution to 1/2 ply and "shift through the table"
>>>in order to adapt the entries. For iterations above 31 you finally
>>>reduce
>>>the resolution to a full ply.
>>
>>
>
>
>
>>how would you *know* which resolution you stored? That is problem
>>number
>
>Yes, that causes some complications, but it still works. If previous
>resolution was 1/2 then I'll simply start with that resolution next
>time.
>
>>one since I carry hash entries not only across iterations but across
>>full
>>searches as well. And when you start quantizing things, you can
>>adversely
>>affect hash matches. IE I'm currently searching to 20.5, but the hash
>>table has a draft of 20. No use. A draft of 21. may be useful, may be
>>quantized to a wrong value.
>>
>>I think this adds too many opportunities for error to make it
>>worthwhile,
>>as the hash tables already are a major source of errors as programs are
>>developed, and missing matches or getting false matches would only make
>>it
>>worse..
>>
>>
>>
>>>So for the most time (except endings) you have a resolution of 1/4 ply,
>>>which is enough to decide wether you may cut or not. I think you
>>>don't need the full resolution here. Higher resolutions are needed only
>>>to allow small increments to add up during long lines.
>>
>>yes, but there *is* a difference between a 15.5 ply search below this
>>node and a 15.75 ply search below this node.. otherwise that .25
>>increment
>>ought not be in there at all.
>>
>>
>>>
>>>So I have 17 bits left for score and flags - enough for me...
>>>
>>>I have no information how Frans does this, but you see 64-bit entries
>>>are easily possible...
>>>
>>>- Guido
>>
>>if you are willing to accept more possible errors and less exact
>>results,
>>yes... although I don't know that he even does fractional ply
>>extensions.
>
>OK, it is a compromise I admit, maybe I'll use 8bits for draft if I'm
>forced to by testing results later, but 12bits is really not necessary
>I'm sure.
>To make that clear there are two ways to handle it:
>1. prune when you should not prune in some rare cases, undermining
> your search extensions
>2. don't prune when you could prune in some rare cases, making your
> graph (it's not a tree, damned !) slightly bigger
>
>I subscribe to 2. And if table gets overloaded the graph will be smaller
>with the same amount of memory available, because I can store more
>positions !
>
>- Guido
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.