Author: Tony Werten
Date: 00:18:55 11/04/02
Go up one level in this thread
On November 03, 2002 at 13:50:41, Uri Blass wrote: >On November 03, 2002 at 13:37:33, Vincent Diepeveen wrote: > >>On November 03, 2002 at 13:07:07, Uri Blass wrote: >> >>>On November 03, 2002 at 11:50:01, Vincent Diepeveen wrote: >>> >>>>On November 03, 2002 at 11:26:42, Brian Kostick wrote: >>>> >>>>for windows there is numega boundschecker. >>>> >>>>for linux there is the excellent free boundschecker (C only) >>>>see for example: http://web.inter.nl.net/hcc/Haj.Ten.Brugge/ >>>> >>>>however you can also go to the homepage from gcc and then go >>>>to 'extensions' and download any boundschecker you need for >>>>use with gcc. it's very good. >>> >>>Thanks >>>I see that I can download a trial version of numega boundchecker so >>>I guess that I am going to try it tomorrow. >>> >>>I use only windows. >>> >>>Note that inspite of the unequal number of nodes in debug mode and in release >>>mode the bug does not seem to prevent it to play well in games. >> >>?? you don't have deterministic number of nodes? >> >>Debug it! > >I have deterministic number of nodes in release mode or in debug mode but the >numbers are not equal. > >The first different number is more than 100000. > >> >>no need for a boundschecker even to debug that. >> >>>The difference is small and I see it only after more than 100000 nodes so maybe >>>the problem is that the random numbers in debug mode are not the same as the >>>random numbers in release mode. >> >>wait a minute. are you telling me that you use the rand() function >>in your program to evaluate? >> >>Comon you gotta be joking? > >Only for my hash tables > >I have >for (fil=0;fil<6;fil++) > for (i=0;i<2;i++) > for (j=0;j<64;j++) > zobrist[fil][i][j]=rand64(); Normally it is possible to feed your rnd function an initialisation seed wich should give you the same "random" numbers all the time. I think it's randomize(seed). Tony > >It may be possible to remember constant numbers and it seems that the numbers >are really constant in release mode but I suspect that they are not the same in >debug and in release mode. > >The easy way to check it is to ask the computer to print the numbers. > > >> >>>The latest tested version solved 292 out of 300 in the Wac test suite at 10 >>>seconds per move on AMD1000 mega hertz and it is now tested on the GCP test >>>suite 300 seconds per position. >> >>DIEP always did 299 positions, depending upon with some patzer luck the >>endgame Rb4 was found or not. >> >>i never test at 10 seconds a move. Only amateurs do IMHO. in real life >>you play tournaments at 90 0 as fastest level. that's like 5 minutes >>first few moves after that your hashtable is loaded already with >>all kind of cool stuff to fail high. At a P5-100Mhz at around 1996 i >>remember i solved like 295 positions or so if not more. Something >>too close to 300 to call is hard :) > >With more time(200 seconds per move) a previous version solved 298 problems. > >The only problem that it did not solve except the Rb4 was problem number 2 >of the Rxb2 but it can solve it with more time. > >Uri
This page took 0.01 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.