Author: Bruce Moreland
Date: 01:08:02 11/06/98
Go up one level in this thread
On November 05, 1998 at 11:02:59, Ernst A. Heinz wrote: >On November 05, 1998 at 09:47:34, Andrew Dados wrote: >> >> Suppose somewhere deep in the search I get reduction to B vs 2P ending... >>what value >>should I assign to it? Side with Bishop can't win - so draw for side with 2P at >>minimum... If I assign 2 *P value then my program will sac Knight for Pawn in >>B+P vs N+2P...rarely sensible . What should my eval return in B vs P and B >vs >>2P ? >> >> Andrew .....(I better get those tablebases working :) > >Try to incorporate my efficient implementation framework for interior-node >recognizers which allows for the expression of "bounded" knowledge such as >"this is at least a draw". A preprint of my according article about efficient >interior-node recognizers as published in the ICCA Journal 21(3) is publicly >available from the WWW page of "DarkThought" at URL I liked your idea of using a hash table. I'll try to give you something back, if you haven't thought of any of the following. When mine boots, it loads the hash table with the material signatures and evaluation function addresses, but I intentionally allow several evaluation functions to share the same material signatures. If I notice that I've already got an evaluation function for this material signature, I chain them. Order is important, of course. I add endgame databases last, so they'll be the first ones to be tried, since this thing is LIFO. So, for instance, in order to do KBP vs KB, I have one that checks the table if it's installed. If the table isn't installed, it moves onto another one that checks to see if it's a wrong rook-pawn condition for the side with the pawn, with the weaker king near the corner, and if so it returns a draw score. This one isn't perfect because there are mates, but I don't care since I call it at the tips only. If that one fails, it goes into one that checks to see if the king is blockading the pawn, and if so, it returns a draw score. This is somewhat redundant with the previous one, so perhaps I don't need the previous one, but they are slightly different, and I haven't check to see what happens if I take that one out. If that one fails, and the bishops are of opposite color, it calls the normal evaluation function and mashes the score toward zero. It could be more foxy in this case and see if the bishop is is on a diagonal the pawn will have to cross, but this function is called when there are lots of different numbers of pawns, so that one wouldn't work in this case, I'd have to write a new one, which might be worth doing. If none of the above conditions applies, it just uses the normal evaluation function. If I am at an interior node, and the material count has just changed, I'll check the evaluation function chain to see if any of them are capable of returning exact scores, and if so I'll give them a shot, which might let me cut off immediately. The one that uses databases can of course return an exact score so it can be used at interior nodes, but this isn't the only one that can return an exact score. In the case of KBP vs K, my wrong rook pawn evaluation function is good enough that it can't make a mistake, so if the position is drawn it will return an exact score and cut off. Maybe you do this. I just now looked at this page: http://wwwipd.ira.uka.de/Tichy/DarkThought/node44.html The first half implies a staged eval function, but the code at the bottom seems to rule this out. If somewhere in your paper you say you do this, and I missed it, my apologies. But if you don't do this, you may wish to consider doing it. Basically you can make your recognizer thing a loop rather than a single lookup. I've just started implementing knowledge, but I've found that you can do some pretty powerful stuff without having to work very hard. bruce
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.