Author: Uri Blass
Date: 10:50:41 11/03/02
Go up one level in this thread
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(); 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.