Questions for Vas

[Zach Wegner]

EDIT: please keep this thread clean. I'd like to only have specific questions about low level similarities between Rybka and Fruit, and possibly answers from Vas. No need to start another flamewar here.

Vas,

You agreed to answer any questions about similarities between Rybka 1.0 and Fruit. I am glad that you have agreed to do such, and I hope you take the time to answer each of the concerns that I and others have.

This list of similarities between Rybka 1.0 and Fruit was compiled in the past day or so. It's by no means complete, and there are other issues that I've found that I haven't totally verified yet. Each item in this list may be a small similarity that other engines also have, but the idea is to show how many of them are. At some point it will have to be decided whether it all is just a coincidence or not. For those that ask for proof, I'm going to try to set up a web page with snippets of disassembly compared to the Fruit code for each claim made here. Any assistance that anyone has in doing this would be greatly appreciated. It would also help to point out low-level similarities between Strelka and Fruit. These would be verified against Rybka 1.0 by myself or someone else before posting.

I will add, Vas, that some have questioned our motives in presenting these questions. I believe that Rybka started its life as Fruit. I don't wish that you stop. You have obviously done some amazing things with Rybka, and I want them to continue just for the sake of advancement. I just want everyone to play by the rules. If you started with Fruit, there's no problem with that, you just need to be forthcoming about it and abide by the license. I'm not even interested in the legal aspect of all this, that would be for others to handle if necessary.

COMMAND INTERPRETER:
--The UCI 'go' parser is virtually identical (as shown by Rick Fadden), including the time control code

SEARCH:
--Does not use fractional extensions
--In the root function, for initializing the search, the order of steps is:
Generate legal moves
Setjmp
Limit depth if num_moves == 1 to 4
Increment hash age
Reset killers
Reset history
Look up hash move
Score and sort moves
--Use identical easy move logic: if (depth == 1 && best_score > second_best + 150) easy=true;
--both use flags in the root function bad_1 and bad_2

EVAL:
--Piece square tables are of the form [12][64][2], where the last entry is game stage

TRANS:
--Stores both a minimum and maximum bound in the hash table, and depths for both
--Stores only 32 bits of the hash key
--Stores a quantity called "move depth"
--For the replacement scheme, a value is calculated that is trans_age[entry] - depth, where trans_age contains the difference of the current date and the entry's date mod DateSize (4 in Rybka, 16 in Fruit). This is multiplied by 256. In Rybka, the table has the values already multiplied by 256, and in Fruit, it is multiplied on the fly.
--Both use a bucket system with 4 entries

BOARD REPRESENTATION:
--Uses an "undo_t" to store moves that it made, which are only kept on the system stack, not in regular memory.
--Only game history stored is a stack of hashkeys
--The index of this game history is stored as an int, not a pointer
--Two values, "opening" and "endgame" are stored in the board, containing sums of piece square tables
--The masks for hashing castling status are WK=1, WQ=2, BK=4, BQ=8
--For hashing of castling status, the hashkey is updated by CastleHash[oldflags ^ newflags], rather than the more natural CastleHash[oldflags] ^ CastleHash[newflags]
--Both have separate make_null and undo_null functions

[chrisw]

Please respect Zach's request to be allowed to work up his case here.

[Alexander Schmidt]

I am not sure why we ask this questions, it's like if we ask Lance Armstrong if he used doping during his career.

Nevertheless, here are my questions

1. Where do the similaries in the engineoutput come from? There are several characteristic that can only be found in Fruit and Rybka. Rybka 1.6.1 had a completely different output. (See below)

2. Why does Rybka 1.0 Beta see an advantage for white in this position?
FEN: 8/1k6/1b6/8/8/8/1K6/8 b - - 0 1

Rybka 1.0 Beta 32-bit:

Code: Select all

   3	00:00	         619	633.856	-0,03	Lb6g1
   3	00:00	         961	984.064	+0,03	Lb6d4+
   4	00:00	       4.687	4.799.488	 0,00	Lb6d4+ Kb2b1
   4	00:00	       5.078	5.199.872	+0,03	Lb6g1
   5	00:00	       8.662	8.869.888	-0,03	Lb6g1 Kb2b3
   5	00:00	      12.665	12.968.960	+0,03	Lb6d4+ Kb2b1 Ld4b2
   6	00:00	      34.895	1.116.640	 0,00	Lb6d4+ Kb2b1 Ld4b2 Kb1a2
   6	00:00	      35.819	1.146.208	+0,03	Lb6g1 Kb2b3 Kb7a6
   7	00:00	      52.054	1.110.485	-0,03	Lb6g1 Kb2c2 Kb7a6 Kc2d1
   7	00:00	      57.374	1.223.978	+0,03	Lb6d4+ Kb2b1 Ld4b2 Kb1a2 b2a1
   8	00:00	      93.754	1.215.241	+0,03	Lb6d4+ Kb2b1 Ld4b2 Kb1a2 Lb2a1 Ka2b1 Kb7c6
   9	00:00	     109.470	1.418.952	+0,03	Lb6d4+ Kb2b1 Ld4b2 Kb1a2 Lb2a1 Ka2b1 Kb7c6
  10	00:00	     129.394	1.394.731	+0,03	Lb6d4+ Kb2b1 Kb7c6 Kb1a2 Ld4a1 Ka2b1 Kc6b6 Kb1a2
  11	00:00	     159.176	1.293.620	+0,03	Lb6d4+ Kb2b1 Kb7c6 Kb1a2 Ld4a1 Ka2b1 Kc6b6 Kb1a2 Kb6c7 Ka2b1
  12	00:00	     188.274	1.227.978	+0,03	Lb6d4+ Kb2b1 Kb7c6 Kb1a2 Ld4a1 Ka2b1 Kc6b6 Kb1a2 Kb6c7 Ka2b1
  13	00:00	     248.911	1.249.435	+0,03	Lb6d4+ Kb2b1 Kb7c6 Kb1a2 Ld4a1 Ka2b1 Kc6b6 Kb1a2 Kb6c7 Ka2b1
  14	00:00	     313.246	1.277.943	+0,03	Lb6d4+ Kb2b1 Kb7c6 Kb1a2 Ld4a1 Ka2b1 Kc6b6 Kb1a2 Kb6c7 Ka2b1
  15	00:00	     515.770	1.467.079	+0,03	Lb6d4+ Kb2b1 Kb7c6 Kb1a2 Ld4a1 Ka2b1 Kc6b6 Kb1a2 Kb6c7 Ka2b1
  16	00:00	     592.044	1.433.222	+0,03	Lb6d4+ Kb2b1 Kb7c6 Kb1a2 Ld4a1 Ka2b1 Kc6b6 Kb1a2 Kb6c7 Ka2b1
  17	00:00	     694.167	1.418.816	+0,03	Lb6d4+ Kb2b1 Kb7c6 Kb1a2 Ld4a1 Ka2b1 Kc6b6 Kb1a2 Kb6c7 Ka2b1
  18	00:01	     802.923	1.381.837	+0,03	Lb6d4+ Kb2b1 Kb7c6 Kb1a2 Ld4a1 Ka2b1 Kc6b6 Kb1a2 Kb6c7 Ka2b1
  19	00:01	   1.197.910	1.375.179	+0,03	Lb6d4+ Kb2b1 Kb7c6 Kb1a2 Ld4a1 Ka2b1 Kc6b6 Kb1a2 Kb6c7 Ka2b1
  20	00:01	   1.469.854	1.415.927	+0,03	Lb6d4+ Kb2b1 Kb7c6 Kb1a2 Ld4a1 Ka2b1 Kc6b6 Kb1a2 Kb6c7 Ka2b1
  21	00:01	   2.159.069	1.488.812	+0,03	Lb6d4+ Kb2b1 Kb7c6 Kb1a2 Ld4a1 Ka2b1 Kc6b6 Kb1a2 Kb6c7 Ka2b1

