ChessUSA.com TalkChess.com
Hosted by Your Move Chess & Games
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Verification search
Post new topic    TalkChess.com Forum Index -> Computer Chess Club: Programming and Technical Discussions Flat
View previous topic :: View next topic  
Author Message
Vincent Diepeveen



Joined: 09 Mar 2006
Posts: 1738
Location: The Netherlands
PostPost subject: Re: Verification search    Posted: Thu Jun 21, 2012 2:47 pm Reply to topic Reply with quote
lucasart wrote:
lucasart wrote:

* the piece precondition: only do a null move when you have at least a piece on the board. Well even that is almost useless. Adding that condition was unmeasurably better (better but below error bar). I kept it anyway, but perhaps it could be further improved, like at least one piece, or not in a king opposition (ie. king dist != 2). Even in K+P endgames, the zugzwang is more an exception than a general problem. And not doing null move misses a lot of good moves that would be found deeper in search, which is to be put in front of the zugzwang improvement.

After some testing, I've come to the conclusion that:

null move precondition
1.1 doing null move all the time is fine
1.2 not doing it when we have no pieces left is very slightly better.
1.3 doing it all the time except if we have no piece left, and the kings are in direct opposition, is very slightly better than 2/
So 3/ is what I do now

verification search
2.1 doing it all the time hurts
2.2 doing it in all positions but only at high depths still improves nothing. it probably hurts but as Robert Hyatt said the overhead is just reduced.
2.3 doing it only when the side to move has no pieces (assuming 1.3 is the precondition) doesn't show an improvement either.
So I am very skeptical about this verif search hype. And I tested in 12+0.2, reaching average depths of 11 in the middle game, so I doubt it becomes useful at long time controls...


If verification search hurts, may i suggest trying double nullmove?

It's less overhead and still detects a few zugzwangs, especially the simple ones, meanwhile hashtables favour you and usually give a cutoff when it ain't a zugzwang anyway.

BTW a reduction factor of 4 for nullmove sounds a tad huge last few plies. is that excluding the additional plydepth?

Normal nullmove is defined as:

nullscore = -search(-beta,-beta+1,depth - R - 1);

So there is an additional '-1' on top of R. Is the R=4 posted here for last few plies including that -1 or excluding; in short is it the total reduction or is it the reduction factor?

The condition of eval >= beta is not new. Most used it already mid 90s.
In Diep i'm doing nothing of that. I always nullmove, i just forbid the 3d consecutive nullmove, which defines double nullmove.

I'm using R=3. Realize that already gets r=4 in too many positions, if you use reductions. Just reducing a search with 5 plies is really a lot.

You typically see most modern engines that get immense search depths that first 20 ply they pick up most things very quick. Moving from 20 to 40 ply is really thin search and hardly adds more understanding to the engines. They still pay to a branching factor of just under 2.0, meanwhile not getting the same elowin one classically would expect winning another ply.

So tricks of 21 ply nominal (just normal alfabeta with check evasion extension and nothing else), they need 30-40 ply to find it, which Diep, Hiarcs and DeepJunior find at 17-21 ply or so. So it's a few minutes for Diep and a minute or 20 for hiarcs and a minute or 21 for DeepJunior, but if you need 40 ply with superthin searching engine you need 24 hours or so. You still pay to some branching factor every iteration to get deeper.

Saying one tested it at bullet levels doesn't impress there, as those depths you don't reach at bullet.

So one should carefully test at slower time controls whether those huge reduction factors that get used at the depths one reaches at slow time controls, that these really work.

If you would for example move up R from 3 to 5 when having a position at depthleft 20, i can understand it, but if you do depth/2 that means a reduction factor of 9, or even 10 in case it's +1.

It's not gonna add elo you know.

You see typically Houdini picks up massive elo by not needing a too extreme search depth there either to find it. It needs a minute or 90 for such positions. Basically what Houdini doesn't find within 3 minutes, it's going to find slower than Diep,Hiarcs,DeepJunior it seems.

Now the evaluation of all those rybka type clones is similar if not the same, so that ain't the difference. If you compare it with Ivanhoe, ivanhoe is 100% the same, yet needs factor 4 more in time to find the same best moves.

The thing where the thin mainline checkers of course really do well is 'avoid moves'. Like the classical Qxb2?? and Qxg2?? in some positions. I do notice that above 20 ply this advantage has gone as well. It's just a blitz advantage there.
Back to top
View user's profile Send private message Send e-mail Visit poster's website MSN Messenger
Display posts from previous:   
Subject Author Date/Time
Verification search Lucas Braesch Thu Jun 14, 2012 1:07 pm
      Re: Verification search Robert Hyatt Thu Jun 14, 2012 1:19 pm
            Re: Verification search Pawel Koziol Thu Jun 14, 2012 2:54 pm
            Re: Verification search Lucas Braesch Fri Jun 15, 2012 4:00 am
                  Re: Verification search Eelco de Groot Fri Jun 15, 2012 12:54 pm
                  Re: Verification search Daniel Homan Fri Jun 15, 2012 3:00 pm
                  Re: Verification search Lucas Braesch Sat Jun 16, 2012 3:18 am
                        Re: Verification search Vincent Diepeveen Thu Jun 21, 2012 2:47 pm
                              Re: Verification search Larry Kaufman Sat Jun 23, 2012 5:06 am
                                    Re: Verification search Vincent Diepeveen Sun Jun 24, 2012 10:32 am
                                          Re: Verification search Larry Kaufman Sun Jun 24, 2012 2:40 pm
                                                Re: Verification search Vincent Diepeveen Tue Jun 26, 2012 10:40 am
                                                      Re: Verification search Don Dailey Tue Jun 26, 2012 11:09 am
                                                            Very minor verification search modification. Eelco de Groot Tue Jun 26, 2012 4:47 pm
                                                                  Re: Very minor verification search modification. Vincent Diepeveen Wed Jun 27, 2012 1:30 am
                  Re: Verification search Vincent Diepeveen Sat Jun 16, 2012 2:58 pm
      Re: Verification search Karlo Bala Jr. Fri Jun 15, 2012 7:30 am
            Re: Verification search Lucas Braesch Fri Jun 15, 2012 11:02 am
                  Re: Verification search Pawel Koziol Fri Jun 15, 2012 12:13 pm
                  Re: Verification search Karlo Bala Jr. Fri Jun 15, 2012 1:58 pm
      Re: Verification search J. Wesley Cleveland Sat Jun 16, 2012 12:12 am
      Re: Verification search Don Dailey Sat Jun 16, 2012 10:32 pm
            Re: Verification search Lucas Braesch Sun Jun 17, 2012 3:13 am
                  Re: Verification search Don Dailey Sun Jun 17, 2012 3:41 am
                  Re: Verification search Miguel A. Ballicora Sun Jun 17, 2012 4:21 am
Post new topic    TalkChess.com Forum Index -> Computer Chess Club: Programming and Technical Discussions

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum




Powered by phpBB © 2001, 2005 phpBB Group
Enhanced with Moby Threads