Code: Select all
op[me] += RookKingFileOpening - RookSemiKingFileOpening;
I guess another way to look at it, is that Zach "un-folded" one value into two, so he could assign them the same chess-programmer-meaningful names that were used in Fruit.wgarvin wrote:No. What I'm saying is that the semantics described in Zach's document for the "feature" which Fruit calls RookKingFileOpening, are also present in Rybka.
Now that I actually look at Zach's document, I see that the Fruit code using RookKingFileOpening actually looks like this:The compiler obviously folded the two constants together. Optimizing compilers usually do this even at -O0 because its faster than not doing it.Code: Select all
op[me] += RookKingFileOpening - RookSemiKingFileOpening;
You could always try demonstrating "fruitification" with another program on as many points to make your point. If you're unable to make that work, I'd say such protests are out of gas, if not hot air. You might then be forced to agree with what it obvious to most everyone else, that odds are indeed "1 in a billion".Rebel wrote:No, please don'tBB+ wrote:I removed the comments, as it appears that's been called "fantasy code". Perhaps I should just give up trying.What is this code for? - please don't tell me it's from the UCI parser....
But as you are used to criticize RF postings here I was wondering why you (yet?) did not address the what's called Fruitication issue.
orgfert wrote:You could always try demonstrating "fruitification" with another program on as many points to make your point. If you're unable to make that work, I'd say such protests are out of gas, if not hot air. You might then be forced to agree with what it obvious to most everyone else, that odds are indeed "1 in a billion".Rebel wrote:No, please don'tBB+ wrote:I removed the comments, as it appears that's been called "fantasy code". Perhaps I should just give up trying.What is this code for? - please don't tell me it's from the UCI parser....
But as you are used to criticize RF postings here I was wondering why you (yet?) did not address the what's called Fruitication issue.
In fact, this was/is the very conclusion I arrived at. Otherwise these folks would have to be completely devoid of common sense, although that shouldn't be completely dismissed either. Too bad they can't abrogate the ICGA rules and/or GPL license. Their viewpoint & history of Rybka's sacrosanct is over.hyatt wrote:Although in this case, I think they understand, they just want to create a false/deceptive impression that this stuff doesn't work. Which would be news to students in my CS330 class that do some of this.
The following just might fall within the scant capabilities of Rybka embusques. Determine if any engines beside Fruit and its un-cromulent offspring find themselves at sea in this position.Rebel wrote:I assume there is rational explanation for this ...
It is however, only one position. I found that the last 100 versions of Rainbow Serpent actually could not solve this anymore, all of them showing 0.00 scores, and the ones before build 224 could. It had nothing to do with Transposition Tables in this case, but fawlty Step 14C "Double Pass Stand Pat Futility Pruning"orgfert wrote:The following just might fall within the scant capabilities of Rybka embusques. Determine if any engines beside Fruit and its un-cromulent offspring find themselves at sea in this position.Rebel wrote:I assume there is rational explanation for this ...
http://www.talkchess.com/forum/viewtopi ... 233#427233
I can assure you that the affected code is not present in Fruit either/or Rybka, unless someone copied it from the free search.cpp that is out there somewhere, but seeing it is buggy as #$@ I hope that no one has. Anyway thanks very much to Harm-Geert working on Sparctacus endgame theory for the Open NK next weekend, or I would probably never have found this out, I never test any of those changes by actually playing testgames, so from time to time the engine has to undergo serious regression therapy. In this case of about 100 versions.I don't know exactly what these terms mean [to Dagh], but it probably doesn't matter (is being too "dependent" sufficient as a sign of "non-originality"?). In the end, there will be some subjective determination, as with "substantial similarity" in general. E.g., the LION++ decision had to consider what "close" derivative meant.Uly wrote:What is being discussed is if the report manages to show proof of "code copying" or just of "dependence" [Dagh Nielsen]
I usually stop reading RF threads when they exceed one page (50 posts). If I find time, and find it to be relevant, I might say more about any issue you raise.Rebel wrote:But as you are used to criticize RF postings here I was wondering why you (yet?) did not address the what's called Fruitication issue.
Zach is the more relevant person to ask about his document.Rebel wrote:I am also curious if you can explain why dozens of values simply can't be found in the R1 executable, a few examples.
From Zach's document: