Author: Uri Blass
Date: 08:22:44 06/14/04
Go up one level in this thread
On June 14, 2004 at 09:33:17, Fabien Letouzey wrote: > >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 am sure that when I tried it I earned from it. I did not have hash at that time and I did not try to disable it since that time. I have more ideas for path dependent evaluation that I still did not try and humans use path dependent evaluation in games that they play. > >>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. Thanks I think that the success of movei is mainly thanks to some search tricks and part of the path dependent evaluation. There is another part of path dependent evaluation that I plan to get rid of it and it is the mobility evaluation. Movei use basically 2 numbers for mobility evaluation(number of legal moves of the side to move and number of legal move of the opponent in the previous ply). It is carful not to use it when the side to move is in check and in this case it goes 2 plies earlier if it can do it. I did it in that way because this was the easiest way for me to implement mobility. It was clearly productive but I am sure that it is not the best way. The price in speed was nothing for me because movei always generated list of legal moves. The reason is that I have no function to generate only captures and my qsearch first generate the list of legal moves and later look for the captures (and also for checks in the first ply). Writing a function to generate only captures is possible but it is not an easy task in the structure of movei so I am not going to do it in the near future. Uri
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.