What I wrote about the similaries:

An UCI engine is free in how and when sending it's info strings, thisresults in very different output of all the engines, just like some kind of fingerprint. Many engines have a quite similar output with all infos in one line, Fruits is very unique.

The position of the info strings for every depth in Fruit are:

depth
depth - seldepth - score cp - time - nodes - pv
depth - seldepth - time - nodes - nps

Later it looks like this:

currmove - currmovenumber 19
currmove - currmovenumber 20
depth (x) - seldepth - time - nodes nps
depth (x+1)
currmove - currmovenumber 1
time - nodes - nps - cpuload
hashfull
depth (x+1) seldepth - score cp - time - nodes - pv
currmove - currmovenumber 2
currmove - currmovenumber 3

Fruit 2.1

Code: Select all

80500<1&#58;info depth 3
80500<1&#58;info depth 3 seldepth 3 score cp 54 time 0 nodes 148 pv b1c3 b8c6 g1f3
80500<1&#58;info depth 3 seldepth 3 time 0 nodes 186 nps 0
80500<1&#58;info depth 4
80500<1&#58;info depth 4 seldepth 6 score cp 0 time 0 nodes 300 pv b1c3 b8c6 g1f3 g8f6
80500<1&#58;info depth 4 seldepth 6 time 0 nodes 976 nps 0
80500<1&#58;info depth 5
80500<1&#58;info depth 5 seldepth 9 score cp 48 time 0 nodes 1729 pv b1c3 b8c6 g1f3 g8f6 d2d4
8050<1&#58;info depth 5 seldepth 9 time 0 nodes 1933 nps 0
80500<1&#58;info depth 6
80500<1&#58;info depth 6 seldepth 12 score cp 0 time 0 nodes 3331 pv b1c3 b8c6 g1f3 g8f6 d2d4 d7d5
80500<1&#58;info depth 6 seldepth 12 time 0 nodes 9447 nps 0
80500<1&#58;info depth 7
80516<1&#58;info depth 7 seldepth 14 score cp 42 time 16 nodes 15332 pv b1c3 b8c6 g1f3 g8f6 d2d4 d7d5 c1f4
80516<1&#58;info depth 7 seldepth 14 time 16 nodes 16243 nps 0
80516<1&#58;info depth 8
80547<1&#58;info depth 8 seldepth 17 score cp 0 time 47 nodes 35078 pv b1c3 g8f6 g1f3 b8c6 d2d4 d7d5 c1f4 c8f5
80594<1&#58;info depth 8 seldepth 20 time 94 nodes 72286 nps 0
80594<1&#58;info depth 9
80657<1&#58;info depth 9 seldepth 20 score cp 15 time 157 nodes 125215 pv b1c3 g8f6 g1f3 b8c6 d2d4 d7d5 d1d3 c6b4 d3b5 b4c6
80688<1&#58;info depth 9 seldepth 21 time 188 nodes 151298 nps 0
80688<1&#58;info depth 10
80907<1&#58;info depth 10 seldepth 22 score cp 12 time 407 nodes 330356 pv b1c3 d7d5 d2d4 c8f5 g1f3 g8f6 f3h4 f5g4 h2h3 g4d7
81032<1&#58;info depth 10 seldepth 22 score cp 15 time 532 nodes 427686 pv g1f3 b8c6 d2d4 d7d5 b1c3 g8f6 d1d3 g7g6 c1f4 c8f5
81125<1&#58;info depth 10 seldepth 24 time 625 nodes 504717 nps 0
81125<1&#58;info depth 11
81500<1&#58;info time 1000 nodes 800000 nps 800000 cpuload 1000
81500<1&#58;info hashfull 18
81578<1&#58;info depth 11 seldepth 24 score cp 23 time 1078 nodes 861114 pv g1f3 b8c6 b1c3 g8f6 e2e3 d7d5 f1b5 c8g4 h2h3 g4f5 e1g1
81578<1&#58;info currmove b1c3 currmovenumber 2
81625<1&#58;info currmove d2d4 currmovenumber 3
81657<1&#58;info currmove e2e4 currmovenumber 4
81719<1&#58;info currmove d2d3 currmovenumber 5
81735<1&#58;info currmove e2e3 currmovenumber 6
81735<1&#58;info currmove b1a3 currmovenumber 7
81750<1&#58;info currmove g1h3 currmovenumber 8
81766<1&#58;info currmove b2b3 currmovenumber 9
81766<1&#58;info currmove b2b4 currmovenumber 10
81766<1&#58;info currmove g2g3 currmovenumber 11
81782<1&#58;info currmove g2g4 currmovenumber 12
81782<1&#58;info currmove a2a4 currmovenumber 13
81797<1&#58;info currmove h2h4 currmovenumber 14
81797<1&#58;info currmove c2c4 currmovenumber 15
81797<1&#58;info currmove f2f4 currmovenumber 16
81797<1&#58;info currmove c2c3 currmovenumber 17
81797<1&#58;info currmove a2a3 currmovenumber 18
81797<1&#58;info currmove h2h3 currmovenumber 19
81813<1&#58;info currmove f2f3 currmovenumber 20
81813<1&#58;info depth 11 seldepth 24 time 1313 nodes 1036135 nps 789136
81813<1&#58;info depth 12
81813<1&#58;info currmove g1f3 currmovenumber 1
82500<1&#58;info time 2000 nodes 1570000 nps 785000 cpuload 1000
82500<1&#58;info hashfull 34
82641<1&#58;info depth 12 seldepth 28 score cp 10 time 2141 nodes 1684642 pv g1f3 b8c6 b1c3 g8f6 d2d4 d7d5 f3e5 c8f5 e5c6 b7c6 c1f4 a8b8 b2b3
82641<1&#58;info currmove b1c3 currmovenumber 2
82969<1&#58;info currmove d2d4 currmovenumber 3

And now to Rybka 1.0 Beta.

The position of the info strings for every depth is:

depth
depth - score cp - time - nodes - nps - pv
depth - time - nodes - nps

Remember Fruit:

depth
depth - seldepth - score cp - time - nodes - pv

depth - seldepth - time - nodes - nps

The only difference is Rybka don't give seldepth infos and has added nps in 2nd line.

And later the output changes to this:

