Author: Heiner Marxen
Date: 09:01:32 12/29/01
Go up one level in this thread
On December 29, 2001 at 10:39:50, Uri Blass wrote: >On December 29, 2001 at 08:54:43, Rafael Andrist wrote: > >>On December 29, 2001 at 06:16:18, Uri Blass wrote: >> >>>On December 29, 2001 at 05:28:15, Rafael Andrist wrote: >>> >>>>On December 28, 2001 at 16:04:46, Uri Blass wrote: >>>> >>>>>On December 28, 2001 at 15:13:14, Rafael Andrist wrote: >>>>> >>>>>>On December 28, 2001 at 13:46:32, Uri Blass wrote: >>>>>> >>>>>>>I have almost no experience with writing into text files in C and this is one of >>>>>>>the reason that I did not try to do the relevant program by myself and prefered >>>>>>>to concentrate on other things. >>>>>> >>>>>>its practically the same like writing text to stdout, use fprintf instead of >>>>>>printf >>>>> >>>>>I may try to do it later if I get no help but I think that the program that I >>>>>suggest may help many progrmammers because it is not dependent on the structure >>>>>of the program and it is very simple to use(only to add few lines in the right >>>>>place when the lines are the same for all programmers and to add a file that has >>>>>the relevant functions to the project). >>>> >>>>I think it is more efficient to implement it directly in search. To make a >>>>general tool would require another new communication protocol too. >>> >>>You only need 2 functions >>> >>>1)AddInitialPositionToTree(char position[80]); >>>This function get the FEN of the root of the tree >>> >>> >>>2)AddMoveToTree(char move[6];int ply;char* comments) >>>This function get the following information: >>> >>>a)move algebric notation(for example e2e1Q or e8g8) >>>b)ply(if it is bigger by 1 than the previous call for this function you go >>>forward and if it is not bigger you can find how many plies to go backward based >>>on the difference) >>>c)a string of comments >> >>Now you aren't talking about a separate program but about a library you can link >>together with your program. If I have the time, i'll try to write it today. >> >>But if you search more than 3 plys nominal depth you will have too much data. >> >>regards >>Rafael B. Andrist > >You are right that I cannot follow deep searches of my program by this way but >I believe that there is a lot to learn from shallow searches. > >I also can follow part of the tree at deep search(nodes 500000-501000 when I >need to give also the moves that the program already went forward at node 500000 >that is also easy to do) > >Uri If I understand correctly, you need a sort of width-first notation of a tree that is generated depth-first. That needs to buffer arbitrarily large amounts of data. Either you buffer in core (up to some limited amount, at which point all fails), or you buffer in multiple files, e.g. one for each ply depth. Increment a global counter at each move execution, and tag all moves with their counter in the output file. A separate program then can read all those files simultaneously, and merge the moves according to the wanted sequence. Well... the details a bit complex, so you may want to really build an explicit tree in core, and at the end traverse it in the wanted manner. I agree that visualizing even parts of the search tree can be of great value. In order to limit the amount of data and detail, implement a depth restriction, i.e. trace the top level N plies, where N is passed to the program at startup. 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.