Author: Heiner Marxen
Date: 11:19:00 06/16/03
Go up one level in this thread
On June 16, 2003 at 04:42:43, Andrei Fortuna wrote: >On June 16, 2003 at 04:30:14, Uri Blass wrote: > >>On June 16, 2003 at 03:47:02, Andrei Fortuna wrote: >> >>>Hi, >>> >>>Recently I have been thinking a lot about game trees. As you might know I have >>>released a free library that can be used with a chess program to output game >>>trees to a file (that later can be viewed/analysed). The solution I came up was >>>along those lines : >>> * call a function to setup position before analysis starts >>> * all search functions need to be modified by adding an extra parameter >>>(node_id of the parent node) >>> * when the engine enters a search node : first thing to do is get a node_id >>>from the library (this way children nodes will always have an id higher than >>>their parents) >>> * when the engine exists a search node it will write the collected data for >>>this node to an output file >>> >>>No extra memory is needed, all nodes are written as they appear ... but it might >>>look a bit complicated at first look. Do you think there is a better way (i.e. >>>simpler in terms in changes that need to be done to the existing chess program) >>>for this task ? >>> >>>Cheers, >>>Andrei >> >>Yes >> >>I believe that it is more simple not to add parameters but only to change >>the makemove function and undomove function and the function to setup position. I agree with Uri here. And it can be done much less intrusive. >>Adding parameter means that I need to change all the places when I call >>alphabeta and qsearch and I do not like to do it for the original code if I care >>about speed(adding parameter may do the program slightly slower). >> >>changing only the makemove,undomove and setup position seems more simple and I >>can get rid of it when the program plays a game by the following kind of code >>inside makemove: >> >>#if TREE >>//tell information about move to external program >>... >>#endif I would design the following additional functions/macros: - if you need it, lets have a startup function - makemove announcer - undomove announcer - announcing score for current position - stop tracing (we'll do some moves without wanting them to be traced) - continue tracing stop/cont should be nestable, i.e. count a nesting level. If you want a current nodeID, just make a stack for them, maintained by the makemove/undomove announcers. The score announcement could be supplemented with more infos, but I would prefer when each kind of info has its own announcer. Also, the program tracing should also work without this additional info. I've done such a kind of tracing for Chest. It is not hard to do, and does not add much overhead. >Ok, but in this case how can you know in makemove/unmakemove: > * the node_id of the parent node (this is needed when you write the node) > * the returned score for the node > >What if you use makemove/unmake move for something else than calling Search or >QSearch ? Use stop/cont around the special work. > >Andrei As an additional service you could offer a single manifest (#define) that enables/disables the tracing at compile time, by making macros for all needed operations, and conditionally let them call functions or do nothing. I hate lots of #ifdef cluttering my code, and often introduce conditionally defined macros to improve readability. Cheers, Heiner
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.