currmove - currmovenumber 19
currmove - currmovenumber 20
depth (x)- time - nodes - nps
depth (x+1)
currmove - currmovenumber 1
depth (x+1) - score cp - time - nodes - nps - pv -
currmove - currmovenumber 2
currmove - currmovenumber 3

Remember Fruit:

currmove - currmovenumber 19
currmove - currmovenumber 20
depth (x) - seldepth - time - nodes nps
depth (+1)
currmove - currmovenumber 1
time - nodes - nps - cpuload
hashfull
depth (+1) - seldepth - score cp - time - nodes - pv
currmove - currmovenumber 2
currmove - currmovenumber 3

Again nearly the same with some missing info strings in Rybka.

Code: Select all

181938<1&#58;info depth 3
181938<1&#58;info depth 3 score cp 7 time 1 nodes 235 nps 240640 pv b1c3
181938<1&#58;info depth 3 time 1 nodes 328 nps 335872
181938<1&#58;info depth 4
181938<1&#58;info depth 4 score cp 3 time 1 nodes 491 nps 502784 pv b1c3
181938<1&#58;info depth 4 time 1 nodes 826 nps 845824
181938<1&#58;info depth 5
181938<1&#58;info depth 5 score cp 8 time 1 nodes 1117 nps 1143808 pv b1c3 b8c6
181938<1&#58;info depth 5 time 1 nodes 1352 nps 1384448
181938<1&#58;info depth 6
181953<1&#58;info depth 6 score cp 3 time 16 nodes 1913 nps 122432 pv b1c3 b8c6 g1f3
181953<1&#58;info depth 6 time 16 nodes 4005 nps 256320
181953<1&#58;info depth 7
181985<1&#58;info depth 7 score cp 5 time 32 nodes 6216 nps 198912 pv b1c3 b8c6 g1f3 g8f6
182000<1&#58;info depth 7 time 63 nodes 9565 nps 155469
182000<1&#58;info depth 8
182032<1&#58;info depth 8 score cp 7 time 79 nodes 14615 nps 189440 pv b1c3 b8c6 g1f3 g8f6 d2d4
182047<1&#58;info depth 8 time 110 nodes 19009 nps 176956
182047<1&#58;info depth 9
182266<1&#58;info depth 9 score cp 5 time 329 nodes 47418 nps 147586 pv b1c3 g8f6 d2d4 d7d5 c1f4 c8f5
182328<1&#58;info depth 9 time 391 nodes 57842 nps 151483
182328<1&#58;info depth 10
182657<1&#58;info depth 10 score cp 3 time 720 nodes 93647 nps 133186 pv b1c3 g8f6 d2d4 d7d5 g1f3 b8c6 d1d3
182657<1&#58;info currmove b1a3 currmovenumber 2
182672<1&#58;info currmove d2d3 currmovenumber 3
182688<1&#58;info currmove d2d4 currmovenumber 4
182719<1&#58;info currmove b2b3 currmovenumber 5
182735<1&#58;info currmove a2a3 currmovenumber 6
182735<1&#58;info currmove a2a4 currmovenumber 7
182750<1&#58;info currmove b2b4 currmovenumber 8
182782<1&#58;info currmove c2c4 currmovenumber 9
182782<1&#58;info currmove c2c3 currmovenumber 10
182797<1&#58;info currmove e2e4 currmovenumber 11
182813<1&#58;info currmove e2e3 currmovenumber 12
182828<1&#58;info currmove f2f4 currmovenumber 13
182828<1&#58;info currmove f2f3 currmovenumber 14
182828<1&#58;info currmove g2g4 currmovenumber 15
182844<1&#58;info currmove g2g3 currmovenumber 16
182844<1&#58;info currmove h2h4 currmovenumber 17
182875<1&#58;info currmove h2h3 currmovenumber 18
182875<1&#58;info currmove g1f3 currmovenumber 19
182875<1&#58;info currmove g1h3 currmovenumber 20
182891<1&#58;info depth 10 time 938 nodes 128456 nps 140233
182891<1&#58;info depth 11
182891<1&#58;info currmove b1c3 currmovenumber 1
184094<1&#58;info depth 11 score cp 7 time 2157 nodes 268104 nps 127277 pv b1c3 g8f6 d2d4 d7d5 g1f3 b8c6 e2e3 d8d6
184110<1&#58;info currmove b1a3 currmovenumber 2
184110<1&#58;info currmove d2d3 currmovenumber 3

OK, at last an output of a completely different engine, if I remember right, it was Rybka 1.6.1, last private version before Rybka 1.0 Beta appeared.

Code: Select all

13859<1&#58;info depth 1 seldepth 1 
13859<1&#58;info currmovenumber 1 currmove b1a3 
13890<1&#58;info depth 1 time 60 score cp 0 lowerbound nodes 1 nps 16 pv b1a3 
13890<1&#58;info currmovenumber 1 currmove b1a3 
13890<1&#58;info currmovenumber 2 currmove b1c3 
13890<1&#58;info depth 1 time 70 score cp 16 lowerbound nodes 3 nps 42 pv b1c3 
13890<1&#58;info currmovenumber 1 currmove b1c3 
13906<1&#58;info currmovenumber 2 currmove b1a3 
13906<1&#58;info currmovenumber 3 currmove g1f3 
13906<1&#58;info currmovenumber 4 currmove g1h3 
13906<1&#58;info currmovenumber 5 currmove a2a4 
13906<1&#58;info currmovenumber 6 currmove b2b4 
13906<1&#58;info currmovenumber 7 currmove c2c4 
13906<1&#58;info currmovenumber 8 currmove d2d4 
13922<1&#58;info currmovenumber 9 currmove e2e4 
13922<1&#58;info currmovenumber 10 currmove f2f4 
13922<1&#58;info currmovenumber 11 currmove g2g4 
13922<1&#58;info currmovenumber 12 currmove h2h4 
13922<1&#58;info currmovenumber 13 currmove a2a3 
13922<1&#58;info currmovenumber 14 currmove b2b3 
13922<1&#58;info currmovenumber 15 currmove c2c3 
13937<1&#58;info currmovenumber 16 currmove d2d3 
13937<1&#58;info currmovenumber 17 currmove e2e3 
13937<1&#58;info currmovenumber 18 currmove f2f3 
13937<1&#58;info currmovenumber 19 currmove g2g3 
13953<1&#58;info currmovenumber 20 currmove h2h3 
13953<1&#58;info nodes 23 
13953<1&#58;info depth 2 seldepth 2 
13953<1&#58;info currmovenumber 1 currmove b1c3 
13953<1&#58;info depth 2 time 90 score cp 16 lowerbound nodes 72 nps 800 pv b1c3 
13953<1&#58;info currmovenumber 1 currmove b1c3 
13968<1&#58;info currmovenumber 2 currmove b1a3 
13968<1&#58;info currmovenumber 3 currmove g1f3 
13968<1&#58;info currmovenumber 4 currmove d2d4 
13968<1&#58;info currmovenumber 5 currmove e2e4 
13968<1&#58;info currmovenumber 6 currmove g1h3 
13968<1&#58;info currmovenumber 7 currmove c2c4 
13984<1&#58;info currmovenumber 8 currmove f2f4 
13984<1&#58;info currmovenumber 9 currmove a2a3 
13984<1&#58;info currmovenumber 10 currmove c2c3 
13984<1&#58;info currmovenumber 11 currmove d2d3 
13984<1&#58;info currmovenumber 12 currmove e2e3 
13984<1&#58;info currmovenumber 13 currmove f2f3 
14000<1&#58;info currmovenumber 14 currmove h2h3 
14000<1&#58;info currmovenumber 15 currmove b2b3 
14000<1&#58;info currmovenumber 16 currmove h2h4 
14000<1&#58;info currmovenumber 17 currmove g2g3 
14000<1&#58;info currmovenumber 18 currmove a2a4 
14015<1&#58;info currmovenumber 19 currmove g2g4 
14015<1&#58;info currmovenumber 20 currmove b2b4 
14015<1&#58;info nodes 112 
14015<1&#58;info depth 3 seldepth 3 
14015<1&#58;info currmovenumber 1 currmove b1c3 
14031<1&#58;info currmovenumber 2 currmove g1f3 
14031<1&#58;info currmovenumber 3 currmove d2d4 
14031<1&#58;info currmovenumber 4 currmove e2e4 
14031<1&#58;info currmovenumber 5 currmove b1a3 
14031<1&#58;info currmovenumber 6 currmove g1h3 
14047<1&#58;info currmovenumber 7 currmove c2c4 
14047<1&#58;info currmovenumber 8 currmove f2f4 
14047<1&#58;info currmovenumber 9 currmove a2a3 
14047<1&#58;info currmovenumber 10 currmove c2c3 
14062<1&#58;info currmovenumber 11 currmove d2d3 
14062<1&#58;info currmovenumber 12 currmove e2e3 
14062<1&#58;info currmovenumber 13 currmove f2f3 
14062<1&#58;info currmovenumber 14 currmove h2h3 
14062<1&#58;info currmovenumber 15 currmove b2b3 
14078<1&#58;info currmovenumber 16 currmove h2h4 
14078<1&#58;info currmovenumber 17 currmove g2g3 
14078<1&#58;info currmovenumber 18 currmove a2a4 
14078<1&#58;info currmovenumber 19 currmove g2g4 
14093<1&#58;info currmovenumber 20 currmove b2b4 
14093<1&#58;info currmovenumber 1 currmove b1c3 
14093<1&#58;info currmovenumber 2 currmove g1f3 
14093<1&#58;info currmovenumber 3 currmove d2d4 
14093<1&#58;info currmovenumber 4 currmove e2e4 
14109<1&#58;info currmovenumber 5 currmove b1a3 
14109<1&#58;info currmovenumber 6 currmove g1h3 
14109<1&#58;info currmovenumber 7 currmove c2c4 
14109<1&#58;info currmovenumber 8 currmove f2f4 
14125<1&#58;info currmovenumber 9 currmove a2a3 
14125<1&#58;info currmovenumber 10 currmove c2c3 
14125<1&#58;info currmovenumber 11 currmove d2d3 
14125<1&#58;info currmovenumber 12 currmove e2e3 
14125<1&#58;info currmovenumber 13 currmove f2f3 
14140<1&#58;info currmovenumber 14 currmove h2h3 
14140<1&#58;info currmovenumber 15 currmove b2b3 
14140<1&#58;info currmovenumber 16 currmove h2h4 
14140<1&#58;info currmovenumber 17 currmove g2g3 
14140<1&#58;info currmovenumber 18 currmove a2a4 
14140<1&#58;info currmovenumber 19 currmove g2g4 
14156<1&#58;info currmovenumber 20 currmove b2b4 
14156<1&#58;info currmovenumber 1 currmove b1c3 
14156<1&#58;info depth 3 time 120 score cp 0 lowerbound nodes 500 nps 4166 pv b1c3 8c6 g1f3 g8f6 
14156<1&#58;info nodes 500 
14156<1&#58;info depth 4 seldepth 4 
14172<1&#58;info currmovenumber 1 currmove b1c3 
14172<1&#58;info depth 4 time 120 score cp 0 lowerbound nodes 541 nps 4508 pv b1c3 b8c6 g1f3 g8f6 
14172<1&#58;info currmovenumber 1 currmove b1c3 
14172<1&#58;info depth 4 time 120 score cp 8 lowerbound nodes 682 nps 5683 pv b1c3 b8c6 g1f3 g8f6 d2d4 
14172<1&#58;info currmovenumber 1 currmove b1c3 
14187<1&#58;info currmovenumber 2 currmove d2d4 
14187<1&#58;info currmovenumber 3 currmove e2e4 
14187<1&#58;info currmovenumber 4 currmove g1f3 
14187<1&#58;info currmovenumber 5 currmove b1a3 
14187<1&#58;info currmovenumber 6 currmove g1h3 
14187<1&#58;info currmovenumber 7 currmove c2c4 
14203<1&#58;info currmovenumber 8 currmove f2f4 
14203<1&#58;info currmovenumber 9 currmove a2a3 
14203<1&#58;info currmovenumber 10 currmove c2c3 
14203<1&#58;info currmovenumber 11 currmove d2d3 
14203<1&#58;info currmovenumber 12 currmove e2e3 
14203<1&#58;info currmovenumber 13 currmove f2f3 
14218<1&#58;info currmovenumber 14 currmove h2h3 
14218<1&#58;info currmovenumber 15 currmove b2b3 
14218<1&#58;info currmovenumber 16 currmove h2h4 
14218<1&#58;info currmovenumber 17 currmove g2g3 
14218<1&#58;info currmovenumber 18 currmove a2a4 
14218<1&#58;info currmovenumber 19 currmove g2g4 
14234<1&#58;info currmovenumber 20 currmove b2b4 
14234<1&#58;info currmovenumber 1 currmove b1c3 
14234<1&#58;info currmovenumber 2 currmove d2d4 
14234<1&#58;info currmovenumber 3 currmove e2e4 
14250<1&#58;info currmovenumber 4 currmove g1f3 
14250<1&#58;info currmovenumber 5 currmove b1a3 
14250<1&#58;info currmovenumber 6 currmove g1h3 
14250<1&#58;info currmovenumber 7 currmove c2c4 
14250<1&#58;info currmovenumber 8 currmove f2f4 
14265<1&#58;info currmovenumber 9 currmove a2a3 
14265<1&#58;info currmovenumber 10 currmove c2c3 
14265<1&#58;info currmovenumber 11 currmove d2d3 
14265<1&#58;info currmovenumber 12 currmove e2e3 
14265<1&#58;info currmovenumber 13 currmove f2f3 
14265<1&#58;info currmovenumber 14 currmove h2h3 
14281<1&#58;info currmovenumber 15 currmove b2b3 
14281<1&#58;info currmovenumber 16 currmove h2h4 
14281<1&#58;info currmovenumber 17 currmove g2g3 
14281<1&#58;info currmovenumber 18 currmove a2a4 
14281<1&#58;info currmovenumber 19 currmove g2g4 
14297<1&#58;info currmovenumber 20 currmove b2b4 
14297<1&#58;info nodes 925 
14297<1&#58;info depth 5 seldepth 5 
14297<1&#58;info currmovenumber 1 currmove b1c3 
14312<1&#58;info currmovenumber 2 currmove g1f3 
14312<1&#58;info currmovenumber 3 currmove d2d4 
14312<1&#58;info currmovenumber 4 currmove e2e4 
14312<1&#58;info currmovenumber 5 currmove b1a3 
14328<1&#58;info currmovenumber 6 currmove g1h3 
14328<1&#58;info currmovenumber 7 currmove c2c4 
14328<1&#58;info currmovenumber 8 currmove f2f4 
14328<1&#58;info currmovenumber 9 currmove a2a3 
14343<1&#58;info currmovenumber 10 currmove c2c3 
14343<1&#58;info currmovenumber 11 currmove d2d3 
14343<1&#58;info currmovenumber 12 currmove e2e3 
14359<1&#58;info currmovenumber 13 currmove f2f3 
14359<1&#58;info currmovenumber 14 currmove h2h3 
14359<1&#58;info currmovenumber 15 currmove b2b3 
14359<1&#58;info currmovenumber 16 currmove h2h4 
14375<1&#58;info currmovenumber 17 currmove g2g3 
14375<1&#58;info currmovenumber 18 currmove a2a4 
14375<1&#58;info currmovenumber 19 currmove g2g4 
14375<1&#58;info currmovenumber 20 currmove b2b4 
14390<1&#58;info currmovenumber 1 currmove b1c3 
14390<1&#58;info depth 5 time 150 score cp 0 lowerbound nodes 2930 nps 19533 pv b1c3 b8c6 g1f3 g8f6 d2d4 c6b4 
14390<1&#58;info nodes 2930 
14390<1&#58;info depth 6 seldepth 6 
14406<1&#58;info currmovenumber 1 currmove b1c3 
14406<1&#58;info depth 6 time 150 score cp 0 lowerbound nodes 3706 nps 24706 pv b1c3 b8c6 g1f3 g8f6 d2d4 c6b4 
14406<1&#58;info currmovenumber 1 currmove b1c3 
14422<1&#58;info depth 6 time 150 score cp 8 lowerbound nodes 4482 nps 29880 pv b13 b8c6 g1f3 g8f6 d2d4 c6b4 c3b5 
14422<1&#58;info currmovenumber 1 currmove b1c3 
14422<1&#58;info currmovenumber 2 currmove d2d4 
14437<1&#58;info currmovenumber 3 currmove g1f3 
14437<1&#58;info currmovenumber 4 currmove e2e4 
14437<1&#58;info currmovenumber 5 currmove e2e3 
14437<1&#58;info currmovenumber 6 currmove d2d3 
14453<1&#58;info currmovenumber 7 currmove b1a3 
14453<1&#58;info currmovenumber 8 currmove c2c4 
14453<1&#58;info currmovenumber 9 currmove g1h3 
14453<1&#58;info currmovenumber 10 currmove f2f4 
14468<1&#58;info currmovenumber 11 currmove c2c3 
14468<1&#58;info currmovenumber 12 currmove a2a3 
14468<1&#58;info currmovenumber 13 currmove h2h4 
14468<1&#58;info currmovenumber 14 currmove f2f3 
14484<1&#58;info currmovenumber 15 currmove h2h3 
14484<1&#58;info currmovenumber 16 currmove b2b3 
14484<1&#58;info currmovenumber 17 currmove a2a4 
14484<1&#58;info currmovenumber 18 currmove g2g3 
14500<1&#58;info currmovenumber 19 currmove g2g4 
14500<1&#58;info currmovenumber 20 currmove b2b4 
14500<1&#58;info currmovenumber 1 currmove b1c3 
14515<1&#58;info currmovenumber 2 currmove d2d4 
14515<1&#58;info currmovenumber 3 currmove g1f3 
14515<1&#58;info currmovenumber 4 currmove e2e4 
14515<1&#58;info currmovenumber 5 currmove e2e3 
14531<1&#58;info currmovenumber 6 currmove d2d3 
14531<1&#58;info currmovenumber 7 currmove b1a3 
14531<1&#58;info currmovenumber 8 currmove c2c4 
14531<1&#58;info currmovenumber 9 currmove g1h3 
14547<1&#58;info currmovenumber 10 currmove f2f4 
14547<1&#58;info currmovenumber 11 currmove c2c3 
14547<1&#58;info currmovenumber 12 currmove a2a3 
14547<1&#58;info currmovenumber 13 currmove h2h4 
14562<1&#58;info currmovenumber 14 currmove f2f3 
14562<1&#58;info currmovenumber 15 currmove h2h3 
14562<1&#58;info currmovenumber 16 currmove b2b3 
14562<1&#58;info currmovenumber 17 currmove a2a4 
14578<1&#58;info currmovenumber 18 currmove g2g3 
14578<1&#58;info currmovenumber 19 currmove g2g4 
14578<1&#58;info currmovenumber 20 currmove b2b4 
14578<1&#58;info nodes 8288 
14593<1&#58;info depth 7 seldepth 7 
14593<1&#58;info currmovenumber 1 currmove b1c3 
14593<1&#58;info currmovenumber 2 currmove d2d4 
14593<1&#58;info currmovenumber 3 currmove d2d3 
14609<1&#58;info currmovenumber 4 currmove e2e3 
14609<1&#58;info currmovenumber 5 currmove g1h3 
14609<1&#58;info currmovenumber 6 currmove b1a3 
14609<1&#58;info currmovenumber 7 currmove g1f3 
14625<1&#58;info currmovenumber 8 currmove f2f4 
14625<1&#58;info currmovenumber 9 currmove f2f3 
14625<1&#58;info currmovenumber 10 currmove e2e4 
14625<1&#58;info currmovenumber 11 currmove c2c4 
14640<1&#58;info currmovenumber 12 currmove c2c3 
14640<1&#58;info currmovenumber 13 currmove a2a3 
14640<1&#58;info currmovenumber 14 currmove h2h3 
14640<1&#58;info currmovenumber 15 currmove h2h4 
14656<1&#58;info currmovenumber 16 currmove b2b3 
14656<1&#58;info currmovenumber 17 currmove a2a4 
14656<1&#58;info currmovenumber 18 currmove g2g3 
14672<1&#58;info currmovenumber 19 currmove g2g4 
14672<1&#58;info currmovenumber 20 currmove b2b4 
14672<1&#58;info currmovenumber 1 currmove b1c3 
14672<1&#58;info depth 7 time 230 score cp 0 lowerbound nodes 24706 nps 107417 pv b1c3 b8c6 g1f3 g8f6 d2d4 d7d5 c3b5 c6b4 
14687<1&#58;info nodes 24706 
14687<1&#58;info depth 8 seldepth 8 
14687<1&#58;info currmovenumber 1 currmove b1c3 
14703<1&#58;info depth 8 time 230 score cp 0 lowerbound nodes 26032 nps 113182 pv b1c3 b8c6 g1f3 g8f6 d2d4 d7d5 c3b5 c6b4 
14703<1&#58;info currmovenumber 1 currmove b1c3 
14703<1&#58;info depth 8 time 310 score cp 8 lowerbound nodes 45970 nps 148290 pv 1c3 b8c6 g1f3 g8f6 d2d4 d7d5 c3b5 c6b4 f3e5 
14718<1&#58;info currmovenumber 1 currmove b1c3 
14718<1&#58;info currmovenumber 2 currmove d2d4 
14718<1&#58;info currmovenumber 3 currmove e2e4 
14718<1&#58;info currmovenumber 4 currmove g1f3 
14734<1&#58;info currmovenumber 5 currmove e2e3 
14734<1&#58;info currmovenumber 6 currmove d2d3 
14734<1&#58;info currmovenumber 7 currmove g1h3 
14734<1&#58;info currmovenumber 8 currmove b1a3 
14750<1&#58;info currmovenumber 9 currmove f2f4 
14750<1&#58;info currmovenumber 10 currmove c2c4 
14750<1&#58;info currmovenumber 11 currmove a2a3 
14750<1&#58;info currmovenumber 12 currmove h2h3 
14765<1&#58;info currmovenumber 13 currmove f2f3 
14765<1&#58;info currmovenumber 14 currmove c2c3 
14765<1&#58;info currmovenumber 15 currmove h2h4 
14765<1&#58;info currmovenumber 16 currmove a2a4 
14781<1&#58;info currmovenumber 17 currmove b2b3 
14781<1&#58;info currmovenumber 18 currmove g2g4 
14781<1&#58;info currmovenumber 19 currmove g2g3 
14781<1&#58;info currmovenumber 20 currmove b2b4 
14797<1&#58;info currmovenumber 1 currmove b1c3 
14797<1&#58;info currmovenumber 2 currmove d2d4 
14797<1&#58;info currmovenumber 3 currmove e2e4 
14812<1&#58;info currmovenumber 4 currmove g1f3 
14812<1&#58;info currmovenumber 5 currmove e2e3 
14812<1&#58;info currmovenumber 6 currmove d2d3 
14812<1&#58;info currmovenumber 7 currmove g1h3 
14828<1&#58;info currmovenumber 8 currmove b1a3 
14828<1&#58;info currmovenumber 9 currmove f2f4 
14828<1&#58;info currmovenumber 10 currmove c2c4 
14828<1&#58;info currmovenumber 11 currmove a2a3 
14843<1&#58;info currmovenumber 12 currmove h2h3 
14843<1&#58;info currmovenumber 13 currmove f2f3 
14843<1&#58;info currmovenumber 14 currmove c2c3 
14843<1&#58;info currmovenumber 15 currmove h2h4 
14859<1&#58;info currmovenumber 16 currmove a2a4 
14859<1&#58;info currmovenumber 17 currmove b2b3 
14859<1&#58;info currmovenumber 18 currmove g2g4 
14859<1&#58;info currmovenumber 19 currmove g2g3 
14875<1&#58;info currmovenumber 20 currmove b2b4 
14875<1&#58;info nodes 57429 
14875<1&#58;info depth 9 seldepth 9 
14875<1&#58;info currmovenumber 1 currmove b1c3 
14890<1&#58;info currmovenumber 2 currmove g1f3 
14890<1&#58;info currmovenumber 3 currmove e2e4 
14890<1&#58;info currmovenumber 4 currmove d2d4 
15297<1&#58;info depth 9 time 1480 score cp 8 lowerbound nodes 528691 nps 357223 pv d2d4 g8f6 d1d3 b8c6 g1f3 c6b4 d3c4 e7e6 c1f4 
15297<1&#58;info currmovenumber 1 currmove d2d4 
15297<1&#58;info currmovenumber 2 currmove b1c3 
15312<1&#58;info currmovenumber 3 currmove g1f3 
15312<1&#58;info currmovenumber 4 currmove e2e4 
15312<1&#58;info currmovenumber 5 currmove e2e3 
15312<1&#58;info currmovenumber 6 currmove d2d3 
15328<1&#58;info currmovenumber 7 currmove g1h3 
15328<1&#58;info currmovenumber 8 currmove b1a3 
15328<1&#58;info currmovenumber 9 currmove f2f4 
15328<1&#58;info currmovenumber 10 currmove c2c4 
15343<1&#58;info currmovenumber 11 currmove a2a3 
15343<1&#58;info currmovenumber 12 currmove h2h3 
15343<1&#58;info currmovenumber 13 currmove f2f3 
15343<1&#58;info currmovenumber 14 currmove c2c3 
15359<1&#58;info currmovenumber 15 currmove h2h4 
15359<1&#58;info currmovenumber 16 currmove a2a4 
15359<1&#58;info currmovenumber 17 currmove b2b3 
15359<1&#58;info currmovenumber 18 currmove g2g3 
15375<1&#58;info currmovenumber 19 currmove g2g4 
15375<1&#58;info currmovenumber 20 currmove b2b4 
15375<1&#58;info nodes 536231 
15375<1&#58;info depth 10 seldepth 10 
15390<1&#58;info currmovenumber 1 currmove d2d4 
16078<1&#58;info depth 10 time 2260 score cp 8 lowerbound nodes 1017166 nps 450073 pv d2d4 g8f6 d1d3 b8c6 g1f3 c6b4 d3c4 e7e6 c1f4 
16093<1&#58;info currmovenumber 1 currmove d2d4 
16250<1&#58;info currmovenumber 2 currmove d2d3 
16250<1&#58;info currmovenumber 3 currmove b1a3 
16265<1&#58;info currmovenumber 4 currmove e2e3 
16265<1&#58;info currmovenumber 5 currmove g1h3 
16265<1&#58;info currmovenumber 6 currmove f2f4 
16265<1&#58;info currmovenumber 7 currmove f2f3 
16281<1&#58;info currmovenumber 8 currmove c2c4 
16281<1&#58;info currmovenumber 9 currmove h2h4 
16281<1&#58;info currmovenumber 10 currmove c2c3 
16297<1&#58;info currmovenumber 11 currmove a2a4 
16297<1&#58;info currmovenumber 12 currmove a2a3 
16297<1&#58;info currmovenumber 13 currmove h2h3 
16297<1&#58;info currmovenumber 14 currmove b2b3 
16312<1&#58;info currmovenumber 15 currmove g2g4 
16312<1&#58;info currmovenumber 16 currmove g2g3 
16312<1&#58;info currmovenumber 17 currmove b2b4 
16312<1&#58;info currmovenumber 18 currmove g1f3 
16328<1&#58;info currmovenumber 19 currmove e2e4 
16328<1&#58;info currmovenumber 20 currmove b1c3 
16343<1&#58;info nodes 1156235 
16343<1&#58;info depth 11 seldepth 11 

