Transposition tables and move evaluation, questions/advice

[Greg Strong]

Many engines only set the en-passant square if it is actually threatened by an opponent pawn. In this case it very often contributes to the value of a position.

Ah that makes a lot more sense -- that addresses the problem I was having with having to store 'useless' en-passants that were blocking access to TT entries.

The first thing that occurs to me is that the act of deciding whether or not a square is attacked by a neigboring pawn is more work than just setting an ep flag when a pawn moves two squares and be done with it. Given that I don't really know what's going on here, I probably have missed the point of this exchange.

p.s my knowledge of "proper" chess algorithms is limited.

I think you must check whether or not a square is attacked by a neighboring pawn and set the ep flag, regardless of the amount of work and whether or not it seems justified. Remember that that information becomes part of the position hash which is used for detecting repetitions. If you don't check it, you could see a position reoccur where at one time there is a possible en-passant capture and at another time there isn't and incorrectly determine that its a repetition draw when really it isn't.

[Teemu Pudas]

If you don't check it, you could see a position reoccur where at one time there is a possible en-passant capture and at another time there isn't and incorrectly determine that its a repetition draw when really it isn't.

Note if the position with the en-passant possibility is in the tree, you definitely _want_ to consider it a rep-draw.

Similarly, if the current position repeats an earlier tree position except for your own castling rights, you can prune it if alpha >= 0.

[mcostalba]

Normally it is the history table that takes in account this.

Ah ok, just googled it, it seems to make sense -- is it effective though?

The system I proposed is slightly different since I'm only considering piece-type and to-square rather than the to-square and from-square that the history table considers -- although it might make no difference.

Indeed it makes difference: to-square only is better

See Glaurung / Stockfish sources for an example of an implementation.....



P.S.: I have found http://chessprogramming.wikispaces.com/ an useful site to have an idea of how a chess engine works, this could spare you some more time then googling around.

[hgm]

In many pawn endings the difference between having e.p. rights in a certain position is the difference between winning or losing. Even in the middle game the difference is often a full Pawn.

Suppressing false e.p. rights (i.e. no enemy Pawn next to the moved Pawn) makes hashing in the early middle-game (where there are many double moves) very much more effective. Testing for the pawns only takes a bnano-second. Making an extra hash probe takes a few hundred nanoseconds.

[Fguy64]

...

P.S.: I have found http://chessprogramming.wikispaces.com/ an useful site to have an idea of how a chess engine works, this could spare you some more time then googling around.

Sorry if I'm veering slightly off topic. I prefer Colin Frayne's site for just getting started, it seems a little less advanced. Can move on to ChessWiki once I get past this...

http://www.frayn.net/beowulf/theory.html

[hgm]

Note that the piece-square tables in the quoted example are incredibly poor. E.g. having your white King on e5 in the middle game is more like -1000 than like -50, having a Pawn on the 7th is more like +280 than +50.

[wgarvin]

Many engines only set the en-passant square if it is actually threatened by an opponent pawn. In this case it very often contributes to the value of a position.

Ah that makes a lot more sense -- that addresses the problem I was having with having to store 'useless' en-passants that were blocking access to TT entries.

The first thing that occurs to me is that the act of deciding whether or not a square is attacked by a neigboring pawn is more work than just setting an ep flag when a pawn moves two squares and be done with it. Given that I don't really know what's going on here, I probably have missed the point of this exchange.

p.s my knowledge of "proper" chess algorithms is limited.

I think you must check whether or not a square is attacked by a neighboring pawn and set the ep flag, regardless of the amount of work and whether or not it seems justified. Remember that that information becomes part of the position hash which is used for detecting repetitions. If you don't check it, you could see a position reoccur where at one time there is a possible en-passant capture and at another time there isn't and incorrectly determine that its a repetition draw when really it isn't.

The position with the enpassant square can never re-occur during the game. But you're right that you still need to know if there is an attacking pawn or not in order to handle the repetitions correctly.

[Fguy64]

Many engines only set the en-passant square if it is actually threatened by an opponent pawn. In this case it very often contributes to the value of a position.

Ah that makes a lot more sense -- that addresses the problem I was having with having to store 'useless' en-passants that were blocking access to TT entries.

The first thing that occurs to me is that the act of deciding whether or not a square is attacked by a neigboring pawn is more work than just setting an ep flag when a pawn moves two squares and be done with it. Given that I don't really know what's going on here, I probably have missed the point of this exchange.

p.s my knowledge of "proper" chess algorithms is limited.

I think you must check whether or not a square is attacked by a neighboring pawn and set the ep flag, regardless of the amount of work and whether or not it seems justified. Remember that that information becomes part of the position hash which is used for detecting repetitions. If you don't check it, you could see a position reoccur where at one time there is a possible en-passant capture and at another time there isn't and incorrectly determine that its a repetition draw when really it isn't.

The position with the enpassant square can never re-occur during the game. But you're right that you still need to know if there is an attacking pawn or not in order to handle the repetitions correctly.

It's not clear to me what you are saying. Do you mean that the existence of an epTarget square is a characteristic of the position that is being repeated, or that you must ensure that the existence of an epTarget square does not become a part of your condition for 3-fold repitition. See what I'm asking?

[sje]

If an en passant target square is set only after a double pawn advance, then it is impossible for the resulting position to be a draw by repetition or by the fifty move rule.

[Fguy64]

If an en passant target square is set only after a double pawn advance, then it is impossible for the resulting position to be a draw by repetition or by the fifty move rule.

duly noted, but it is possible according to the rules of chess for double pawn advance to create the first instance of a three fold repetition, right? In which case the existence of an ep target is not part of the repeated position according to my definitions.