Author: Vincent Diepeveen
Date: 08:42:00 11/15/99
Go up one level in this thread
On November 15, 1999 at 09:45:49, Bas Hamstra wrote: >On November 15, 1999 at 07:29:16, Vincent Diepeveen wrote: > >>On November 14, 1999 at 22:58:19, James Robertson wrote: >> >>>On November 14, 1999 at 22:16:33, Will Singleton wrote: >>> >>>>On November 14, 1999 at 21:45:26, William Bryant wrote: >>>> >>>>>I recently found that my null threashold is set to low, and I am experimenting >>>>>with different level. >>>>> >>>>>I am curious what other people have found works for them. >>>>> >>>>>Do you count pieces or pieces and pawns? >>>>> >>>>>How may pieces or pieces and pawns must be present for the side on move >>>>>to allow a null move? >>>>> >>>>>Thanks in advance. >>>>> >>>>>William >>>>>wbryant@ix.netcom.com >>>> >>>>I originally had a threshold of around 3 pieces per side, but now I allow >>>>endgames as long as someone has a piece. This is further modified by a >>>>blocked-pawn term, which disallows null if most pawns are blocked. I think. >>>>So, I don't detect zug like some others attempt to do. >>>> >>>>I only use R=2, but I know others alternate between 2 and 3 depending on the >>>>situation. >>>> >>>>Will >>> >>>What are the advantages/disadvantages of alternating between R=2/3? Does having >>>some entries with R=3 cause problems with the hash table? >> >>The difference between R=2 and R=3 is marginally, however for DIEP >>R=2 needs a lot more nodes than R=3. >> >>Something interesting though is what happens the last few ply. >> >>At R=2 you are tempted prune the last 3 ply with quiescencesearch. >> >>At R=3 you are doing the last 4 ply, which means that you prune >>2 moves of your opponent. >> >>For some programs that don't detect much in qsearch this might be >>a problem. >> >>Everyone has to figure out whether R=2 is better for him or whether >>he can do R=3 too. >> >>Some alternatives is using a combination: first nullmove R=3 and >>all nullmoves after the first one R=2. >> >>I am no longer doing that though. I use everywhere R=3 now. >>Bad luck for a few positions in LCT test and bs2830 testset! >> >>Obviously a nullmoving program with R=3 needs 3 ply more than >>with R=2 to find Kh2-g3!! >> >>I guess everyone has to figure out his own reduction based upon >>node reduction. If R=3 gives you a time reduction of 50%, then >>i bet it's a good idea to use R=3 instead of R=2 ! >> >>>James >> >>Vincent > >I have seen a few cases where R=3 used more nodes than R=2 to reach a given >depth. First iterations R=3 did better than R=2 (less nodes), but suddenly it >chokes and on the end used even more nodes than R=3. > >Since that I gave up on R=3. However R=3 near the root and R=2 the rest works >fine for me. I don't see the "choking problem". This is the same discussion as whether bigger hashtables work better or worse than small hashtables. Sure the more bugs in a program the worse it might work. Obviously R=3 gives a bigger reduction so at the bigger depths it is not obvious to me that at smaller depths it reduces nodes so bigtime. It improves the branching factor for me! > >Regards, >Bas Hamstra.
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.