Author: Sune Fischer
Date: 01:39:06 07/04/02
Go up one level in this thread
On July 03, 2002 at 22:49:42, Russell Reagan wrote: >On July 03, 2002 at 17:46:08, Daniel Clausen wrote: > >>But evaluating a board position is far more IMHO. Maybe I want to have different >>evaluation classes, for example one for the opening, one for the middlegame and >>one for the endgame. Of course I could make 3 methods in the board class for >>this. but my intuition tells me this is not a good thing. > >This is (from what I've read the past few days in my studying this topic) the >correct way of dealing with this. For my program, one of the things I am most >interested in is testing my ideas for evaluation, and so I would like to >implement an evaluation module where I can create different ways of evaluating, >plug it in, and it *should* work flawlessly, and I should be able to test my >ideas more efficiently that way, rather than having to change other data >structures to make a new evaluation function "fit" into my program. > >Over the past few days I've been reading some in Code Complete and a series of >articles called Code on the Cob ( >http://www.gamedev.net/reference/list.asp?categoryid=45 ). There are some good >ideas in there, but I haven't read all of the articles yet. > >Russell I did these game phases before using a hashtable, then I figured it might not be the best way, because you really need to reset the hash everytime you change state. I like the idea even less, actually. Because where do you go from opening to middelgame? If your book is large enough you hardly need much 'opening' code, and in any case I think of it more as a smooth transition, and I believe the code should reflect that rather than be boxed into phases. Still, the decision on which game-phase to be in must depend on the position on the board, and not on whether you did 15 or 20 moves, IMO. -S.
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.