Author: Tony Werten
Date: 01:14:58 11/20/03
Go up one level in this thread
On November 19, 2003 at 08:33:58, Tord Romstad wrote: >On November 19, 2003 at 03:12:35, Tony Werten wrote: > >>On November 18, 2003 at 11:39:20, Bas Hamstra wrote: >> >>>On November 18, 2003 at 10:51:44, Tony Werten wrote: >>> >>>>Couldn't resist. >>>> >>>>Tony >>> >>>Actually, in Leiden you said SEE costs you only a table lookup. My question is: >>>what about x-rays? It seems impossible to me to get the *real* see value with a >>>table lookup in practice. So how do you do it? >> >>Basicly, I consider every xray attack as a direct attack by a queen :) Works >>pretty well. > >Really? This is very surprising to me. I consider xray attacks as >direct attacks by the most valuable piece of the piece which emits >the X-ray and the piece the ray is radiating through. It seems to me >that counting all xray attacks as queen attacks would cause too many >inaccuracies. Have you tried both approaches? No, I prefer to slam in my code without any testing. ( Nasty remark off ) Serious though, off course it's more inaccurate, but it's also easier. It's a trade off. I used to have a full SEE wich is more accurate but this is way faster so I can use it for non capture moves, wich improved the tree wich resulted in a win. > >Another problem with X-rays is that they make static mate detection much >more tricky. If black's king is on g8, the square g7 is not defended >by any black piece except the king, and a white queen and bishop >attacks g7, I would like to conclude that white has a mate in 1 by Qxg7. >Unfortunately this is not necessarily true, because it is possible that >the queen attack on g7 is just an X-ray attack. And even if the queen >attack is *not* an X-ray, I cannot be entirely sure that Qxg7 is mate, >because it is possible that black has an "X-ray-defence" of g7 through >the white queen (e.g. if white has Bf6 and Qg5, and black has Kg8, Pg7 >and Qg1). Although attack tables speed up static mate detection, I have >not found any reliable way to do it without doing some ray tracing. Sorry, I was a bit unclear about that. I actually have direct queen attacks ( normal ) and "just queen attacks" ( xray ) My static mate detection needs a direct queen to checkmate. But anyway, I was talking about see, not static mate detection. For see there is no difference. > >An idea I have been thinking about lately is to replace my current >9-bit attack tables (similar to Ed's, except that I distinguish between >bishops and knights) with a really huge table (32 bits or more per square) >which contains detailed information about X-ray attacks and defences. >For instance, I want to include information about which of the attacks >are X-ray attacks, and what kind of piece each X-ray attack radiates >through. The entries in such a table will obviously be too big to be >used directly in lookup tables, but perhaps it could be possible to >design lots of small hash tables for things like SEE calculations, >king safety, static mate patterns and so on. > >>It basicly works as Ed described, with a few differences. >> >>I use 2 tables. >>One for looking if a "piece on a square" is safe wich consist of >>[myPiece,defenders_byte(sq),attackers_byte(sq)] and directly gives a score back. >>myPiece=[Q,R,BN,P] >> >>The second table is to see if a "move to a square" is safe, wich consists of >>[movingPiece,defenders_byte(sq),attackers_byte(sq)] I get a score from that by >>doing: score:=value[captured_piece]+see_move_table[piece,def(sq),att(sq)] >>In this case captured_piece may be empty. > >I don't understand how you can make this work. For instance, if white has >a pawn on e7 and a rook on e1, and black has a rook on a8, how do you know >that the move e8=Q is safe? After all, e8 is defended by the black rook, >and not attacked by any white pieces. Don't you need attack information >about the source square as well as the destination square if you want to >check whether a move is safe? With capture moves it is OK, with normal pawnmoves I don't care, it's only move ordering. Promotions I'll do anyway very soon. > >>Another difference is that I enumerate the bytes wich give the attack/defend >>status. Ed uses 0..255 but that's not nescessairy. ie P attacks and N attacks >>but the piececount=1 or 0 is impossible. You can get the numbers down to 64. >> >>So my SEE_TABLE has [0..3,0..63,0..63] elements = 16 K >> >>and my SEE_MOVE_TABLE has [0..5,0..63,0..63] elements = 24 K >> >>A conversation with Gian Carlo made clear that it's possible to half this but I >>couldn't be bothered with the work it needs. The time is spend in generating the >>attacktables, not in the lookup_tables > >I can see how you can reduce the range a bit from 0..255, but not how it >is possible to get as low as 0..63. How do you achieve this? Is it >possible without sacrificing accuracy? Of course, but how often will you go wrong if you consider attacks by 5,6,7,8 queens the same as 4 queens ? More often than you will go wrong with pinned pieces ? I mostly use this stuff for moveordering, worst case, I search the best move a little later. For evaluation, consider the whole board. How bad is it to maybe, very maybe evaluate the attacks on 2 or 3 squares a little less accurate ? Tony > >Tord
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.