Author: martin fierz
Date: 07:24:26 02/16/04
Go up one level in this thread
On February 16, 2004 at 09:46:24, Tord Romstad wrote: >On February 16, 2004 at 07:09:29, martin fierz wrote: > >>On February 16, 2004 at 05:57:50, Tord Romstad wrote: >> >>>On February 15, 2004 at 17:08:43, martin fierz wrote: >>> >>>>of course, you have a long-developed engine with a balanced evaluation function. >>>>mine is 7.5 months old, and therefore is still pretty bad ;-) >>> >>>I had no idea it was so young. Considering the young age of your engine, >>>I think Muse is extremely impressive. >> >>well, i have been programming checkers for 7 years now, so i have some >>experience in writing game-playing programs - that of course got me started with >>my chess engine very quickly. many things like negamax, hashing, move ordering + >>it's importance and so on are very easy+clear to me. > >Most of this should apply to me as well right now, when I have started >working on hexagonal chess. The difference between normal and hexagonal >chess from a programming point of view should be comparable (probably >smaller) to the difference between checkers and chess, and I should be >able to profit from my experience with computer chess. Still, I find >the new game tremendously difficult, and I'm afraid I will have to work >for years before the new engine is as strong as my chess program. > >>muse now does most of the >>standard stuff, so it's not too surprising that it's playing sort of sensibly - >>however, it does lots of stuff in a bad way. for example, i know my evaluation >>still needs a lot of tuning. my SEE and qsearch-good-check-detection don't >>detect x-ray attacks. my whole program is slow because of some serious >>inefficiencies. i wouldn't mind being a factor 2 or so slower than crafty - but >>a factor 5-6 seems excessive... > >Well, it depends on how complicated your evaluation function is, of course. >I would guess that strong chess players tend to write evaluation functions >which are much more sophisticated (and hence slower) than Crafty's. The >very low N/s count of the two most well-known chess programs written by >strong players (Chess System Tal and Diep) seem to support this theory. that is all nice and good - but if i switch my eval to material only and find that i'm still much slower than crafty i know something is wrong ;-) >>apart from that, i am also a rather strong chess player (cough), for a chess >>programmer at least - which makes it easier for me to find holes in my eval than >>for others IMO. > >Probably. I am sure Muse will eventually become extremely strong. > >>i think the worst thing i've seen in gothmog is your scoring of connected >>passers. hint: even if you have connected passers on d6+c7 as white, they are >>not worth all that much if black has a bishop on the c8-h3 diagonal, or has a >>king in front of those pawns. i have seen gothmog lose more than once against >>muse because it seems to think that these two passers were worth a piece or more >>- which they are clearly not. of course i can't be 100% sure that your connected >>passer eval is bad in this respect, but i am rather sure it is - you should >>check it! > >Thanks. I am painfully aware of this one, and I have seen lots of lost >games because of this hole. My latest development version is slightly >improved in this respect, but there is still a long way to go. here's an easy way out: make the connected passer eval larger for pawns on c6/d6 larger than for pawns on c6/d7 or c7/d6. like that, you will only push the pawns if you see them either getting to c7/d7 or promoting. else you'll rather keep them on c6/d6 - in general, they are better beside each other than diagonally aligned. i currently try detecting whether they're blocked when diagonally aligned, but i guess the above should work even better. >Other major weaknesses are that lots of important endgame knowledge >is completely missing, i think i saw KRP-KR once, muse on the weak side, clear draw. gothmog thought it was about 1.5 pawns ahead IIRC. a simple but good rule for this one is: if the king of the defending side is anywhere on the pawn's path to a queen, it's a draw - i don't return a draw there, but something like -0.5 pawns for the defender - after all, you still have small chances against a weak opponent. but perhaps this was in a game against frenzee - i hope i haven't mixed things up... > that the space eval is too big and too primitive, >and that Gothmog is too happy to push pawns in front of its own king in >positions with opposite side castling. i haven't noticed that too much yet. you should of course push the pawns on the other wing :-) cheers martin > >>>This, too, very much resembles what I do. The evaluation function doesn't >>>just return a single value, it computes separate values for king safety, >>>pawn structure, passed pawns, mobility, and so on. It also locates pinned >>>and hanging pieces, and detects some simple mate threats. All of this >>>information is used in the search. Whenever a move is made, the position >>>is evaluated and I compare the results at the present node with the results >>>at the previous node. If a move does not increase any of the evaluation >>>components, and it does not attack a piece, threaten mate or anything >>>similar, I prune the move or reduce the search depth. If a move threatens >>>mate or dramatically increases the king safety or passed pawn eval, I >>>make an extension. >> >>in fact, i'm not doing this - yet. it's on my todo list of course, but as i >>wrote i first would like to make my engine "decent" with the standard >>techniques. once i'm satisfied with it, i'll start fiddling with this kind of >>stuff. > >That's probably what I should have done, too. But my biggest weakness as >a chess programmer is my lack of patience. I can't wait until I have the >basics perfected before I start adding more advanced stuff. > >Tord
This page took 0.03 seconds to execute
Last modified: Thu, 07 Jul 11 08:48:38 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.