M ANSARI wrote:There is no arrogance or intellectual dishonesty, just my opinion based on EVALUATIONS of Fruit and Rybka 1.0.
...
What you are talking about doesn't have much about EVALUATION.
...
What you are calling EVALUATION is in reality search+evaluation+obfuscated Rybka output.
The real evaluation you would get if you put fixed depth search to -2, disable hash + decode obfuscated Rybka output (in this case rescale score values).
...
output of search+evaluation+without obfuscation is correct:-
1) we cannot accept any output from a program unless we have trust in it. Commercial chess programs might not be willing to tell too much. It may even happen that the author had to output something, but he cannot give the real thing.
2) the score returned after a root search is NOT STATIC EVALUATION in chess programming. It indeed usually involves a call to the static evaluator somewhere up the tree but we don't know at which ply nor after what manner of search prunning, nullmove, ...+ many I don't know about + etc.
3) If Rybka has a facility to "print a reliable static evaluation of a position", then the output would be the static evaluation.
Sean Evans wrote:Here is my email to the WCCC I sent some time ago. As of now no response. It seems the WCCC prefers to hide under a rock rather than deal with issues like Rybka the derivative It looks like I will have to personally pull the WCCC out from under their rock, kicking and screaming if necessary
-----Original Message-----
From: Sean Evans
Sent: June 28, 2010 5:22 PM
To: 'tournaments@icga.org'
Subject: WCCC - 2010
Hello WCCC,
Would you please advise me whether you will reverse engineer Rybka 4 to confirm it is an original work? There is a significant amount belief and some evidence in the computer chess community that Rybka 4 is a derivative of the open source computer chess program “Fruit”.
For instance, you can see a straw poll at the Computer Chess Club here:
M ANSARI wrote:There is no arrogance or intellectual dishonesty, just my opinion based on EVALUATIONS of Fruit and Rybka 1.0.
...
What you are talking about doesn't have much about EVALUATION.
...
What you are calling EVALUATION is in reality search+evaluation+obfuscated Rybka output.
The real evaluation you would get if you put fixed depth search to -2, disable hash + decode obfuscated Rybka output (in this case rescale score values).
...
output of search+evaluation+without obfuscation is correct:-
1) we cannot accept any output from a program unless we have trust in it. Commercial chess programs might not be willing to tell too much. It may even happen that the author had to output something, but he cannot give the real thing.
2) the score returned after a root search is NOT STATIC EVALUATION in chess programming. It indeed usually involves a call to the static evaluator somewhere up the tree but we don't know at which ply nor after what manner of search prunning, nullmove, ...+ many I don't know about + etc.
3) If Rybka has a facility to "print a reliable static evaluation of a position", then the output would be the static evaluation.
Rasjid
The only thing that can and should be trusted from a program, is the move that selects. In that respect, the Rybkas were shown to be quite different from the fruity family with a statistical analysis. At least R2 and R3's, I do not remember now if R1 was tried by Michael Hart.
M ANSARI wrote:There is no arrogance or intellectual dishonesty, just my opinion based on EVALUATIONS of Fruit and Rybka 1.0.
...
What you are talking about doesn't have much about EVALUATION.
...
What you are calling EVALUATION is in reality search+evaluation+obfuscated Rybka output.
The real evaluation you would get if you put fixed depth search to -2, disable hash + decode obfuscated Rybka output (in this case rescale score values).
...
output of search+evaluation+without obfuscation is correct:-
1) we cannot accept any output from a program unless we have trust in it. Commercial chess programs might not be willing to tell too much. It may even happen that the author had to output something, but he cannot give the real thing.
2) the score returned after a root search is NOT STATIC EVALUATION in chess programming. It indeed usually involves a call to the static evaluator somewhere up the tree but we don't know at which ply nor after what manner of search prunning, nullmove, ...+ many I don't know about + etc.
3) If Rybka has a facility to "print a reliable static evaluation of a position", then the output would be the static evaluation.
Rasjid
The only thing that can and should be trusted from a program, is the move that selects. In that respect, the Rybkas were shown to be quite different from the fruity family with a statistical analysis. At least R2 and R3's, I do not remember now if R1 was tried by Michael Hart.
Miguel
I personally think chasing the Rybka 1 - Fruit connection has not much meaning. I don't know how Vasik stated, but his first Rybka outperformed all the others almost on its first release and there is nothing Fruity about it. It is his whatever is said about the other aspects.
michiguel wrote:The only thing that can and should be trusted from a program, is the move that selects. In that respect, the Rybkas were shown to be quite different from the fruity family with a statistical analysis. At least R2 and R3's, I do not remember now if R1 was tried by Michael Hart.
True. However, it has also been shown that unless programs are direct clones, there is very little or no correlation at all between move selection and amount of code copied. Therefore, move selection doesn't help us at all in Rybka/Fruit case.
michiguel wrote:The only thing that can and should be trusted from a program, is the move that selects. In that respect, the Rybkas were shown to be quite different from the fruity family with a statistical analysis. At least R2 and R3's, I do not remember now if R1 was tried by Michael Hart.
True. However, it has also been shown that unless programs are direct clones, there is very little or no correlation at all between move selection and amount of code copied. Therefore, move selection doesn't help us at all in Rybka/Fruit case.
If I first completely rewrite Fruit in bitboard and then add just some critical codes that don't amount to much by lines-of-code and there is a jump of Elo 200, my program will not play like Fruit - a program at -200 Elo.
Chan Rasjid wrote:If I first completely rewrite Fruit in bitboard and then add just some critical codes that don't amount to much by lines-of-code and there is a jump of Elo 200, my program will not play like Fruit - a program at -200 Elo.
Elo does correlate with move selection, but not in the form of elo difference but in the form of mean value.
programs of 3500 and 3300 will have much more correlated move selection than programs of 2100 and 2000.
michiguel wrote:The only thing that can and should be trusted from a program, is the move that selects. In that respect, the Rybkas were shown to be quite different from the fruity family with a statistical analysis. At least R2 and R3's, I do not remember now if R1 was tried by Michael Hart.
True. However, it has also been shown that unless programs are direct clones, there is very little or no correlation at all between move selection and amount of code copied. Therefore, move selection doesn't help us at all in Rybka/Fruit case.
If I first completely rewrite Fruit in bitboard and then add just some critical codes that don't amount to much by lines-of-code and there is a jump of Elo 200, my program will not play like Fruit - a program at -200 Elo.
Rasjid
Don't forget that he also changed some of the weights in the eval. That would change move selection and play style a bit.