Body: <p>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.</p>
  <p>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).</p>
  <p>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?</p>
  <p><a href="https://github.com/roy-debabrata/SpotChess/blob/master/src/main/java/com/debabrata/spotchess/utils/MoveUtil.java" rel="nofollow noreferrer">Here</a> 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).</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-10-22T03:13:22.317Z
Comments.Text: I found this edge case where it will fail: [link](https://chess.stackexchange.com/a/18397/30082), 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).
Comments.UserDisplayName: Debabrata Roy
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-10-22T20:11:09.253Z
Comments.Text: 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.
Comments.UserDisplayName: Debabrata Roy
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-10-26T05:10:01.200Z
Comments.Text: Your code could do with some refactoring. Compare and contrast e.g. [this bit from Stockfish](https://github.com/official-stockfish/Stockfish/blob/2046d5da30b2cd505b69bddb40062b0d37b43bc7/src/position.cpp#L444), which is used generically to implement pinning logic for both sides.
Comments.UserDisplayName: Kevin
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-10-26T14:43:41.737Z
Comments.Text: @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?
Comments.UserDisplayName: Debabrata Roy
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-10-26T17:54:52.250Z
Comments.Text: 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).
Comments.UserDisplayName: Kevin
Tags: <engines><programming><pins>
Title: Is this a possibly faster way to find pinned pieces using magic hash?
ThreadText: # Is this a possibly faster way to find pinned pieces using magic hash?
  
  (Asked by: username_0 on 2021-10-22)
  
  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](https://github.com/roy-username_0/SpotChess/blob/master/src/main/java/com/username_0/spotchess/utils/MoveUtil.java) 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).
  
  **Tags:** engines, programming, pins
  
  > **Comments:**
  > **username_0**: I found this edge case where it will fail: [link](https://chess.stackexchange.com/a/18397/30082), 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).  
  > **username_0**: 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.  
  > **username_1**: Your code could do with some refactoring. Compare and contrast e.g. [this bit from Stockfish](https://github.com/official-stockfish/Stockfish/blob/2046d5da30b2cd505b69bddb40062b0d37b43bc7/src/position.cpp#L444), which is used generically to implement pinning logic for both sides.  
  > **username_0**: @username_1 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?  
  > **username_1**: 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).  
  
  ---
  
  ## 0 answers
  
  