Author: Tony Werten
Date: 06:20:35 08/26/04
Go up one level in this thread
On August 26, 2004 at 08:54:46, Bert van den Bosch wrote: >On August 26, 2004 at 03:01:32, Tony Werten wrote: > >>On August 25, 2004 at 17:37:59, Bert van den Bosch wrote: >> >>>First of all, I hope the forum will continue in some way! >>> >>>Before it is gone, I have a question. >>> >>>I wanted to check my null move so I tested if the null move would create a >>>cutoff, and after that I did the normal stuff. So if you have a cutoff with null >>>moving you are almost sure you will also get a cutoff with the normal proces, >>>except for zugzwangs of course. But this wasn't happening all the time when I >>>tested it, and usually the values involved from what I got back from nullmove >>>and from the normal process were just a few centipawns in difference. Could this >>>be because of search instabillity? If it isn't a bug in my program I had the >>>idea to search nullmove with beta-MARGIN in order for the value returned by null >>>move to bridge the few centipawns gap. And taking MARGIN the few centipawns. But >>>I'm not sure if that is correct. Can someone shine a light on this? >> >>It can and will happen quite often. The basic problem is when you have an >>advantage, wich I will take away from you in a couple of moves. >> >>ie suppose you have rook on the 7th, wich will be attcked by my knight in two >>moves, if you don't move it away I will capture it on the 3rd move. >> >>If a nullmove search reduces depth enough to not let me make this 3rd move, you >>will still get the RookOn7th bonus, wich it would get if you would normaly >>search and do reach my 3rd move. >> >>That's why nullmove hurts positionally (an tacticly). As a compensation, it will >>let you search deeper and improve both tactics and positional. If all is well, >>the improvement should be higher than the loss. >> >>Tony >> >>> >>>Thanks, greetings Bert > >Ok, I spotted some flaws in what I wrote. But I guess it comes down to the >postional tactics loss. So the story is null move is hurting positional play, >couldn't you then take it to the extreme, if a null move doesn't lose material >then you assume your position is ok and return beta? Or if your null move does >lose a bit of tactics but not too much. I think that is what you do when you >search null move with beta-MARGIN. It speeds up my program when I do that but I >am not sure if it is correct. I have played around a bit with this beta+MARGIN a while ago but the result were not very good. The problem with a negative MARGIN was that my program started to play somewhat passively, basicly trying to build fortresses so it could do 1 or 2 passes. It did save a lot of nodes though. With a positive MARGIN, positional play became better, but added a lot of extra nodes. The trick is to find something in between, wich in my program was MARGIN=0 :( What might be interesting (haven't tested it, just came up) is to vary MARGIN with beta. If beta is fe +ROOK then take a positive MARGIN. The idea being that once you're a rook ahead, you're should be making progress. If beta is -ROOK then take a negative margin. Anything that doesn't loose immediately is OK, you need the node reduction to find a tactical trick since that is the only way you are going to survive. Tony > >greetings Bert
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.