Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: One mate to solve...

Author: leonid

Date: 19:25:58 04/22/01

Go up one level in this thread


On April 22, 2001 at 19:22:43, Heiner Marxen wrote:

>On April 22, 2001 at 18:30:53, leonid wrote:
>
>
>>What surpised me very much (just few days ago) is to find that in my mate solver
>>selective demonstrate much higher NPS that brute force search. It is true that
>>it is not that relevant for the quality of the search but is very curious. I
>>never expected this way! In other part of my program opposit is true. Selective
>>search have always lower NPS that brute force search. Specific to my program
>>logic or normal for every program? I really don't know.
>>
>>Leonid.
>
>Hi,
>
>I have never measured it, but yes, that is a surprise at first.
>The logical rasoning is like this:
>
>The two versions of the program (selective and brute force) do nearly the same:
>spanning/searching a tree by move generator and move execution, and evaluating
>the leaves for mate.  The selective version also does some selection decision.
>
>Therefore the selective version would have a somewhat smaller NPS, if the
>execution of common components (generator, execution and leave evaluation)
>would have the same average execution time for both versions.
>Since the NPS is greater, it follows that the common components execute
>faster on average in the selective tree.
>
>How is that possible?
>
>Move execution should have nearly constant execution time.
>But move generation and leave evaluation (also tests for move legality,
>which are contained somewhere in there) are faster for less crowded boards.


In my program all moves are usually generated (exception two plys) for each ply.
For one position [never mind how many nodes (moves) it contain] the same amount
of data is generated in order of verifying legality of moves. So, less moves are
used in selective search, between many generated, I can expect only less
efficency on my code will go down. With this my NPS.


>Bingo!  Those selected moves will be check moves and captures more frequently
>than in the brute force version.  (NPS should also be higher for endgames)
>
>Surprise solved.  Those search trees are sometimes hard to understand ;-)
>
>Heiner

Heiner, here are something that is not that simple and reason for saying so is
that difference between selective search and brute force search for mate should
be more or less the same as for material search. At least, in my program those
both parts share 60% of identical code and procedures. But just before going
here, I went once again to see above position on Rebel 10. Before, when search
was done by brute force and for mate (5 moves deep) its NPS was 472k, as
average. When I looked his NPS for usual game, 10 plys deep (brute force, hash
diconnected) its NPS was 196k. So, why his NPS is now almost twice as low
compared with its NPS for same position when it look for mate?

 My program say something different. 182k as average - searching mate 5 moves
deep. 451k - search for move in usual game (usual - for material advantage) 10
plys deep by brute force. 182k against 451k.

 Rebel's numbers puzzle me for a reason. His branching factor for brute force
search in the game (not for mate) is so good that I expected that maybe he is
cheating and do selective search when it anounce brute force. When it is not the
search for mate, it is never visible who do real brute force search and who not.
Only in search for mate it is 100% certain. But possibily that Rebel do
selective search, where it should search by brute force, come in complet
contradition of what I found in my program. In mine it is selective search (at
least for mate) that give higher NPS that selective. And difference for my
program is big! Between 2 and 8 times.

Usual NPS in mine, for mate, by brute force is between 40 and 90k. Selective for
mate, between 300k and 600k

Cheers,
Leonid.




This page took 0.03 seconds to execute

Last modified: Thu, 07 Jul 11 08:48:38 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.