Author: Bert van den Bosch
Date: 07:33:13 08/26/04
Go up one level in this thread
On August 26, 2004 at 09:20:35, Tony Werten wrote: >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 Yes I had the same experience, negative margin was bad tactics positive too slow. But as you say maybe there are some special cases where you can apply some margin. Should test it... 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.