[/quote]

[Gerd Isenberg]

Some notes to don't make this post disappear.

EDIT: please keep this thread clean. I'd like to only have specific questions about low level similarities between Rybka and Fruit, and possibly answers from Vas. No need to start another flamewar here.

Vas,

You agreed to answer any questions about similarities between Rybka 1.0 and Fruit. I am glad that you have agreed to do such, and I hope you take the time to answer each of the concerns that I and others have.

This list of similarities between Rybka 1.0 and Fruit was compiled in the past day or so. It's by no means complete, and there are other issues that I've found that I haven't totally verified yet. Each item in this list may be a small similarity that other engines also have, but the idea is to show how many of them are. At some point it will have to be decided whether it all is just a coincidence or not. For those that ask for proof, I'm going to try to set up a web page with snippets of disassembly compared to the Fruit code for each claim made here. Any assistance that anyone has in doing this would be greatly appreciated. It would also help to point out low-level similarities between Strelka and Fruit. These would be verified against Rybka 1.0 by myself or someone else before posting.

I will add, Vas, that some have questioned our motives in presenting these questions. I believe that Rybka started its life as Fruit. I don't wish that you stop. You have obviously done some amazing things with Rybka, and I want them to continue just for the sake of advancement. I just want everyone to play by the rules. If you started with Fruit, there's no problem with that, you just need to be forthcoming about it and abide by the license. I'm not even interested in the legal aspect of all this, that would be for others to handle if necessary.

