1

Okay so this is something that I came up with while working on my own engine, but I am not sure if anyone has ever tried. Basically I am using a separate set of magic hashed longs to store pieces and their pinners. So far as I can think this should work. I have a rudimentary implementation and I still need to test it, so I can think through on ways to potentially break it.

The idea only works if we already know that we are not under check. Basically, we use the king's position and all pieces covered by a regular rook or bishop mask to do the magic hash lookup. This returns us a bitboard with the pieces sitting closest to the king in any direction and the piece that next comes after it. So in every direction we have exactly two set bits. If one of them is an opposite coloured rook/bishop we can be certain it's behind the other piece (because we're not in check).

Now all we need to check is if the other piece belongs to us. In case it's our piece we know that it's a pinned piece. Now we can determine if it's a kind of piece that is partially pinned or a kind that gets fully pinned. I do hope that I haven't overlooked anything. Is this not an original idea, or is it? How do you guys think this will perform? Do you see something I am overlooking?

Here is a link to my commit with my rudimentary implementation. (It's a Java based engine so it's not exactly gold standard, also it's a work in progress. I am still at move generation).

Debabrata Roy
  • 11
  • 3
  • I found this edge case where it will fail: link, but I imagine other algorithms would flounder on this as well without additional checks. (Unless you check after making a move if king can be captured). – Debabrata Roy Oct 22 '21 at 03:13
  • There were some obvious issues with the code which I guess I'll blame on sleep deprivation. Wrote selector as x ^ (x-1) instead of x & -x. Also a few other small mistakes. I am updating the link to the file rather than the commit so I can keep updating as I fix issues. Sorry if I confused you. – Debabrata Roy Oct 22 '21 at 20:11
  • Your code could do with some refactoring. Compare and contrast e.g. this bit from Stockfish, which is used generically to implement pinning logic for both sides. – Kevin Oct 26 '21 at 05:10
  • @Kevin I agree. The move generation bit is a pig sty. But stockfish has the advantage of inlining (which java does too). But java does it in run time so more difficult to analyse. So I wrote it to use as few instructions as possible. Now what I am going to do is (once I am done with perft-ing) then use this as a benchmark while I re-organize and just make sure there's no peformance hit. But conceptually, do you see any issue with the algorigthm? – Debabrata Roy Oct 26 '21 at 14:43
  • Frankly, I have no idea. It's too hard to understand. I would suggest you write a slow version that you know is correct, and then try to improve its speed, rather than starting with a fast version which you are unsure of. At the very least, you could use the slow-but-correct version to unit-test an unrelated fast version (by comparing their outputs). – Kevin Oct 26 '21 at 17:54

0 Answers0