Sentinels in UCI

[BB+]

From the bottom of this post:

Furthermore the pre-Rybka 1.16.1 contains on 18 occasions an odd kind of flag with the value "0x7fffffff" also one in the UCI time control.

This is a misrepresentation. The token 0x7fffffff appears 18 times in Rybka 1.6.1, but whether or not each is a "flag" is a different question.

Code: Select all

$ grep 0x7fffffff R16.code
0x0044497b:cmp    $0x7fffffff,%eax
0x00444998:movl   $0x7fffffff,0x6b8da0
0x00444a1f:cmp    $0x7fffffff,%eax
0x00444a4c:movl   $0x7fffffff,0x6b8da4
0x00444a6d:mov    $0x7fffffff,%eax
0x00452472:mov    $0x7fffffff,%edx
0x0045250c:cmp    $0x7fffffff,%eax
0x00452519:movl   $0x7fffffff,(%ecx)
0x0045251f:movl   $0x7fffffff,0x4(%ecx)
0x0045263a:mov    $0x7fffffff,%edx
0x00452824:mov    $0x7fffffff,%edx
0x0045f592:movl   $0x7fffffff,-0x1c(%ebp)
0x0045f5eb:movl   $0x7fffffff,-0x1c(%ebp)
0x0045f7e1:add    $0x7fffffff,%ecx
0x0045f7f9:add    $0x7fffffff,%ecx
0x0045f80f:test   $0x7fffffff,%edx
0x0046018b:mov    $0x7fffffff,%ecx
0x00465dcf:mov    $0x7fffffff,%edx

The first 5 occurrences occur in the UCI parsing. The first two have to do with parsing "nodes", the next two with "movetime", and the last with "infinite". (Cf. this concerning the token orderings). In other words, none has to do with "depth", as Schröder seems to imply later.

Checking Rybka 1.0 beta for "0x7fffffff" the value only appears 2 times, one again in the UCI time control. The evidence is presented here, a more detailed explanation here.

The "here" links did not show up. Furthermore, by the previous "18" accounting, I get many more than 2 in Rybka 1.0 w32.

Code: Select all

$ grep 0x7fffffff R1w32.code
0x00409555:movl   $0x7fffffff,0x667a20
0x0040b1d9:mov    $0x7fffffff,%eax
0x0040bfae:mov    $0x7fffffff,%ecx
0x00410fc2:mov    $0x7fffffff,%esi
0x00411c7c:mov    $0x7fffffff,%ecx
0x00415979:cmp    $0x7fffffff,%edi
0x00418e31:andl   $0x7fffffff,-0x20(%ebp)
0x00419373:andl   $0x7fffffff,-0x20(%ebp)
0x00419889:testl  $0x7fffffff,-0x34(%ebp)
0x004198af:testl  $0x7fffffff,0x8(%ebx)
0x00419d78:testl  $0x7fffffff,-0x18(%ebp)
0x00419d9d:testl  $0x7fffffff,0x8(%edx)
0x00419fe1:testl  $0x7fffffff,-0x18(%ebp)
0x0041a003:testl  $0x7fffffff,-0x28(%ebp)

Only one of these appears in UCI parsing or time control mechanics (the first). The next two have to do with things like max values in a hash entry, and ensuring captures will have a maximal value in move ordering.

As "0x7fffffff" is not found in Crafty or Fruit it's safe to conclude Vas wrote his own time control and the accusation Vas copied Fruit's time control, converted float to int to hide the Fruit origin is pretty much debunked.

I don't think it is "safe" to do this. And "depth" is not exactly a "time control" issue, as it were. As has become typical: find one difference (no matter how minor), then claim that everything must be original.

For instance, one can note that Rybka 1.0 initialises time_limit_1 and time_limit_2 as 0xffffffff (that is, -1) in its UCI/timing code (as per Fruit 2.1), while these do not appear in Rybka 1.6.1. Furthermore, the nodes/movetime sentinels that were in Rybka 1.6.1 disappeared in Rybka 1.0. The 0x7fffffff is treated as a depth holder in Rybka 1.0 UCI. I am just making a speculation, but one reason that this might be used (rather than -1, as Fruit uses) is that Rybka obfuscates its depth by 2, and such a perturbation could cause problems with comparison.

I find Mr. Schröder's interpretation of the above to be dubious; he seems to jump to pre-ordained conclusions, without fulling understanding the whole. And I'm not sure why arguing about UCI/timing code is that relevant anyway.

As an aside, his declaration of the Rybka source code (where Dutch does not demand such a definite article) is loony, particularly as his HexRays dump has 5 errors (the 4 move generators and SEE), and omits loc_40C180 (called FullSearch by Fadden).