The Charter did not mention rule 2. It mentioned cloning and derivatives. Hence rule 2 was a fall back because you were unable to prove cloning or derivative.
Stop playing games.
If you must, however,
"Each program must be the original work of the entering developers. Programming teams whose code is derived from or including game-playing code written by others must name all other authors, or the source of such code, in the details of their submission form. Programs which are discovered to be close derivatives of others (e.g., by playing nearly all moves the same), may be declared invalid by the Tournament Director after seeking expert advice. For this purpose a listing of all game-related code running on the system must be available on demand to the Tournament Director."
See that big fat bold word in rule 2? Appears TWO times. That would be "derived" and "derivatives." So what, exactly, is this incredibly insigntful point you are trying to make? That we WERE supposed to be investigating whether Rybka was a derivative of fruit, because that violates rule 2? Isn't that EXACTLY what I said? And "I am so boring?" Does boring somehow mean "one who reads and understands written text" in your universe???
I will say it again, with Rybka 1.6.1 there is absolutely irrefutable evidence of code copying. With Rybka 1.0 beta, there is strong evidence of non-literal copying, because of the necessary bitboard changes...
Arent you a bit obsessed like the character played by De Niro in Meeting the parents? ;-)
The problem is that he originally copied my code completely, made a few minor changes that were not even apparent when looking, and then claimed that was his original code. He claimed the rybka development was ALWAYS incremental, that is, no "throw everything out and rewrite". Just a steady series of changes. That is also false, as can be verified by comparing the last "private version" 1.6.1 to the first public version 1.0 beta. They are nowhere near similar in terms of search, eval, UCI, etc. Because that code was "non-incrementally copied directly from Fruit, and then modified to work with bitboards."
So why is this supposedly "OK?" Because of the strength of Rybka? All other rules take second-chair to "improving strength at all cost?"
> ... waited for such a development of stolen Rybka source by anonn vilains
to my knowledge Rybka source was never stolen
> All the hippo robbo shit is criminal and evil
If you are talking about Ippolit/Robbolito, there is nothing criminal about them.
R/E for personal, private learning is ok and couldnt be forbidden anyway but then publishing the results that should be alienated in our community. Could you explain why these vilains remain anons if it were legal what they have done?
> R/E for personal, private learning is ok and couldnt be forbidden anyway but then publishing the results that should be alienated in our community.
It's forbidden by EU law to publish RE work, for the USA it's unclear.
So the ICGA (headquarter London) technically broke the EU law publishing the Zach and Watkins documents.
Ippo/Robo etc is more complicated. We have Vas' statement that the R3 hackers were so kind to announce Ippo.
Question is if that is worth all the debates at all!? We are not talking about psychology but right or wrong in computerchess, no?
> Like yourself, you are defending Vas but you are also defending his enemies at the same time.
We are obvious on the same track, have the same goal, there is no mistake here. Nevertheless I believe that only debate plus time can resolve the issue and that too strong language use works counterproductive although releasing your true feelings as an exception to the rule is good and sometimes even needed when dealing with certain characters.
It might be worth asking ICGA where they file?
It is difficult to see how the publishing of RE-ed source is not a copyright infringement. Attacker Hyatt claims the defence that "publishing copied RE-source" is just fine, but we would argue that since the "copying" or rather use of ideas, was not at source code level, was overlapping only, and there is plenty of "own ideas" in there as well that this is no defence.
> Are you sure the ICGA is London based?
Don't know for sure. I see a London address but lately saw the University of Tilburg (NL) listed as well.
> It might be worth asking ICGA where they file?
The FIDE might know
> What we found was above ANY reasonable limit. Suppose you say "no more than 10% of the eval code can match". Rybka 1.0 beta and Fruit were WAY beyond 10%. Beyond 50%.
Rybka 2.3.2 only matched 8 out of Fruit's 29 eval features. And note, this is when talking about a match in the most abstract sense, as in, does the same thing in a chess/math-semantical way. There were probably fewer than 8 matches in an algorithmic sense, and so far there is no evidence whatsoever for any match in a source code sense, at all.
So you are either lying or being intentionally dishonest.
Bob, I wanna thank you for the first part so far. Please let's continue that soon. It was really a good experience to be able to concentrate on my certainly mostly lay questions. Thanks for all the for me deeper explanations. I hope we can have that phone call and that then I can understand you speech. Honestly I watched a couple of Charlie Sheen in Two and a half men and he was really hard to understand for a German. I guess you must have a similar accent with letting many letters drop on the soil. :)
>> What we found was above ANY reasonable limit. Suppose you say "no more than 10% of the eval code can match". Rybka 1.0 beta and Fruit were WAY beyond 10%. Beyond 50%.
> Rybka 2.3.2 only matched 8 out of Fruit's 29 eval features. And note, this is when talking about a match in the most abstract sense, as in, does the same thing in a chess/math-semantical way. There were probably fewer than 8 matches in an algorithmic sense, and so far there is no evidence whatsoever for any match in a source code sense, at all.
> So you are either lying or being intentionally dishonest.
Only 2 PST in R2.3.3 out of 10 could be generated with the Fruit code, modifying the constants and multipliers. These two are based only on the centralization vector [-3,-1,0,1]. There is another that is too trivial to consider (Rook opening, with a linear bonus for a, c, d and e files). The 12th is initialized to zero (Rook endgame).
I personally verified that bishops and knights worked. And pawns except for the two central squares and they would match for one, the endgame bonus for the other. You don't think queens and kings match? And in light of those matching, the rook matching (even though it is very simple) seems clear enough to include.
What, exactly, are you talking about when you say only 2 match???
Zach gave the code. You should try running it and comparing...
> What, exactly are you looking at?
> I personally verified that bishops and knights worked. And pawns except for the two central squares and they would match for one, the endgame bonus for the other. You don't think queens and kings match? And in light of those matching, the rook matching (even though it is very simple) seems clear enough to include.
> What, exactly, are you talking about when you say only 2 match???
> Zach gave the code. You should try running it and comparing...
R2.3.2 not R1. Please read the message you are replying to.
But that begs the question, "what is the point"? Rybka 4 might match even fewer.
However, at least for 2.3.2 the eval terms were still highly correlated...
> But that begs the question, "what is the point"? Rybka 4 might match even fewer.
Just setting the record straight for this particular issue, which is not very clear in the report.
> However, at least for 2.3.2 the eval terms were still highly correlated...
When we were talking about PSTs, I therefore assumed 1.0 beta as nobody has mentioned 2.3.2a PSTs here...
> The report from Zach is CLEARLY about Rybka 1.0 beta, would you agree? Nothing else mentioned? Mark's paper is where the 2.3.2a evalcomp is done.
> When we were talking about PSTs, I therefore assumed 1.0 beta as nobody has mentioned 2.3.2a PSTs here...
The report from the ICGA, says (page6):
"Here is my list of differences in eval between Rybka 2.3 (mid Feb 2007)
and Rybka 1.0 Beta....."
"PawnFile PST is now [-4,-1,0,+1,+1,0,-1,-4] rather than -3 on a/h files."
That is wrong (all the ranks are different) and besides, grossly misleading, making it look like the PSTs were conserved, when they were not.
The report has an appendix with the PST from 2.3.2
Do you even know what it was reported?
Nobody else has NEARLY as much in terms of perfect matches...
> Nobody else has NEARLY as much in terms of perfect matches...
How do you know, you didn't investigate all the other engines that participated in the ICGA WCC did you !!
So we were just "lucky" to find Rybka, and not find any other program so similar to fruit???
> What does this show?
That there is no hard evidence for copying.
Some quotes from Zach, who is sure about Vasik guilt by other considerations than his work alone.
Zach Wegner : The semantic equivalence stuff is more about trying to prove copyright infringement in a case with imperfect information (i.e., we don't have R1's source code). I would have a different view of the case if I believed that Vas had coded all of Rybka from scratch, and only used Fruit as a source of ideas.
Zach Wegner : Coming back to R1/Fruit, yes, if you look at each example in detail, you can't say there is much hard evidence of direct code copying. As I said to Vas, I'm only completely certain that three characters were copied ("0.0").
> As I said to Vas, I'm only completely certain that three characters were copied ("0.0").
Well, Zach, you cannot be certain of that at all. Vas may have written 0. and not 0.0. You'd need to understand a little bit more about compilers to appreciate this of course. If you read the 10 page summary from CB http://chessbase.com/news/2011/riis01-summary.pdf (page 5) you'll see that such an error is not uncommon for large shops.
Any programmer will tell you how easily this happens and how often it has happened to them in their programming.
Matthias Wüllenweber has seen it himself in CB code.
It would seem that Zach is completely certain of nothing.
0.0 is completely unnatural in integer code. The keys are too far apart to make it accidental. This pig is NOT going to fly...
> No "chess programmer" will tell you how easy that would be to do. I have not done it once in 40 years now. Simply no floating point in any of my code that "plays chess".
> 0.0 is completely unnatural in integer code. The keys are too far apart to make it accidental. This pig is NOT going to fly...
"." and ">" are not so far apart. In fact, they are the same key! (with and without the shift)
if (x>.0) //">" key gets stuck, with and without shift, compiles to (x>0.0)
PS: .0 is another option, not only 0.
People did not think about it.
The code was
if (movetime >= 0.0)
So > is irrelevant since the = follows before you get to the constant.
Too much time being spent dreaming up possible explanations. None of which really rise to the level of even "barely plausible". It is hard to get that . in there even with > and . sharing the same key, because the = was also present... This is clearly a case for occam's razor when there is other code around that 0.0 line that matches well with Fruit...
> The code was
> if (movetime >= 0.0)
> So > is irrelevant since the = follows before you get to the constant.
> Too much time being spent dreaming up possible explanations. None of which really rise to the level of even "barely plausible". It is hard to get that . in there even with > and . sharing the same key, because the = was also present... This is clearly a case for occam's razor when there is other code around that 0.0 line that matches well with Fruit...
> if (0.<=movetime)
Nice! It was this "float" that bugged me more than anything else. Vas told us that he definitely wrote his own code and we asked him what this float was doing in there. Vas said he didn't know, thought it was weird and perhaps a bug even. We didn't know what to do, on the one hand we really believed him that he wrote his own code but on the other this looked like a copy job. Then when it was pointed out by an experienced C/C++ programmer that Vas could have written 0. it all made sense. At that point any sane person breathed a sigh of relief and realized that Vas was true to his word. It's bizarre how things happen, if only "Rick Fadden" had known a bit more about compilers I doubt that this witch hunt would have ever happened in the first place.
The pre-Rybka's have the UCI protocol inside while Crafty is Winboard. Looking at the UCI code in the pre-Rybka's it has the below odd kind of flag which is in Rybka also (see Fadden's post) but not in Fruit.
depthLimit = 0x7FFFFFFF; // where in Fruit ???
It proves Vas had its own UCI code before Fabien even started with Fruit and that this same UCI code is in Rybka, not Fruit's.
0.0-gate is no longer.
In other words Vas spoke the truth last month.
There isn't much I can help with here. I don't know where the 0.0 came from. It's definitely weird/wrong.
Rybka was UCI from the beginning, even back when everybody was using WinBoard. I would say that every two to three years I do a big cleanup of this code. This might take a few hours, and then I won't touch it until the next time. My first UCI parser actually used inheritance, I was extending UCI to do some testing, but that was gone even before Rybka 1.
Vas HAD to do his original UCI code. He copied Crafty, which had none.
That is a "newsflash"???
BTW there is no 0.0 and such in 1.4 - 1.6.1, so exactly what does this have to do with anything??? Crafty had its own built-in time control stuff...
As far as "depthlimit" I have no idea what it does. Not used in the Crafty code he copied extensively...
None of this means a thing regarding whether or not he copied Fruit code, of course...
Fruit 1.0 - March 16, 2004
Rybka 1.4 - March 31, 2004
Rybka 1.6.1 - April 19, 2004
1. Crafty is winboard, always has been.
2. Rybka 1.6.1 is UCI. Thus Vas code, before Fabien.
3. The 161 UCI time-control code contains a special mark: 7fffffff
4. The same 7fffffff mark is found in the Rybka 1.0 UCI time-control code.
5. The 7fffffff mark is NOT in Fruit.
Conclusion: there was no copying of Fruits time control, it's Vas own code.
http://www.talkchess.com/forum/viewtopic.php?p=187290#187290 (as referred in Watkins document chapter 6.3.2 Time management)
I think it's simply a case of automatically thinking 0.0, and typing this, and that error staying in. This is also more likely than copying it over from Fruit, though it might have occurred from looking at the Fruit code while writing the Rybka code.
The entire 0.0 thing is an absurd argument. If it happened in analogous places multiple times throughout the code, then there would be something there. But just happening once means nothing. Of course, the other side will come back with, "well, when you combine this with all of the other stuff that is found, you get a much more complete picture", when in reality, each element of the "other stuff" has equal to or less validity as this. They keep using the "complete picture" argument, when in fact, none of the pieces of the picture gives anything consistent. You can create a theory in which some of the parts are broken, with most of the parts being solid, with the understanding that the broken pieces are not so important and will probably be corrected at a later date to make the standing theory cleaner and more complete, but you can't create a theory in which all of the parts are broken.
Again, lots of implausible explanations, when the obvious one is laying there in plain sight...
> Not correct. Would have to be 0. < movetime
1) You mentioned it was <= rather than < (or >= rather than =). Make up your mind!
2) What difference does it make?
> Again, lots of implausible explanations, when the obvious one is laying there in plain sight...
That's why it was important...
> This is clearly a case for occam's razor
"Occam's razor is not an embargo against the positing of any kind of entity, or a recommendation of the simplest theory come what may.
The other things in question are the evidential support for the theory. Therefore, according to the principle, a simpler but less correct theory should not be preferred over a more complex but more correct one. It is this fact which gives the lie to the common misinterpretation of Occam's razor that "the simplest" one is usually the correct one.
For instance, classical physics is simpler than more recent theories; nonetheless it should not be preferred over them, because it is demonstrably wrong in certain respects."
One has to use their God-given "common sense" when something has to be evaluated by inference...
(I did this for my own code, and I found the typo zero times in it)
Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill