Repetitions in Crafty
Martin Borriss
Yesterday I had a look at the way repetitions and 50-Moves-Rule are handled
in Crafty ( I have the v9.31 sources, assuming they haven't changed much in
this respect ).
I am not going to explain the scheme (I think Bob did this already),
but I have 2 questions:
1) in repetition_check(), when you go through the list of positions worth
checking for repetition, how do you recognize the repetition? ( Repetition
is if position has occurred twice in game history before; or once in the
search). I don't see Crafty checking for a position occurring *twice* ?!
What did I miss, Bob?
2) Since the repetition_head_[w|b] is resetted to the beginning of the list
if an irreversible move at the root is made: If I take back such a move,
make a 'reversible' move instead - the game history is already overwritten?
Or do you push all moves from the game into Crafty again if someone takes
back a move (sorry, I didn't check this)?
This is directed to Bob Hyatt, but if someone else feels like answering
(mclame?) this is of course welcome.
Martin
chessman
On 30 Jan 1997 10:19:03 +0100, bor...@inf.tu-dresden.de (Martin
Borriss) wrote:
>Yesterday I had a look at the way repetitions and 50-Moves-Rule are handled
>in Crafty ( I have the v9.31 sources, assuming they haven't changed much in
>this respect ).
>
>I am not going to explain the scheme (I think Bob did this already),
>but I have 2 questions:
>
I would to look look at the latest source because I know Bob had to
correct the counting in the *50 move* rule code...since that rule only
kicks in when both players have played 50 moves...I know the that the
repetition code works.
>Martin
>
>--
>Martin....@inf.tu-dresden.de
Robert Hyatt
Martin Borriss (bor...@inf.tu-dresden.de) wrote:
: Yesterday I had a look at the way repetitions and 50-Moves-Rule are handled
: in Crafty ( I have the v9.31 sources, assuming they haven't changed much in
: this respect ).
: I am not going to explain the scheme (I think Bob did this already),
: but I have 2 questions:
: 1) in repetition_check(), when you go through the list of positions worth
: checking for repetition, how do you recognize the repetition? ( Repetition
: is if position has occurred twice in game history before; or once in the
: search). I don't see Crafty checking for a position occurring *twice* ?!
: What did I miss, Bob?
Nothing. I don't do this at present. I did in Cray Blitz, but when I fooled
with this (twice in history + once in search *OR* twice in search) I managed
to break it several times (check main.c comments for the exact number of
times I changed and broke this. :) )
At present, repeating a position twice is a draw, period. It is occasionally
wrong, and allows an opponent to "undo" a bad move if crafty is behind, because
it will promptly undo its move to repeat and bring the score up to a draw. It
is on my list of things to fix before long as well, although I certainly wonder
how badly I'll break it first. Note that screwing this up doesn't result in
poor play, it results in catastrophies... *bad* ones... :)
: 2) Since the repetition_head_[w|b] is resetted to the beginning of the list
: if an irreversible move at the root is made: If I take back such a move,
: make a 'reversible' move instead - the game history is already overwritten?
: Or do you push all moves from the game into Crafty again if someone takes
: back a move (sorry, I didn't check this)?
I believe in that older code you are correct. In the new code, anytime you
take back a move, it simply runs back through the actual game move history and
reloads the repetition list from that. The bottom line is that using the
reset command or whatever should leave the repetition list in working order
for all cases, so far as I know...
Newer craftys are a little faster here, because the 50-move rule counter
controls how many moves in the repetition list need to be compared when
looking for repetitions, because a pawn push or capture means there's no
need in looking at positions before that move since a repetition would be
totally impossible. It is very fast as it is currently implemented...
: This is directed to Bob Hyatt, but if someone else feels like answering
Robert Hyatt
chessman (ches...@voicenet.com) wrote:
: On 30 Jan 1997 10:19:03 +0100, bor...@inf.tu-dresden.de (Martin
: Borriss) wrote:
: >Yesterday I had a look at the way repetitions and 50-Moves-Rule are handled
: >in Crafty ( I have the v9.31 sources, assuming they haven't changed much in
: >this respect ).
: >
: >I am not going to explain the scheme (I think Bob did this already),
: >but I have 2 questions:
: >
: I would to look look at the latest source because I know Bob had to
: correct the counting in the *50 move* rule code...since that rule only
: kicks in when both players have played 50 moves...I know the that the
: repetition code works.
: >Martin
: >
: >--
: >Martin....@inf.tu-dresden.de
Correct. I also had to take care of the 50th move mating the opponent,
because that mate overrides the potential 50 move draw. It works correctly
in current versions, but this is a pretty recent change as Martin mentioned..
Martin Borriss
In article <5cqcn6$1...@juniper.cis.uab.edu>,
hy...@cis.uab.edu (Robert Hyatt) writes:
>Martin Borriss (bor...@inf.tu-dresden.de) wrote:
>: Yesterday I had a look at the way repetitions and 50-Moves-Rule are handled
>: in Crafty ( I have the v9.31 sources, assuming they haven't changed much in
>: this respect ).
>
>
>: 1) in repetition_check(), when you go through the list of positions worth
>: checking for repetition, how do you recognize the repetition? ( Repetition
>: is if position has occurred twice in game history before; or once in the
>: search). I don't see Crafty checking for a position occurring *twice* ?!
>: What did I miss, Bob?
>
>Nothing. I don't do this at present. I did in Cray Blitz, but when I fooled
>with this (twice in history + once in search *OR* twice in search) I managed
>to break it several times (check main.c comments for the exact number of
>times I changed and broke this. :) )
>
>At present, repeating a position twice is a draw, period. It is occasionally
>wrong, and allows an opponent to "undo" a bad move if crafty is behind, because
>it will promptly undo its move to repeat and bring the score up to a draw. It
>is on my list of things to fix before long as well, although I certainly wonder
>how badly I'll break it first. Note that screwing this up doesn't result in
>poor play, it results in catastrophies... *bad* ones... :)
>
I recently played with a Crafty on GICS and it repeated moves twice and
"played on" the third time. This in fact happend three or four times in the
game. The position was objectively equal, but of course Crafty wanted to
play on against the poor human.
So I was *convinced* that Crafty knew the difference between repeating a
position twice or three times.
I would very much like to avoid the "undo" effect, since this is an easy way
to correct errors (as you said) and also to make a draw, even if only seconds
are left.
Also, if I go to the trouble of keeping the list I really want to handle this
case, otherwise I could do this twice-repetition check simply with a hash
table.
I could imagine funny effects when using this information for hashing. You
basically have the same position, but one time you get back a draw for
it, another time you don't. We'll see.
>
>: 2) Since the repetition_head_[w|b] is resetted to the beginning of the list
>: if an irreversible move at the root is made: If I take back such a move,
>: make a 'reversible' move instead - the game history is already overwritten?
>: Or do you push all moves from the game into Crafty again if someone takes
>: back a move (sorry, I didn't check this)?
>
>I believe in that older code you are correct. In the new code, anytime you
>take back a move, it simply runs back through the actual game move history and
>reloads the repetition list from that. The bottom line is that using the
>reset command or whatever should leave the repetition list in working order
>for all cases, so far as I know...
>
>Newer craftys are a little faster here, because the 50-move rule counter
>controls how many moves in the repetition list need to be compared when
>looking for repetitions, because a pawn push or capture means there's no
>need in looking at positions before that move since a repetition would be
>totally impossible. It is very fast as it is currently implemented...
>
This is already in v9.31. Both updating the 50move rule counter and the
repetition_list_head_[w|q]. What I meant was since you reset the
repetition_head to the start of the list when a non-reversible move occured
you will overwrite whatever was there before; this info is lost if you
takeback. However, it sounds like you keep an actual game history which has
everything still there.
No big deal anyway.
Martin
Robert Hyatt
Martin Borriss (bor...@inf.tu-dresden.de) wrote:
: In article <5cqcn6$1...@juniper.cis.uab.edu>,
I have a repetition check that uses LookUp() to accomplish this, just like
Bruce does in Ferret. The reason I don't use it is that I also use internal
iterative deepening, and that becomes a little messier. At the top of search,
following the PV, you call LookUp() which enters the current position in the
hash table when it doesn't already find it there to set a "trigger" for a
repetition test. Then I find I have no hash move, and recursively call Search()
with the same position, but a shallower depth. This breaks because the repetition
trigger is set and we find the position already there. Takes a kludge to remove
it. It's not impossible, but it also isn't very clean and I've elected to put
up with the list (at present, anyway).
: I could imagine funny effects when using this information for hashing. You
: basically have the same position, but one time you get back a draw for
: it, another time you don't. We'll see.
: >
: >: 2) Since the repetition_head_[w|b] is resetted to the beginning of the list
: >: if an irreversible move at the root is made: If I take back such a move,
: >: make a 'reversible' move instead - the game history is already overwritten?
: >: Or do you push all moves from the game into Crafty again if someone takes
: >: back a move (sorry, I didn't check this)?
: >
: >I believe in that older code you are correct. In the new code, anytime you
: >take back a move, it simply runs back through the actual game move history and
: >reloads the repetition list from that. The bottom line is that using the
: >reset command or whatever should leave the repetition list in working order
: >for all cases, so far as I know...
: >
: >Newer craftys are a little faster here, because the 50-move rule counter
: >controls how many moves in the repetition list need to be compared when
: >looking for repetitions, because a pawn push or capture means there's no
: >need in looking at positions before that move since a repetition would be
: >totally impossible. It is very fast as it is currently implemented...
: >
: This is already in v9.31. Both updating the 50move rule counter and the
: repetition_list_head_[w|q]. What I meant was since you reset the
: repetition_head to the start of the list when a non-reversible move occured
: you will overwrite whatever was there before; this info is lost if you
: takeback. However, it sounds like you keep an actual game history which has
: everything still there.
: No big deal anyway.
Right. the "game.nnn" file has the real moves. A reset reads back thru this
to reconstruct the repetition_lists...
: Martin
: --
: Martin....@inf.tu-dresden.de
Tom C. Kerrigan
Martin Borriss (bor...@inf.tu-dresden.de) wrote:
> This is directed to Bob Hyatt, but if someone else feels like answering
> (mclame?) this is of course welcome.
^
Sorry, couldn't resist... :)
Cheers,
Tom
Martin Borriss
In article <5ctmdh$2...@merlin.pn.org>,
Yup, me too. :) Glad to see you paid attention.
Ich hoffe, Du passt im Deutschunterricht genauso auf!
Martin