UCI 'go' parser seems the strongest point so far.

COMMAND INTERPRETER:
--The UCI 'go' parser is virtually identical (as shown by Rick Fadden), including the time control code

Looks like a plausible order to me - except probably Setjmp
Of course you need to generate moves before ordering them
Does 150 have the same semantics in Fruit and Rybka 1.0 beta, e.g. centipawns?

SEARCH:
--Does not use fractional extensions
--In the root function, for initializing the search, the order of steps is:
Generate legal moves
Setjmp
Limit depth if num_moves == 1 to 4
Increment hash age
Reset killers
Reset history
Look up hash move
Score and sort moves
--Use identical easy move logic: if (depth == 1 && best_score > second_best + 150) easy=true;
--both use flags in the root function bad_1 and bad_2

Might be quite common as well - since you always fetch both game stages simultaneously. In assembly it could be an array of structs as well.

EVAL:
--Piece square tables are of the form [12][64][2], where the last entry is game stage

This is interesting, but might be considered as taking ideas rather than code.

TRANS:
--Stores both a minimum and maximum bound in the hash table, and depths for both
--Stores only 32 bits of the hash key
--Stores a quantity called "move depth"
--For the replacement scheme, a value is calculated that is trans_age[entry] - depth, where trans_age contains the difference of the current date and the entry's date mod DateSize (4 in Rybka, 16 in Fruit). This is multiplied by 256. In Rybka, the table has the values already multiplied by 256, and in Fruit, it is multiplied on the fly.
--Both use a bucket system with 4 entries

