repetition detection

[Mincho Georgiev]

EP square in Pawny is a part of the key. So position with EP square is just different from one without /or different square/. Repetitions are detected by comparing the lock. I don't use hash table methods for repetition detection, it's just a comparison, done in inner nodes of the tree and no result from it gets stored in the hash table. It just returns zero. I'm sure there are better implementations, but this one works for me, at least I haven't seen any problems. Since I don't hash qnodes at all, this simplistic method could not be used successfully in qsearch, it's going to invoke a major slow down. That's one possible drawback.

[micron]

Glass only considers ep-squares if there is truly a capture possible for the hash-signature. Would be interesting to hear about how this is done in Pawny or Spandrel.

Spandrel does the same.

If I change the rule, so that an ep square is always created by a double-step pawn move, the counts become:

Code: Select all

 
ply   repets     tests    tests/repet
  9       1       82816    82816
 10       5      225016    45003
 11      19      695439    36602
 12      29     1067926    36825
 13      37     1504907    40673
 14     106     3445400    32503
 15     236     8074640    34214
 16     573    16886195    29469
 17    1438    37338302    25965
 18    2972    67816741    22818
 19    8845   138686357    15679
 20   55343   359268058     6491
 21  134935  1111066973     8234

[Evert]

Since I don't hash qnodes at all, this simplistic method could not be used successfully in qsearch, it's going to invoke a major slow down. That's one possible drawback.

You can't have repetitions in a capture-only search. Even if you do non-captures (checking moves) in the lower plies, the error introduced is probably small enough that it doesn't matter, but you could test just for those.

[Desperado]

EP square in Pawny is a part of the key. So position with EP square is just different from one without /or different square/. Repetitions are detected by comparing the lock. I don't use hash table methods for repetition detection, it's just a comparison, done in inner nodes of the tree and no result from it gets stored in the hash table. It just returns zero. I'm sure there are better implementations, but this one works for me, at least I haven't seen any problems. Since I don't hash qnodes at all, this simplistic method could not be used successfully in qsearch, it's going to invoke a major slow down. That's one possible drawback.

Hello Mincho,

maybe i totally misunderstand you, but everyone has to consider
the ep square as part of the key. That is not the point.

The point is, when do you update the ep square so it changes the key.

That has nothing to do with the repetition detection code itself, or
qnodes, or some transposition table tricks.

Michael

[Mincho Georgiev]

Thanks for this hint. Glass only considers ep-squares if there is truly a capture possible for the hash-signature. Would be interesting to hear about how this is done in Pawny or Spandrel.

That's why I've explained it. I'm updating the ep in the key in every make(). I don't see what it has to do with rep. detection either, but since you've started with ep square and I was asked how I'm doing it, it came my explanation.
As for the capture search, and the condescending remarks, maybe I've already got it, but where in my answer I've said "capture search". I'm talking about evasions search and believe me, there ARE repetitions in there.

[Evert]

As for the capture search, and the condescending remarks, maybe I've already got it, but where in my answer I've said "capture search". I'm talking about evasions search and believe me, there ARE repetitions in there.

I'm not aware of being condescending in any way.
As for "capture search", what you said is "qsearch", which I took to refer to the highly selective search at the horizon where one typically considers captures (and promotions) and possibly checking or other tactical moves in the first few plies. If you meant something else, or do something very different in your quiescence search, then certainly things are different.

[Desperado]

Thanks for this hint. Glass only considers ep-squares if there is truly a capture possible for the hash-signature. Would be interesting to hear about how this is done in Pawny or Spandrel.

That's why I've explained it. I'm updating the ep in the key in every make(). I don't see what it has to do with rep. detection either, but since you've started with ep square and I was asked how I'm doing it, it came my explanation.
...

Well, i think it was me who introduced the ep-square into the discussion.
To now, you didnt answer the question, but maybe i formulated wrong.
It was not my intention to ask "when" in the context of "every make()",
but it was the question

* how does your condition to set the ep-square looks like ?

Code: Select all

from startpos:

1. e4  - testPos  // do you set e3 as ep-square now ?
1. ...   - Nc6
2. Nf3 - Nb4
3. Ng5 - Na6
4. Nh3 - Ng8
5. Ng1 - currentPos

  * can/must/should someone set the ep-square in your opinion,
     or is it even forbidden to do so ?
  * and is currentPos now a repetition of testPos ?
  * doesnt setting or not the ep-status after e4 influence both answers ?

That is the reason why Edmund asked for how it is done in your engine.
IMO nobody here is somehow condescending i believe.
Maybe i am wrong, but i think you missed the point.
if you answer for yourself the given questions in the code snippet,
you will start to see why it has sth to do with repetition detection.

regards, Michael

[Mincho Georgiev]

Well, i think it was me who introduced the ep-square into the discussion.

My reply was to you, not to Edmund.

Code: Select all

1. e4  - testPos  // e3 is the ep square now. /relevance test (like in polyglot) - omitted/
1. ...   - Nc6 //e3 is no longer the ep square 
2. Nf3 - Nb4 
3. Ng5 - Na6
4. Nh3 - Ng8
5. Ng1 - currentPos //e3 is no longer the ep square as well.

  * IMO one could set up ep square - it's easier and faster than making relevance test.
  * currentPos is not equal to testPos - e3 is not set up as e.p. square in it.
  * i'm not sure I got this one, i think setting E4 doesn't influence the 2nd paragraph, since currentPos IS NOT EQUAL to testPos.

[Desperado]

Well, i think it was me who introduced the ep-square into the discussion.

My reply was to you, not to Edmund.

Code: Select all

1. e4  - testPos  // e3 is the ep square now. /relevance test (like in polyglot) - omitted/
1. ...   - Nc6 //e3 is no longer the ep square 
2. Nf3 - Nb4 
3. Ng5 - Na6
4. Nh3 - Ng8
5. Ng1 - currentPos //e3 is no longer the ep square as well.

  * IMO one could set up ep square - it's easier and faster than making relevance test.
  * currentPos is not equal to testPos - e3 is not set up as e.p. square in it.
  * i'm not sure I got this one, i think setting E4 doesn't influence the 2nd paragraph, since currentPos IS NOT EQUAL to testPos.

Ok,

your case:
========
* so you use the "only double pawn push" condition.
That is different than Edmund is doing.
* testPos != currentPos is logical consquence now
* look at Edmunds case...

Edmunds case:
===========

* he doesnt set the ep square
* testPos == currentPos
* he has a repetition here !!
( that is the reason why it is making difference how ep-square is
handled in repetition context )

So, and if you replied to me, then please tell me now exactly which part
of my posts have been condscending ?!!

Michael

[Mincho Georgiev]

I replied to you, answering why I'm explaining what the ep square fits in my rep. detection, because you said that you don't see what this have to do with the subject. I said, that what has to do it was that I was asked from Edmund for it (at least I thought so). The condescending part neither came from you, nor it was pointed at you so, please read above.