Author: Uri Blass
Date: 06:54:04 12/04/02
Go up one level in this thread
On December 04, 2002 at 08:57:49, José Carlos wrote: >On December 04, 2002 at 08:38:39, Uri Blass wrote: > >>On December 04, 2002 at 06:56:35, Richard Pijl wrote: >> >>>On December 04, 2002 at 05:22:48, Uri Blass wrote: >>> >>>>On December 04, 2002 at 04:28:15, David Rasmussen wrote: >>>> >>>>>I don't need an external program for that. I test like that already. I test to >>>>>fixed depths, in the case of speed. Because then the speed gain will still be >>>>>visible, and the node count and all other things not dependant on time, should >>>>>be exactly the same. >>>>> >>>>>/David >>>> >>>>You are right that testing for fixed depth for that purpose is simpler but >>>>EPD2WB has not an option to test for fixed depth and I did not care to develop a >>>>special program to analyze epd files after the existence of EPD2WB >>> >>>It should be very easy for you to add a command to Movei to search a small >>>number of positions to a fixed depth and then provide statistics on the results. >>>That's what I've done in the Baron (command is 'bench'). >>>It just seems much simpler than developing and using an external test program >>>... >>> >>>Richard. >> >>I agree that it is simpler than developing an external program. >>I do not agree that it is simpler than using an external program. >> >>Until today I did not develop a function to read epd files because I used an >>external function for that job(EPD2WB). >> >>Uri > > You don't need to read an epd file for that. Just write a function where you >set a fen position (directly in code) and search for fixed depth. Then count >nodes, fail high nodes, hash table hits, ... whatever you want to compare to >make sure the tree is exactly the same. And of course, measure total time. >Repeat the process for n positions (I do n = 10) and write the results to a text >file (or just print them). You can implement that in 1 hour, and it'll be >helpful forever. > > José C. I have a function to read Fen so if I want to use small number of positions there is no problem. I compare nodes count for specific positions as a first test to see if I have no bugs. comparing nodes count is done manually(usually if the number of nodes is the same there is no new bug that is relevant to the position that was searched). The point is that after I do a lot of small changes then I want to check it on a big test suite when the program runs for hours so I practically use a big test suite and not 1 position or 10 positions. I think also that fixed depth test is not enough. I say it because of something that I discovered now. It is important to do a test that proves that the number of nodes in one position is not dependent on the previous analysis I found that it is exactly what happened to latest movei and it is not supposed to happen(the analysis in game is supposed to be dependent on the order of pieces in my array but when I setup position the array is dependent only on the FEN). 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.