I think the next one is quite common as well. I also use WK=1, WQ=2, BK=4, BQ=8 and used to use the stack that much and have separate make_null, undo_null. Why is CastleHash[oldflags] ^ CastleHash[newflags] more natural?

BOARD REPRESENTATION:
--Uses an "undo_t" to store moves that it made, which are only kept on the system stack, not in regular memory.
--Only game history stored is a stack of hashkeys
--The index of this game history is stored as an int, not a pointer
--Two values, "opening" and "endgame" are stored in the board, containing sums of piece square tables
--The masks for hashing castling status are WK=1, WQ=2, BK=4, BQ=8
--For hashing of castling status, the hashkey is updated by CastleHash[oldflags ^ newflags], rather than the more natural CastleHash[oldflags] ^ CastleHash[newflags]
--Both have separate make_null and undo_null functions

Gerd

[Zach Wegner]

Gerd,

Thank you for your interest. This kind of posts are what we need: calm, objective observations.

UCI 'go' parser seems the strongest point so far.

It is certainly strong evidence. Unfortunately nobody seems to take it as "evidence".

Looks like a plausible order to me - except probably Setjmp
Of course you need to generate moves before ordering them
Does 150 have the same semantics in Fruit and Rybka 1.0 beta, e.g. centipawns?

Yes, at this point, the semantics are the same. It is a plausible order, i.e. it makes sense, but it is just rare to have the exact same order. The most important points here IMO are the setjmp, the limit depth, and the lookup hash move. Not many engines do a hash probe before starting with iterative deepening.

Might be quite common as well - since you always fetch both game stages simultaneously. In assembly it could be an array of structs as well.

Yes, these things might be "typical". But very few engines use them. I am merely trying to accumulate such low level similarities. As of yet, I haven't found any such similarities with any other engine I am aware of.

This is interesting, but might be considered as taking ideas rather than code.

While I see this point, we have to keep in mind that Rybka was already a 2000 engine before Fruit. I would expect it to already have hash tables, piece square tables, etc. So it's either a coincidence that such similarities exist, or Vas rewrote many fundamental aspects of his engine after Fruit came out.

I think the next one is quite common as well. I also use WK=1, WQ=2, BK=4, BQ=8 and used to use the stack that much and have separate make_null, undo_null. Why is CastleHash[oldflags] ^ CastleHash[newflags] more natural?

I would think that would be obvious. Take two situations, from the beginning of the game. Castling status is 1111b. Now white can lose its castling rights in two ways, moving its king or both its rooks. Which would happen like this:

King move:
hashkey ^= CastleHash[1111 ^ 0011 = 1100];

Rook moves:
hashkey ^= CastleHash[1111 ^ 0111 = 1000];
hashkey ^= CastleHash[1111 ^ 1011 = 0100];

Both of these must result in the same hashkey, which means that CastleHash[1100] == CastleHash[1000] ^ CastleHash[0100]. So you can't simply fill CastleHash with random numbers, you have to create 4 hashkeys at first (for each of 1, 2, 4, 8), and then make CastleHash[abcd] = CastleHash[a000] ^ CastleHash[0b00] ^ ..., with of course CastleHash[0] = 0.

And then of course when reading a fen, you must initialize the hashkey with hashkey ^= CastleHash[1111 ^ flags].

[Gerd Isenberg]

I think the next one is quite common as well. I also use WK=1, WQ=2, BK=4, BQ=8 and used to use the stack that much and have separate make_null, undo_null. Why is CastleHash[oldflags] ^ CastleHash[newflags] more natural?

I would think that would be obvious. Take two situations, from the beginning of the game. Castling status is 1111b. Now white can lose its castling rights in two ways, moving its king or both its rooks. Which would happen like this:

King move:
hashkey ^= CastleHash[1111 ^ 0011 = 1100];

Rook moves:
hashkey ^= CastleHash[1111 ^ 0111 = 1000];
hashkey ^= CastleHash[1111 ^ 1011 = 0100];

Both of these must result in the same hashkey, which means that CastleHash[1100] == CastleHash[1000] ^ CastleHash[0100]. So you can't simply fill CastleHash with random numbers, you have to create 4 hashkeys at first (for each of 1, 2, 4, 8), and then make CastleHash[abcd] = CastleHash[a000] ^ CastleHash[0b00] ^ ..., with of course CastleHash[0] = 0.

