Author: Tony Werten
Date: 11:22:49 11/19/03
Go up one level in this thread
On November 19, 2003 at 12:09:46, Bas Hamstra 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. >> >>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. >> >>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 > >Aha I see. But that *will* make errors, for instance I wouldn't begin to skip >losing captures in the qsearch based on this. Depends. Skipping loosing captures is no problem, skipping winning captures if they don't bring the score close to alpha would be too dangerous in my opinion. >However the idea of getting the >SEE value based on table lookup is very interesting, because I already use SEE a >lot and would use it even more if it wasn't such a performance killer. But I >like it to be reliable, because x-rays do happen and they matter. For instance >this: > >r . R . . . q r >. . . . P . . . >. . . . . . . . >. Q . . . . . . >B . . . . . . . >. . . . . . . . >. . . . . . . . >. . . . R . . . > >Tao can determine the SEE value of e7-e8 quite well, and I am not willing to >give that up. Question is, can you ever get that from a table lookup. Sure. Pawn moves forward, if black takes with queen you take back with a rook => winning, at least q-(R+P) Off course with pawnmoves, you might have to make sure your attackbyte is correct when there is a rook behind it. You also have to ask:" How often will the (few) exceptions happen" Tony > > >Bas.
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.