I would say your 0.8 for the rook-pawn code is an outrageous mistake. And I'm being kind calling it a mistake. You do realise the chessic difference between the codings, and that you shoehorned the Rybka code into a category it should not be in, just to be able to "parallelise" (falsely) the two programs?BB+ wrote:hyatt wrote: I'd bet that was an outright error in translation, seeing as how it is actually a -25 Elo change.How is "beyond any reasonable doubt" the right standard? Who gets to decide?Chris Whittington wrote:Bet taken. $25,000 that you can't prove beyond any reasonable doubt that the Rybka rook-pawn code we were discussing was a "outright error in translation" within the next two months. I'll send you my lawyers address, we can both deposit $25,000 each. The $50,000 goes to me when you lose, else vice versa.I was actually going to comment on this issue (as Mr. Schröder had desired), but I see it has been derailed. Anyway, I still have not heard from a GM (evidently more useful than a mere IM, otherwise I might even have asked Levy ) regarding the chessic notion.hyatt wrote:I'll take that bet slightly reworded. YOU prove that he did NOT design the code as I speculated. ... Because now the onus would be on YOU. And it is an absolute certainty that you can't prove someone didn't so something. And NO, his word would NOT be proof.
Rebel wrote: But I haven't seem a program that gives NO PENALTY AT ALL for any double pawn in the middle game and only in the endgame.Midgame in Rybka is an interpolation of opening (24 phase units) and endgame (0 phase units). Rybka gives a (nonzero) penalty for a doubled pawn once any piece has been captured (on a pure phase basis, 24/25th of time, or 96% which would round up ). Furthermore, EVAL_COMP is primarily about features, not about numerical tuning. In this sense, Fruit and Rybka (and Faile and ExChess) use the "same" doubled pawn feature, while some other engines listed are of a more varying nature.Rebel wrote:There is NO midgame code in Rybka.All the engines involved have a "unique" backward/weak pawns feature. It is something for which there is a lot of scope for variations in implementation. Fruit/Rybka was higher than the "typical" amount of overlap.Rebel wrote:Considering the absence of an unique Fruit eval featureIf you wish to calibrate the scoring in that way, you are free to do so. You then end up with only (nearly) exact matches at 1.0, and Fruit/Rybka has (significantly) more of these than any other pair. I personally think adding in partial scores is a superior method. [For that matter, recall that most of the Panel did not particularly find EVAL_COMP's quantification of the situation to be necessary, and it was largely produced in response to comments by van Kervinck and Roberson].Rebel wrote:the similarity with Rybka is exactly 0.0
As to the rest of your COMP EVAL, its hard to know where even to begin in criticising it. Not even wrong comes to mind. But, again rook-pawn is an example - why no FILTERING? You do understand copyright law, and by extension the non-existent plagiarism law haha, allows for many cases where similar/identical does not mean copied and should be scrapped from consideration? Why no filter-scrapping?