1

Chess engines often use Zobrist hashing for quick lookups. An ideal of Zobrist hashing (as with hashing in general) is that the generated keys be as dissimilar as possible for similar positions.

The problem then, is this - how can one map similar positions to similar keys? In short, what I would like is a quick and dirty way of classifying chess positions (through the hash function alone). Has anyone any interesting ideas?

The definition of a chess position here is not merely the board position, but also the current state of the game (whether castling or making an en passant capture possible etc.)

Ideally positional concepts from chess should be incorporated into the hash function. Perhaps there should be two hash tables, one for Black to move, and one for White to move, since these positions could well be very different in nature. I have found a couple of similar questions, e.g. efficient storage of a chess position on stackoverflow and elsewhere, but very few answers.

This question is probably chess-oriented for stackoverflow, but it is also too programming-oriented for https://chess.stackexchange.com/

Edit: Apologies if this came across as if I am expecting a complete solution without having done any work myself, but I was simply hoping for some discussion or interesting ideas, having very relatively little knowledge of topic myself. Everything that I have found so far aims to separate the keys as far apart as possible rather than purposely grouping them together, such as http://chessprogramming.wikispaces.com/Zobrist+Hashing

Edit: A related question (and another way to go about solving the underlying problem) is the devising of some similarity measure between two chess positions. Has anyone any ideas regarding this approach?

Community
  • 1
  • 1
UserUnspecified
  • 101
  • 6
  • 2
    Whoa there! While that certainly is an interesting topic, the way the question is worded (especially the part about _bonus points_) makes it sound like you're expecting to receive a complete solution to a problem which you have not tried to solve. We're here to help you solve your problem, not to write solutions for you for free. Refer to the [FAQ](http://meta.stackexchange.com/questions/156810/stack-overflow-question-checklist). Please consider rewording your question so that it doesn't appear to be expectant of a full solution, or post the current efforts you've taken to solve this yourself. – Christian May 13 '14 at 08:24
  • 1
    In general, hash-locality is not possible. For endgame-databases something you intend is possible, but an endgame database is probably represented as a DAG, indexed by material balance plus some material hints. For intersting ideas about Zobrist hashing, see http://osdir.com/ml/games.devel.go/2002-09/msg00011.html – joop May 13 '14 at 08:49
  • Define "similar positions" - would the same position but with the colors reversed be considered "similar?" If you tell us what the actual problem is you're trying to solve with this, there is probably a better solution. – BlueRaja - Danny Pflughoeft May 13 '14 at 13:43
  • @ BlueRaja - Danny Pflughoeft: No, they probably shouldn't be considered similar, which is why I suggested having two hash tables, one for black to move, and one for white to move. – UserUnspecified May 14 '14 at 04:46
  • Making the difference between black/white to move requires just one extra bit of information. Assign a zobrist hashvalue for "black to move" and xor that to the whole-board-hash on every move, just like you do with the castling state or the EP state. Or use the movenumber%2. – wildplasser May 14 '14 at 10:06

1 Answers1

0

Finding good similarity measures for chess positions is a quite hard problem. I suggest to split up the positions into different positional elements, which are generally important in chess: e.g.

  1. material
  2. pawn structure
  3. king position
  4. position of heavy pieces
  5. position of light pieces ...

Generate hash values for each element (hash1...hashn).

The similarity of two positions can be expressed by the equality of corresponding hash values.

rka
  • 11
  • 2