Author: Andrew Williams
Date: 10:26:59 01/26/99
Go up one level in this thread
On January 26, 1999 at 12:09:03, KarinsDad wrote: >On January 26, 1999 at 11:01:27, Andrew Williams wrote: > >>On January 26, 1999 at 10:05:09, KarinsDad wrote: >> >>>On January 26, 1999 at 05:12:09, Andrew Williams wrote: >>> >>>>On January 25, 1999 at 18:30:20, KarinsDad wrote: >>>> >>>>> >>>>>I don't understand. Couldn't you just as easily find positions that had castling >>>>>in the TT way before you actually castle in your position? What is so special >>>>>about castling? Is it that the number of transpositions drop drastically after >>>>>castling (even though some would still be there)? Also, wouldn't castling often >>>>>be within opening book moves so you are not yet in your TT? >>>> >>>>Sorry, I wasn't being particularly clear here. What I mean is that after I >>>>castle, I change the pawn scoring to reflect the side the King is now sitting >>>>on. So the pawns on that side are told to stay put, while the ones on the >>>>other side are allowed to advance (this is a simplification, of course). So >>>>I clear the TTs because the scores from before castling are not compatible >>>>with those after castling. >>>> >>>> >>>>Andrew >>> >>>Wow! What a good idea! Probably wouldn't have figured this one out on my own in >>>a long time. >>> >> >>I wish I could claim credit for this, but I think crafty (and probably >>everyone else!) does this too. >> >>>With this in mind, do you also modify the pawn information within the search >>>tree once you castle there as well (i.e. 6 ply down, it castles, hence the >>>evaluation function should have a pawn modification below that node which is >>>different than the pawn structure information, I assume you are using a >separate pawn structure evaluation)? >>> >> >>No. But this was my original intention. I didn't do this because.... >>Oh dear, I've forgotten now. I think it was something to do with the way I >>hash my pawn scores. The hashing only takes into account the location of >>the Pawns, so I can't include any scoring that depends on the location of >>the pieces. (It's coming back to me now). The original idea here was to >>have different pawn scoring in the endgame (try to get them to promote) from >>in the opening and middlegame (try to get them to stand still long enough >>so that I don't get mated). So, I devised a different piece/square table for >>my pawns once I reach the endgame, but "reaching the endgame" is dependent >>on how many pieces are on the board. If I try to switch halfway-through the >>search, it will mess up my pawn hashing (which I don't want because my pawn >>TT gives me a big speed boost). So I switch piece/square tables at the root >>of a search. While I was doing this (endgame piece/square tables), I thought >>it would be a good idea to have different ones to reflect where each side has >>castled - and I just incorporated this idea with the other. >> >>There is a slightly modified approach that would include the King's position >>in the pawn hash key. Then any scoring relating to the King that doesn't >>depend on other pieces (eg pawn shelter around the king) can be included in >>the score that is put in the pawn hash table. This would allow me to switch >>during the course of a search. This was being talked about here a few months >>ago, and I think that Ernst Heinz said he did this. I'm pretty sure that it's >>in crafty too. > >Actually, I would think that having multiple elements of information in your >pawn hash key (similar what I do in my position hash key) such as approaching >endgame (i.e. types and number of pieces remaining, especially the removal of >the rooks and queen), king location, etc., regardless of the pawn structure >could be done. Then, you would not have to prune the TT, each position is scored >individually and "correctly" based on position "conditions". This would either >increase the number of pawn hash entries, or if you put multiple pieces of >information in the pawn structure, you could keep the same number of entries at >the cost of a larger structure and more processing time to calculate it (of >course, you would only have to calculate pertinent info, i.e. if you haven't >castled yet, no need to calculate the castle info., once castling is found in >the search, you could calculate castling info on a per need basis if not >currently in the pawn structure, and once castling is done, you could not >calculate any pre-castle info anymore, and prune the TT accordingly). > >All in all, this may take quite a bit of code and additional time in the search, >so you may be better off doing what you are currently doing. > >Once the rooks and queens are removed from the board, the only piece that can >simultaneously attack a pawn and the square in front of the pawn is the king >(and this only from 3 squares unless the pawn checks the king). Hence, there is >a threshold where the remaining pieces can either attack the pawn, or the > square >in front of the pawn, but not both simultaneously. Therefore, at least two >pieces must be used together to attack a pawn and the nature of the game changes >accordingly. Thanks for this. Can you imagine that I had never thought of it this way! Are you a strong player by the way? For that matter, is anyone else in the U2600 club any good as a player? (I'm useless). > >Also, an open file becomes less useful when the rooks and queen are gone, so >those bonus points for having a half or fully open file should go away at that >point. > >Does your pawn structure take into account open diagonals for bishop and queen? >A harder concept to really understand and implement. No. It's one of those things that I think would be nice to have, but not nice enough to justify the time spent calculating it. PostModernist is an *extremely* inefficient program, so things like this are out of my reach at the moment. > >> >>I hope this is clear (it's a bit "stream of consciousness", I'm afraid). I'm >>really glad you asked the question, because you reminded me that I've only >>done half of what I was thinking about doing. >> >>From the hints you've dropped, your program sounds like an interesting project. >>Any idea how long before it plays its first game? Are you going to play it on >>the servers? > >No. It is in it's infancy. Part of the search algorithm, the hashing algorithm, >and the evaluation function still have to be done, just to get it to work. Plus >we changed it to use xraying and non-xraying attack tables with bitboards for >use by the evaluation function and the legal move generator, hence they have to >change to take advantage of this. Then there is having it talk to WinBoard, >putting more sophisticated evalutation elements such as a pawn structure, >putting in chess knowledge, opening books, etc., etc., etc. We just started 2 >months ago and in reality, have spent less than a half hour a day on average >working on it, so it is slow going. > >I would guess that we will not have it on the servers (and then maybe only fics) >until summer time. But I'm hoping to have at least a 2000 rated program by then. > >Keep working at it :) Good luck, Andrew
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.