Computer Chess Club Archives




Subject: Re: Thanks for extracting this!

Author: Uri Blass

Date: 05:53:35 01/01/06

Go up one level in this thread

On January 01, 2006 at 07:46:50, Alessandro Damiani wrote:

>On January 01, 2006 at 06:12:31, Uri Blass wrote:
>>On January 01, 2006 at 05:24:30, Alessandro Damiani wrote:
>>>On January 01, 2006 at 02:36:28, Uri Blass wrote:
>>>>On December 31, 2005 at 20:50:30, Vincent Diepeveen wrote:
>>>>>On December 31, 2005 at 20:20:47, Greg Simpson wrote:
>>>>>>Vasik had very logical and persuave ideas.  I particularly liked the point that
>>>>>>trading one third speed searching for twenty times the evauation per position
>>>>>>almost has to be good if done right.
>>>>>If that describes what he's doing then it seems however Vasik has taken the
>>>>>other way around, the junior way. The utmost minimum of knowledge in leafs.
>>>>I do not understand this comparison.
>>>>Rybka is a slow searcher and Junior is a fast searcher.
>>>>What is the reason that you think that rybka has minimum of knowledge in leafs?
>>>How do you know Rybka is a slow searcher? Just by looking at its obfuscated
>>>nps?? For instance, in
>>>[D]8/8/pppppppK/NBBR1NRp/nbbrqnrP/PPPPPPPk/8/Q7 w - - 0 1
>>>do you really think it takes quite long to find the mate in 1 because of a huge
>>>static analysis? ;)
>>In this case it does not show nodes per second but in the following position
>>it shows nodes per second
>>[D]8/8/pppppppK/NBBRQNRp/nbbrqnrP/PPPPPPPk/8/8 w - - 0 1
>>Analysis by Rybka 1.0 Beta 32-bit:
>>  +-  (2.46)   Depth: 3   00:02:22
>>  +-  (2.46)   Depth: 4   00:03:01
>>1.dxe4 dxe5
>>  +-  (2.46)   Depth: 5   00:05:22
>>1.Qxd4 Qxd5
>>  +-  (2.77)   Depth: 5   00:06:16
>>1.Qxd4 dxc5 2.Qxe4
>>  +-  (3.06)   Depth: 6   00:08:19  4kN
>>1.Qxd4 dxc5 2.Qxe4 Bxd5
>>  +-  (3.06)   Depth: 7   00:12:59  18kN
>>(,  01.01.2006)
>>For some reason it searches only 4000 nodes in 499 seconds.
>>This really seem strange that static analysis takes so much time
>>I could believe 100,000 nodes per seconds on My A3000 and even 10,000 nodes per
>>seconds but less than 10 nodes per second is even too much for me to believe.
>>It seems that Vasik searches many nodes in what he counts as nodes.
>>Maybe he is using different function and not using his normal makemove in the
>>qsearch but it is clear that he searches a lot of legal moves inside of what he
>>considers as evaluation so I cannot consider it as evaluation.
>>I think that static analysis can consider trapped pieces so you can consider
>>some moves without making them to check for trapped pieces but what I see in
>>rybka is clearly too much for what I consider as static analysis.
>>I think that recursive search of moves with more than one move per side cannot
>>be considered as part of the evaluation.
>Exactly. Static analysis is a 0-ply search, search being an operation which uses
>making/unmaking of moves.
>With my previous message I wanted to say this: you cannot imply from low nps
>that an engine is a slow searcher. For instance, by just not counting quiescence
>nodes an engine will have a low nps.

I agree but I do not see a reason not to count qsearch nodes and the author did
not admit that he does not count qsearch nodes and it seems to me based on his
posts that he counts every node in his search so I was surprised to find out
that he does not do it.

I did not want to believe GCP that rybka does not count qsearch nodes because I
assumed that Vasik knows more about rybka and I assume that he does not give
misinformation but it seems that I was wrong and GCP was right.

Not finding the mate fast is no proof for not counting nodes in the qsearch but
the small number of nodes in the next diagram is certainly a proof that the
number of nodes can be very small(less than 10 nodes per second) and searching
less than 10 nodes per second cannot be explained by something that is not
recursive search and not something equivalent to recursive search.


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.