Author: Uri Blass
Date: 07:41:04 04/28/04
Go up one level in this thread
On April 28, 2004 at 09:41:11, Vincent Diepeveen wrote: >On April 27, 2004 at 21:54:49, Uri Blass wrote: > >>On April 27, 2004 at 21:00:22, Vincent Diepeveen wrote: >> >>>On April 27, 2004 at 11:43:36, José Carlos wrote: >>> >>>>On April 27, 2004 at 08:37:34, Tony Werten wrote: >>>> >>>>>On April 27, 2004 at 03:33:26, Bas Hamstra wrote: >>>>> >>>>>>About double nullmove: I tested this in some pawnendgames to see if it could >>>>>>handle zuzwang problems, but I don't see it perform any better than normal >>>>>>nullmove. Can Vincent or you post a position where double null outperforms >>>>>>normal null? I agree the idea is elegant, but I just don't see it work. >>>>> >>>>>I switch it off in pawns only endgames. Couldn't figure out why it wasn't doing >>>>>as well as it sounded. >>>> >>>> I can't think about it now, but I recall this thread where an interesting >>>>discussion about double null move came up: >>>> >>>>http://chessprogramming.org/cccsearch/ccc.php?art_id=241476 >>>> >>>> José C. >>> >>>Christophe wrote that down just to let you guys believe you should search >>>fullwidth. >>> >>>Practical chances of it happening is small, not zero but very close to it. >>>Additionally you can add a single 'if then else' condition in transposition >>>table cutoff to avoid the theoretical scenario that christophe describes. >>> >>>Look the alternative to double nullmove is doing something dead slow like what >>>Gerd is doing, or what i used to do in my draughtsprogram; a verification >>>search, which is just a fullwidth search of n-R ply. So not the later posted in >>>ICGA verification search. Verification search already was excisting in other >>>publications than in the ICGA. So Omid just stole the name kind of for something >>>working crappy :) >> >>No >> >>Omid did not steal the idea. >> >>You simply did not understand Omid's ideas. >>Omid's idea is not mainly to detect zugzwangs but to detect tactics earlier. > >What i refer to is that the original 'verification search' was doing a kind of >fullwidth search as a replacement of nullmove. Omid then later made a >'verification search' which is sometimes doing a 1 ply search near the leafs >depending upon when you try it, full of hashtable bugs. If a search full of bugs work for Omid then maybe they are not bugs but a good decision. > >So there is 2 algorithms called verification search both doing a different thing >but having the same intention. > >Further Omid never has proven his verification search is tactical stronger >because he compared search depths, not search times and he did it with a program >that is so crappy that any modification to the program would be good. > >The stronger programs however have checks efficiently implemented in search and >do not do the dubious forward pruning that Omid is doing with Falcon at his >P3-733Mhz. As far as I know Falcon also has checks in the qsearch. I hope you will see in the next WCCC that it is not weaker than the top programs. > >>Null move pruning means that there are tactics that you need more plies to see >>because of the horizon effect when you cannot detect the threat. >> >>With verified null move pruning you can see it 1 or 2 plies earlier. > >No you are not seeing things 1 or 2 plies earlier. Not at all. You just lose a >ply in search depth to it, that's all. No I do today verified null move pruning only in endgame. I found that there are clearly cases when I find things 1 or 2 plies earlier but it happens more in the endgame relative to the middle game. And it's buggy implementation will cause >you to not profit from it at a crucial time. > >>Doing checks in the qsearch cannot solve the problem because there is tactics >>that is not based on checks. > >Not doing too dubious forward pruning the last so many plies and making an >efficient search with checks in qsearch of course plays even better *and* is >tactical stronger. > >>>Basically all those approaches eat shitload of nodes to say it *very* polite. > >>Basically I see no reason that verification search to detect zugzwangs needs to >>eat many nodes(Omid's idea is not verification search) and common sense tells me >>that if the depth is reduced enough it does not eat many nodes. > >Common sense testing tells us that verification search loses a full ply of >search depth compared to R=3. I think that it is dependent on the program and if I remember correctly based on my experience the loss is less than 1 ply. Of course my program is different and I do not use hash for pruning but I see advantage of not using hash for pruning and the main advantage is that you have more freedom in the evaluation function and I can let myself to have evaluation that is dependent not only on the leaf position. 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.