Author: martin fierz
Date: 01:41:17 11/28/03
Go up one level in this thread
On November 27, 2003 at 12:39:06, Ed Schröder wrote: >On November 27, 2003 at 07:54:50, martin fierz wrote: > >>hi, >> >>i have a question about ed schröder's webpage, specifically on the hanging >>pieces part. >> >>ed explains that he has two tables which contain attack info for each square of >>the board, they look like this: >> >>+------+------+------+------+------+------+------+------+ >>| BIT0 | BIT1 | BIT2 | BIT3 | BIT4 | BIT5 | BIT6 | BIT7 | >>+------+------+------+------+------+------+------+------+ >>| Number of | PAWN |KNIGHT| ROOK | QUEEN| KING | >>| ATTACKERS | |BISHOP| | | | >>+------+------+------+------+------+------+------+------+ >> >>so if you have a square attacked by a white pawn and a white bishop, you get the >>value 00011010 in binary notation for this square, or 26. >>next, ed explains that he has a 3D table >> >>[piece_type][white_attack][black_attack] ([12][256][256]), which contains the >>expected value for a capture on a square. >> >>for example, if you have a pawn which is attacked by 2 pawns and is defended by >>a knight, you will find in your table that the expected material gain is 1 pawn. >>up to here i understand all of this, and it seems like a great idea - you have a >>SEE based on a single table lookup. it doesn't deal with xray-attacks, of >>course. > >Rebel while creating the attack tables supports xray attacks. > >If you have Rebel 12 (dos or win) have a look at the file ATTACK.BIN which is >the representation of the [piece_type][white_attack][black_attack] >([12][256][256] table with all its precalculated results. hi ed, i don't own any copy of rebel, so i can't do that. i owned a rebel module for a mephisto board once though, but i) i gave it away, ii) probably you didn't have that attack.bin file in the ROM there and iii) even if you did i would have trouble finding it :-) but it's the idea that counts, and i understand the idea quite well. i was just a bit concerned about inaccuracies of the system, and wanted to make sure that i understood that properly - that there are inaccuracies but it's ok most of the time. >It depends how you are planning to use the information, it is great for >move-ordering, q-search, static selective search, pruning, extensions, >reductions, eval. However you (for example) can't replace q-search with a static >evaluation of the hanging pieces, for that the data is too insecure. i want to use the data for move ordering, and in the QS to throw out losing captures. the QS will stay there, but at the moment my QS is much too big and i need a way to reduce the number of captures i'm looking at. i do a crafty-style (OMG, if i ever participate in an ICGA event i'll be accused of being a clone!) QS, getting a stand-pat score first and trying to improve it if necessary by looking at captures which look good. only up to now my heuristic for deciding which captures look good only knows about "small piece takes big piece" and "piece takes undefended opponent piece"; it's pretty much agnostic on other captures (where something captures something that's defended) and searches them last, but it doesn't discard them outright (except for really really bad captures, such as QxP, protected by P). which i guess is what i would want my program to do... cheers martin
This page took 0.01 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.