Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Fairly good examples of eval inconsistencies between Rybka versions...

Author: Uri Blass

Date: 04:14:02 01/03/06

Go up one level in this thread


On January 03, 2006 at 06:40:13, Uri Blass wrote:

>On January 03, 2006 at 06:16:29, Vasik Rajlich wrote:
>
>>On January 02, 2006 at 19:09:12, enrico carrisco wrote:
>>
>>>On January 02, 2006 at 04:26:55, Vasik Rajlich wrote:
>>>
>>>>On January 01, 2006 at 17:06:43, enrico carrisco wrote:
>>>>
>>>>>I stated here in CCC days after Rybka was released that the nps was manipulated
>>>>>but lacked any real convincing examples of this.  I even ran the idea by Chrilly
>>>>>when he was disassembing Rybka, but he had no comment on it.
>>>>>
>>>>>In the following position, we see two different evaluations for Rybka 1.0 Beta
>>>>>64-bit and Rybka 1.01 Preview 2 64-bit.  Of course, without knowing what
>>>>>undocumented changes (if any) were made from 1.0 Beta to Preview 2, it's hard to
>>>>>deduce anything concrete.  However, Vasik has posted here a few times that
>>>>>nothing was changed with the strength or eval (I believe...  Not trying to quote
>>>>>anything...)
>>>>>
>>>>>Specifically, the time-to-ply figures are odd.  Preview 2 appears to slow down
>>>>>in time to ply while Rybka 1.0 Beta seems to 'speed up' as the depth increases
>>>>>(from nps figures.)
>>>>>
>>>>>The second position, below, shows the differences in nps better -- where the
>>>>>qsearch demands a little recognition...  :)  Time-to-ply is very close (unlike
>>>>>the first position) but the nps differs substantially...
>>>>>
>>>>
>>>>Enrico,
>>>>
>>>>I already explained this here - did you really miss it?
>>>
>>>Hello Vas.  Yes, I am afraid I did miss it.  Do you have a link to the message?
>>>I notice from Uri's reply to this thread it seems you posted something about
>>>changing Rybka's node count..  Is this correct?  I would be interested to read
>>>your posting on this.
>>>
>>>>
>>>>If you don't mind, I have two nosy questions for you:
>>>>
>>>>1) What is the Hiarcs definition of node?
>>>
>>>I'm not clear on what you're asking here with your inclusion of HIARCS.  Our
>>>definition does not differ from the general definition of a node (any move made
>>>by the program in its "thinking" - i.e. updating a data structure.)
>>>
>>>Perhaps I am missing some sarcasm?
>>>
>>>>2) Do you have access to the Hiarcs sources?
>>>
>>>Again -- I'm not sure how this relates in the matter of my original question.
>>>It is well known that Mark is the programmer of HIARCS.  If my activities
>>>included programming, I would be listed as a co-author.
>>>
>>>If the inference is that without a programming contribution to HIARCS my
>>>knowledge or input on such a matter is discounted -- please just say so.
>>>
>>>However, I believe there are many knowledgeable programmers in this forum that
>>>do not have a top 10 (or even 20) engine.
>>>
>>>If I've struck a nerve with you, it was not my intention.  I just wanted to know
>>>why the positions I posted gave varied eval by Rybka versions.  I would have
>>>assumed other posts in this thread which make very direct inferences to Rybka's
>>>roots would have been more worthy of any sarcastic retort than my inquiry.
>>>
>>>Regards,
>>>
>>>-elc.
>>>
>>
>>Hi Enrico,
>>
>>actually, I wasn't being sarcastic. It's just that I don't want to explain what
>>exactly I do which doesn't leave much else to say :)
>>
>>The reason for my questions is that I suspect that Hiarcs is doing something
>>similar to Rybka. The per-node tactical strength of Hiarcs is phenomenal. It
>>would be interesting to compare notes although in practice this is unlikely to
>>happen. (It's already unlikely that I find out who actually looks at the Hiarcs
>>sources :))
>>
>>Re. Rybka Beta vs Rybka Preview 1.01, I changed Rybka's node-counting to give
>>partial credit for "extra work done inside a node". This was done to stabilize
>>the nps figure as in Rybka Beta it can fluctuate wildly. Uri was quite
>>displeased with this change :)
>
>The extra work that is done inside a node probably include recursive search of
>captures based on my observations(otherwise rybka could search more nodes per
>second in positions that have many captures in the root).
>
>100,000 nodes per seconds on a fast hardware make sense but not less than 10
>nodes per second.
>
>Uri

In other words I believe that rybka is searching because I see nothing logical
that it can do except searching that takes so much time in complex positions.

evaluation can take different time in different positions but there are no cases
when it takes more than 1/10 second and it does not make sense to believe that
other things that are not making moves takes so much time.

originally I was not happy with giving partial credit for "extra work done
inside a node" but after I understand that the extra work has to be search I
have no problem with it.

Uri



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.