Draw by position repetition

[cms271828]

Thanks, but I still don't see the problem with my idea, I'll recap:

I have null move turned off as its just adding to the confusion.

So basically my hash table has nothing to do with my repetition detection,
During the search, at each node, before I do anything else, I store the zobrist key for the current node in a small array (size 100) in the correct place.

Next, I loop backwards (using a 2nd array paired with 1st one, which stores position in 1st array to search back to) through the array (in steps of 2), if I find an identical zobrist, I immediatley return 0.

So if theres a node which repeats a previous position (found before, on same path leading to this node), it won't need to look into the hash table, as 0 will be returned.

So thats what I'm doing at the min, and seems to work, but if its wrong, then I really need to know why, thanks

[bob]

Thanks, but I still don't see the problem with my idea, I'll recap:

I have null move turned off as its just adding to the confusion.

So basically my hash table has nothing to do with my repetition detection,
During the search, at each node, before I do anything else, I store the zobrist key for the current node in a small array (size 100) in the correct place.

Next, I loop backwards (using a 2nd array paired with 1st one, which stores position in 1st array to search back to) through the array (in steps of 2), if I find an identical zobrist, I immediatley return 0.

So if theres a node which repeats a previous position (found before, on same path leading to this node), it won't need to look into the hash table, as 0 will be returned.

So thats what I'm doing at the min, and seems to work, but if its wrong, then I really need to know why, thanks

That sounds fine and is what I do (a repetition list). I was commenting on the hash table approach which works, but there are performance issues.

[cms271828]

Oh I see...

Seems like a bit of bother using a hash table for this, when an array is more intuitive, and less hassle and faster.

I'm not entirely sure about using the array method with null move, as the null move doesn't give a true representation of the search.

So I'm thinking I only do this in nodes of the tree where no null has been played at all leading upto that node, so that that path represents a possible line of play. These nodes should be simple to identify, and it seems intuitive to me, or is there a better way?

Thanks

[bob]

Oh I see...

Seems like a bit of bother using a hash table for this, when an array is more intuitive, and less hassle and faster.

I'm not entirely sure about using the array method with null move, as the null move doesn't give a true representation of the search.

So I'm thinking I only do this in nodes of the tree where no null has been played at all leading upto that node, so that that path represents a possible line of play. These nodes should be simple to identify, and it seems intuitive to me, or is there a better way?

Thanks

It works fine with null move.You can either choose to not search back thru the list for entries stored prior to the null move, you can modify the hash signature when you make a null-move (probably not a good solution) or you can ignore it, which is what I am doing. Nothing wrong with terminating repeating branches after a null-move. Anything to make it go faster...