And then of course when reading a fen, you must initialize the hashkey with hashkey ^= CastleHash[1111 ^ flags].

Anyway, I found xor castle state more natural, even with your mentioned initialization issues. You can not get a castle right back in make move. Thus a one bit in the xor sum of the states implies appropriate castle rights lost in make move and is therefor sufficient as index. Probably I am a bit biased with my quad-bitboard color flipper

I appreciate your courage, fairness and reasoning!

Cheers,
Gerd

[Zach Wegner]

Anyway, I found xor castle state more natural, even with your mentioned initialization issues. You can not get a castle right back in make move. Thus a one bit in the xor sum of the states implies appropriate castle rights lost in make move and is therefor sufficient as index. Probably I am a bit biased with my quad-bitboard color flipper

Interesting. I still think it is rather unnatural, but I can see your reasoning. Of course, Fabien also seemed to favor that method. It does seem to me to be a rather unconventional way, though.

I appreciate your courage, fairness and reasoning!

Believe me Gerd, the feeling is mutual. This forum is a very difficult place to conduct any sort of an investigation. We have tried to make it a public process, so that as many objective opinions can be gathered and so that we can get as much information public as quickly as possible. This seemed to backfire rather badly. Instead of calm, objective discussion, as is happening right here, there is a huge amount of noise surrounding motives etc. in which the good stuff can easily be drowned out.

Your posts are both informative and unbiased. You present the arguments for the other side without taking a side at all. Though you have made very few posts in this matter compared to most, your contribution is invaluable.

Thank you for your kind words, Gerd. I wish you well.

Regards,
Zach

[chrisw]

Gerd,

Thank you for your interest. This kind of posts are what we need: calm, objective observations.

UCI 'go' parser seems the strongest point so far.

It is certainly strong evidence. Unfortunately nobody seems to take it as "evidence".

Looks like a plausible order to me - except probably Setjmp
Of course you need to generate moves before ordering them
Does 150 have the same semantics in Fruit and Rybka 1.0 beta, e.g. centipawns?

Yes, at this point, the semantics are the same. It is a plausible order, i.e. it makes sense, but it is just rare to have the exact same order. The most important points here IMO are the setjmp, the limit depth, and the lookup hash move. Not many engines do a hash probe before starting with iterative deepening.

Might be quite common as well - since you always fetch both game stages simultaneously. In assembly it could be an array of structs as well.

Yes, these things might be "typical". But very few engines use them. I am merely trying to accumulate such low level similarities. As of yet, I haven't found any such similarities with any other engine I am aware of.

This is interesting, but might be considered as taking ideas rather than code.

While I see this point, we have to keep in mind that Rybka was already a 2000 engine before Fruit. I would expect it to already have hash tables, piece square tables, etc. So it's either a coincidence that such similarities exist, or Vas rewrote many fundamental aspects of his engine after Fruit came out.

I think the next one is quite common as well. I also use WK=1, WQ=2, BK=4, BQ=8 and used to use the stack that much and have separate make_null, undo_null. Why is CastleHash[oldflags] ^ CastleHash[newflags] more natural?

I would think that would be obvious. Take two situations, from the beginning of the game. Castling status is 1111b. Now white can lose its castling rights in two ways, moving its king or both its rooks. Which would happen like this:

King move:
hashkey ^= CastleHash[1111 ^ 0011 = 1100];

Rook moves:
hashkey ^= CastleHash[1111 ^ 0111 = 1000];
hashkey ^= CastleHash[1111 ^ 1011 = 0100];

Both of these must result in the same hashkey, which means that CastleHash[1100] == CastleHash[1000] ^ CastleHash[0100]. So you can't simply fill CastleHash with random numbers, you have to create 4 hashkeys at first (for each of 1, 2, 4, 8), and then make CastleHash[abcd] = CastleHash[a000] ^ CastleHash[0b00] ^ ..., with of course CastleHash[0] = 0.

And then of course when reading a fen, you must initialize the hashkey with hashkey ^= CastleHash[1111 ^ flags].

Zach,

Would it be possible that you generate some corresponding identical Fruit/Rybka engine code fragment in a strongest case version. ie the one you believe you could base your case on and which is most difficult to refute? Both sides can then concentrate their expert firepower onto this one case. If the anti side can't shoot your example down, then maybe Vas could be asked to comment?

[Zach Wegner]

Zach,

Would it be possible that you generate some corresponding identical Fruit/Rybka engine code fragment in a strongest case version. ie the one you believe you could base your case on and which is most difficult to refute? Both sides can then concentrate their expert firepower onto this one case. If the anti side can't shoot your example down, then maybe Vas could be asked to comment?

Chris,

In your attempt to "clean up" this thread, you have made a mistake. I responded to your (now edited) post perfectly reasonably, and the reply has been moved away. But more importantly, you have left your post in place, when that is what caused many side discussions. If you had simply moved your post instead of its replies, we would not need four extra threads, merely one.

Of course I am preparing this "identical code". I have been for quite some time. All I am working on now is the root function posted earlier, as some people cannot accept "hieroglyphics". I have been going through it with a huge amount of detail, and even presenting 20-30 lines of accurately reverse engineered code takes quite some time. To ask me to do the same thing for everything I have seen (and more) in the Rybka 1.0 executable and come up with the "best" before Vas even comments is far too much. I will post things as I get them. Whether they are the best evidence remains to be seen.

This whole thread's point was to ask Vas for comments, and they have not come. So now I have to post more evidence in order for what I said earlier to be valid in your view?

[chrisw]

Zach,

Would it be possible that you generate some corresponding identical Fruit/Rybka engine code fragment in a strongest case version. ie the one you believe you could base your case on and which is most difficult to refute? Both sides can then concentrate their expert firepower onto this one case. If the anti side can't shoot your example down, then maybe Vas could be asked to comment?

Chris,

In your attempt to "clean up" this thread, you have made a mistake. I responded to your (now edited) post perfectly reasonably, and the reply has been moved away. But more importantly, you have left your post in place, when that is what caused many side discussions. If you had simply moved your post instead of its replies, we would not need four extra threads, merely one.

Of course I am preparing this "identical code". I have been for quite some time. All I am working on now is the root function posted earlier, as some people cannot accept "hieroglyphics". I have been going through it with a huge amount of detail, and even presenting 20-30 lines of accurately reverse engineered code takes quite some time. To ask me to do the same thing for everything I have seen (and more) in the Rybka 1.0 executable and come up with the "best" before Vas even comments is far too much. I will post things as I get them. Whether they are the best evidence remains to be seen.

This whole thread's point was to ask Vas for comments, and they have not come. So now I have to post more evidence in order for what I said earlier to be valid in your view?

Sorry, I thought I was doing the best possible, but, as you and Vas know, one's best efforts always get criticised by someone. I edited the bits of my post that might remotely have sent people sideways and left in the positive (hopefully) suggestion.

Anyway, let's look forward to seeing the results of all your hard work. I hope it will have been worth it.