Author: Fabien Letouzey
Date: 06:33:17 06/14/04
Go up one level in this thread
On June 14, 2004 at 08:46:01, Uri Blass wrote: >questions and verification if I understand correctly. >1)Is it correct that Fruit does not evaluate positions >when the king is in check? Yes, this is one of my fundamental principles. Generate all moves and search them when in check. So I know that in any components I add later (e.g. endgame recognisers), I can ignore this issue. I am aware that many programs successfully use capture-only quiescence searches though. >2)Am I correct to assume that op[] is opening evaluation when eg[] is endgame >evaluation? Yes, the final score is an interpolation that only depends on the total material (excluding pawns). All my evaluation terms have two values. This is the most simple way I could find to "deal" with the "phase" problem (e.g. king placement). >3)What is the job of material_get_info? >As far as I can see it is using material_comp_info It is a hash table containing all information that is material-only. Just like a pawn hash table is (usually) pawn-only. I don't have any special use for it, anything that only depends on piece/pawn counts should be stored in that table. In Fruit 1.0 it was clearly worthless. My goal was to provide a way of storing material-only data (e.g. endgame recognisers in the future) with little extra cost. At the moment, very little is used. I use these data only for evaluation at the moment, but I intend to access the table at every node later (e.g. to recognise more draws at internal nodes). >I understand that material_comp_info does the following: >1)calculate drawn positions in simple endgames. Yes, more precisely "likely draw" positions (when the "attacker" has no pawns). I actually have different heuristics: in most cases I just reduce the material balance (I divide it by ten) before applying the other evaluation features. In other cases (insufficient material to give mate) a draw bound/score can result (at evaluation time). Note that the actual scoring is only used at the leaves, so a search is still performed at internal nodes. >2)clauclating phase of the game between opening and endgame to decide about >weight of endgame evaluation and opening evaluation Yes, only to save a division at evaluation time; worthless. >3)calculate pawn correction for rook and knights. >It seems to me that you give bonus for knights if there are more than 5 pawns >and you give panelty for rooks when there are more than 5 pawns. >In other word the claim is that more pawns are good for knights and less pawns >are good for rooks. The idea came from: http://mywebpages.comcast.net/danheisman/Articles/evaluation_of_material_imbalance.htm Note that the code is deactivated: static bool UsePawn = false; // pawn correction for knights and rooks I think the dynamic evaluation should see that say a rook is more powerful in open positions, counting pawns does not look the right way to do it. This idea on the web page is different though: there is a statistical correlation between the rook power and the number of friendly pawns. >4)calculate bonus for pair of bishops Yes. More generally the material score for the evaluation (it does not have to be linear). >5)encouraging the better side to have more pawns and to trade other pieces(I >will probably try to implement it in similiar way). Not used, ignore it: static bool UseTrade = false; // trade pieces not pawns when ahead I have not noticed big problems with not having a trade bonus yet (I do have big problems with basic piece values though). >I see that later in the evaluation you decide to divide the evaluation by 2 in >case of opposite color bishops and the question is what is the definition of >it(Do you consider only endgame with bishops to be opposite color bishop endgame >or also endgame with rooks and bishops?) Experimental code, I think it's simply ridiculous. Not activated of course: static bool UseBishop = false; // opposit-colour bishops >I still did not get to evaluation of pawn structure and evaluation of mobility >that is also interesting for me because I do not think that I like my evaluation >of these factors but I guess that I will do it in another post. I only changed the definition of a backward pawn between Fruit 1.0 and 1.5 >>Unfortunately I don't know what is the fastest way to progress for >>you. You mentionned before that Movei was not using the transposition >>table to full power, it sounds like something promising to fix?! >yes but it seems harder for me to do it. >Movei is using evaluation that is dependent on the path and not only on the >final position and the code of the search is too ugly to make it easy to make >complicated changes without bugs. Are you sure you clearly benefit from path-dependant evaluation? I can understand path-dependent search (e.g. recapture extension), but ... evaluation? As a principle, I try to avoid this. >I believe that a small push of the evaluation to fruit direction can help. >search changes can also help but it seems to me harder to write them without >bugs. Feel free. Given Movei's results, I don't think it is full of bugs ... Good luck in WBEC 1st Division! Fabien.
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.