Rybka Chess Community Forum
Oh, for God sake he neglected to inform you of his using Crafty as part of his learning how to program his chess engine-and you saw that now as an opportunity ban him. Nice cut throat tactic.
I never expected you to "get it" so at least I am not disappointed...
Copy code -> break rules. Regardless of the results.
You got him on a technicality re: Crafty! One down, Bob!
>Trotsky, just so you know that I believe Bob Hyatt is prone to hearing things from others and not checking them out himself, he can believe that a rumour is gospel truth, if it agrees with his internal view of the world.
Oh that is real tight Nick... very sound logic.
Bob posts something for all to see... not quite to "perfection"... you exaggerate it to a "he's prone to..."
You don't like what he's saying about Rybka... then fine... use your noggin to refute it. But potshots like these are quite disgusting... you can't prove he's wrong so you go to a personal attack.
Who of us hasn't made a mistake on a forum and possibly had to retract part of it or say, "Aha yes you are right... I am wrong here..." You playing the hypocrite Nick?
You wanna profess such a belief? Fine then next time bring along a half dozen examples to show "he's prone" blah blah blah. Btw...not ones with... "Then I was wrong in what I remembered".
What next? Start accusing him and Ken Thompson senility? And the rest of the panel with collusion?
I cannot believe
what I am hearing spill out of your mouth. You should be ashamed.
> So, we have, according to your assumptions, 1.6.1 leaves Vas's hand in 2004?
This being the 1.6.1 version that Hyatt is freaked out on? That got Vas placed finishing 53rd???? May be Tohno should have signed a complaint! He came in 54!
how is 1.6.1 == Crafty, when 3rd != 53rd?
Unknown and I don't care. Could be hardware. Could be some changes he made. Could be the opening book. Could be lag. Could be bad luck. It doesn't matter where it finished, that version is almost all Crafty. Feel free to look at the ICGA rybka/crafty stuff...
As far as I know it was given to several testers and Vas himself entered it in CCT.http://www.vrichey.de/cct6/
at the bottom of this page it lists those who used an operator so it appears vas operated himself.
You are going to try to go to any extreme possible to get out of this 1.6.1 vs Crafty "problem", right?
>Did you read through that?
You know the answer to that Bob, despite being generous here to allow turbo to reply...
And then what does he do? Give him a little wiggle room and he wiggles out with a "Let's not take the unreleased Rybka 1.6.1"
turbojuice1122, you wanted prove. The ICGA references were not prove enough for you. You inquired for more specific source, you were directed to specific Crafty source files, yet this is not enough or as you claim, there isn't anything there. I could go on and on giving you more & more sources and references but something tells me, based on recent disagreement, the same disapproval of the truth will continue....
If you've decided NOT to see the copied Crafty (and Fruit) codes found in Rybka by deeming it "phantom code", then it's obvious you're determine not to see it. You've made up your mind. This is your right but nonetheless, this does not remove nor disprove the Crafty-Fruit codes from/in Rybka.
But if you strongly feel Vas was wrongly convicted based on insufficient or false findings, feel free to take it up with the ICGA and maybe Rybka's ban will be overturned.
You cannot possibly be serious. Don't you see how wrong you are on such a juvenile level in trying to use this argument?
"I wrote a book 20 years ago, and Bob copied several lines from my book in one of his papers. The lines are in [this book]. I don't need to tell you which of Bob's papers these lines are located--me telling you that they were copied from the book I wrote is enough."
C'mon...either you can find the ~matching code~ in the two programs, or you can't. In order to show that you have found ~matching code~, you must find it in ~both~ programs. Claiming that some lines were copied from one program and appear "somewhere" in the other program is clearly not good enough--anyone can see that on the most elementary level.
You should try rewording your argument--you are looking very, very silly here...
Anyway, Bob also said that it's not really a big deal because others are using the same code in their programs.
These reports were not "undocumented". They are referenced in the ICGA report. They were discussed on CCC for a year as the Wegner report was compiled...
True. I was referring to the "pre ICGA investigation" reports era, which later made it into the ICGA reference reports.
Y'all don't understand turbo's point here...
He's trying out for Johnny's old spot as "Carnac the Magnificent".
TJ, Vas has admitted at least this much. Vas himself said he had borrowed "bits and pieces" of both Fruit and Crafty which were in Public Domain and then distributed these throughout Rybka. But you see, Vas told us that he changed the board representation model to bitboard from whatever it was with Fruit. That changes the code in a way where one can't necessarily compare in an apples to apples sort of way, but at the end of the day the basket of "fruit"(lol) comes out weighing the same semantically. I see nothing wrong with what he has done, so far as he has given credit where credit was due since beta. If he is guilty so is everyone else!
> But you see, Vas told us that he changed the board representation model to bitboard from whatever it was with Fruit. That changes the code in a way where one can't necessarily compare in an apples to apples sort of way, but at the end of the day the basket of "fruit"(lol) comes out weighing the same semantically.
That's basically what I'm trying to draw out, if any people think they can find "matching" code--what they're going to have, at best, is something like "well, this section in Crafty is kind of like that section in Rybka", but the code won't match.
Sorry, but in such places the code will match _exactly_. So long as you have the requisite skills needed to compare C and X86 assembly language code...
Sorry, this wasn't done in your report, outside of UCI parser and time management. Keep claiming it is though. If you say it enough times, surely it will become true, Pinocchio.
You do realize that just _once_ was enough? The ICGA rule does not say "only a little can be copied." It says original, which means _none_ was copied.
the evaluation stuff is probably over your head, so we can pass on trying to discuss that...
Nothing could get over your big head.
Unfortunately, the same can't be said for you. Which is what makes these discussions essentially futile efforts at education directed at the intentionally uneducable...
Yes. This is exactly what I need. Education from a loser who spent his whole life becoming an associate professor at a second rate engineering school.
First I am not in an engineering school. Second, I don't think a person on the planet considers UAB a second-rate university. We are a top-50 research university, in fact. But of course, as always, don't let a few facts get in the way of your personal attacks rather than technical rebuttals.
Eh? See rybka/crafty evidence.
> Sorry, but in such places the code will match _exactly_.
That's great! In that case, can you show us the "_exact_" "match" in Rybka?
Can you explain the relevance since Vas has already admitted doing this?
The relevance is showing what "copied" code actually looks like in these situations.
There are two classes. For one, if you look at the stuff produced by Zach and Mark, there are blocks of identical code. The first one that I personally saw was the one that caught my attention the most, the code using the setjmp()/longjmp() methodology to unwind and exit the search when time runs out. It is a horrible idea, and I can't imagine two different programmers using the same horrible methodology, in _exactly_ the same way and place in their code. That code is there for all to see. The code that does the time control stuff with the extremely odd 0.0 floating point constant in integer operations is there.
The second class is the evaluation, which could not be just copied and used as-is, it had to be converted to bitboards. Which changes the syntactical way things are done dramatically. So Mark W took each term and compared how they were computed, what was tested, in what order, what partial scores were summed, etc. Basically abstracting up one layer to filter out the board representation and look at just what was being done and how. And there he found identical "stuff". Exactly what one would expect to find, only if A (mailbox) was copied to B (bitboard) and then modified so that it would work properly. There's no other viable explanation. Take any two programs of your choice, and look to see if they evaluate things in the same order. In the same way. With the same (or even close to the same) partial scores. It just doesn't happen naturally, it happens when you copy and modify. If you don't understand that idea, then you will never be satisfied with Mark's part of the report. And a few here are in that boat. But once you understand the idea, it becomes "crystal clear" as to what happened, and exactly how it happened.
> And there he found identical "stuff". Exactly what one would expect to find, only if A (mailbox) was copied to B (bitboard) and then modified so that it would work properly.
I don't think that anybody could accept this statement after scrutiny. What one would expect
to find in such a case would be all of the terms matching--the same features in each evaluation function. Furthermore, this isn't an "if and only if" situation--while exact copying with modification would produce all matching features, all matching features does not imply evaluation code copying...only feature idea copying. In other words, you also get exactly what one would expect if Vas looked at the Fruit code very closely and decided, point by point, which features he wants to include in his program, especially since there wasn't a 100% match (Vas decided some ideas, i.e. roughly 25%, might not work so well in his program).
Let me repeat. He found the same evaluation features. Passed pawns, weak pawns, mobility, king safety, etc. He then looked at each feature, and found them implemented in the same way, testing for the same board characteristics, in the same order, using the same partial score values. The _only_ difference is in how the board is accessed, which changes the low-level way the code looks. But if you were to take fruit and rybka eval, and write them in a somewhat simpler pseudo-code, so that the board representation is hidden, and you use more "chessy terms" like this:
1. Is the knight on the 5th or 6th rank, and c, d, e, f files (this could vary significantly with different programs written by different people, as sometimes a knight on g5 is a good outpost knight. But here we only test for 8 possible squares, nothing more).
2. Is the knight on a square that is can not be attacked by an enemy pawn?
3. Is the knight supported by a pawn? if yes, add xx bonus.
4. Is the knight supported by two pawns? If yes, add yy bonus.
5. If the opponent has no bishop that can attack the square, and the opponent has no knight, then the knight can not be exchanged to eliminate it, add zz bonus.
There are other things one might add as well for where the opponent king is, is the knight closing a file that an enemy rook could occupy if it were not there, etc.
If all of those match _exactly_ then something is up. And there are several eval terms that have many more steps than those.
So if the only difference is the code to answer the questions because it has to be done differently for bitboards vs mailbox, then a reasonable person, and any computer chess author would think "something is fishy here."
And the more such matches you find, the more fishy it becomes.
I didn't read all the reports or follow all details but you convinced me with that post that Vas started Rybka work using some other code.
None the less, it is also to me obvious that even in Rybka 1 he did bring his own stone to the edifice since at release of R1.X, Rybka was already so far ahead of all other available engines.
Therefore to me, he did bring with Rybka 1.X his own stone with what I would call an original Engine.
So let’s say Vas was lazy and didn't start his work from scratch..... Was all that fuss justified? I believe not.
Should Vas be penalized for that? I don’t know but definitively what happened is disproportionate.
The problem was, (a) he did this over several years and tournaments. He denied doing it. repeatedly. And he refused to participate in the investigative process. I don't see any other action the ICGA _could_ have taken.
Well, this is where opinion differs.
And differing opinions are fine.
I would think that the above pseudo code is an "idea" that could be used by others. I'm just starting to work on my eval and would think it was ok to try to add the above. The actual code would certainly be different (since I'm a real amateur). I would have thought of 2 through 5 myself, since that's pretty basic. I probably wouldn't have thought of 1, so would it be considered copying if I used it?
I guess to answer my own question, you'd have to consider the total eval to determine whether it is copying?? Even though I'm sure not a single line of code would match? Sort of a blurry line between right and wrong here...
There are always going to be some things that will match perfectly if one copies and then translates from one data structure to another, because there are some parts of any procedure/function that are board-representation-independent. My point was that if you take program A and reduce each eval term to pseudo-code as in my example, and then do the same for program B, if they match perfectly in multiple places, there is a high probability that one is a copy of the other. And the more examples you enumerate, the higher that probability. You could do the above outpost knight code an a _bunch_ of different ways. Even having parts of that code scattered around in other places in your evaluation. For example, your pawn evaluation code might produce a list of squares that can never be attacked by pawns of each side, and then you use it in the knight evaluation code. Or you might incrementally update that information in MakeMove()/UnmakeMove() and use that in evaluate knights. When they match exactly, the two programs were not developed independently.
It is an almost grey area, yes. But once you look at the code carefully, and if you were to take each version and remove the bitboard/mailbox specific stuff only and replace that with pseudo-code, a lot of similarity is a problem. If you take a half-dozen of today's programs and look at what they do, how they do it, and _where_ they do it, nothing looks similar at all. yes, most handle isolated or weak pawns, passed pawns, king safety. But no two do it the same way using the same steps, and the same partial scores.
Just doesn't happen naturally.
Again, the "exact" matches are in the implementation of the features, something that is quite expected, and quite legal, as long as it doesn't go too much further than that. These types of matches are what anyone would expect for someone using Fruit as a basis for what he wants to create, and who wants to make sure to include multiple features from Fruit. I don't see how you can tell anything about the exact way that the code was written by feature comparisons. If the same bonuses are added, great--but the code can still be written differently, and bonuses are not subject to copyright anymore than are 1.e4 and 1.d4.
You miss the point, and there is not much more I can add to clear up your misunderstanding. If you tell two programmers to "go write some code to evaluate (say) king safety. Here's what I want you to include. King tropism (how close is each piece to the king) done in an exponential manner so that a queen + piece or two is _far_ more dangerous than a couple of minors that are closer. Include friendly and enemy tropism. Consider pawn shelter including weak squares (f3/h3 after you play g3 as an example) and also handle open and half-open files against the enemy king.
Then you can start to make the "what" more precise by suggesting numbers or ideas of how to evaluate each part. And when the two programmers finish, hopefully they will have produced code that handles what you dictated. But they will not be similar in the "how" they do the stuff. That's the point. When the what, the how, the how much are all the same, the two codes are _not_ independent. If you have enough such terms in the evaluation, then the two evaluations are not independent about the only way that can happen is if one copied the other, even if numbers were changed...
You have to (a) understand programming; (b) understand how many different ways there are syntactically to express an "idea" Then you realize that while lightening might strike twice in the same place, once, it won't do it a number of times in different places in the code. It just doesn't happen.
What I don't see is how the methodology used for the "overlap %" shows the code being the same as opposed to the features being implemented in a similar way. From what I see of how these numbers were tallied in the report, this shows something quite a bit different than necessarily code copying (though if code is copied, the numbers will also be high--in fact, they would be 100% on each term, with no exceptions; naturally, this isn't the case).
We looked at the code to see how rybka 1.0 beta computes the eval for a single idea. The fact that both have the same idea (backward pawn for example) is not a problem. But if they do everything exactly the same way, same order, to do that evaluation, that is highly unnatural.
Unnatural, yes--very much so. That is because Vas based Rybka 1.0 Beta off of Fruit. But there is nothing wrong with doing it this way if he didn't copy code.
If he didn't copy code, he wouldn't do it this way. But based on the evidence, he took the fruit eval and converted it to bitboards, which means he did everything in the same order and way, excepting for the different board representations. that is no more original than translating a book from English to Spanish. Or even English/printed to English/Braile.
If all he did was translate to bitboards, then (a) there would be a 100% match on all of those features, and (b) there wouldn't be a 40-point elo gain in the 32-bit version. Also, how do you know what he "wouldn't" do? If he's looking back and forth at Fruit while writing his program, this is precisely how he would do it if it makes sense to do so.
First, who said "all he did was..."??? We said "that was his starting point." Clearly he added code later, and continued to add it to keep Rybka ahead of the pack. And nobody I know has said otherwise. But it is that "quick-start" copy-job that got him there so quickly, and which is against ICGA rules...
If you are "looking back and forth as you write" you are _not_ writing. You are translating. And that _is_ what I believe he did. If you read thru fruit and thru Crafty, and thru other programs, and made notes, and then wrote your evaluation code, it would not have identical parts in common with any of those, because you didn't copy / translate... As a simple example, pick a dozen people you know, and ask them to write one paragraph of 500 words or less, describing some really well-known thing. For example, how to change the spark-plugs on a car. Then see how many in that group produce an indentical paragraph of words. Then look for similar sentences in the same order. Eventually you give up because even that simple task can be specified in a remarkable number of different ways, yet all do the same thing.
In your spark plug analogy, all that this evaluation feature match test did was find out whether the same general steps of changing a spark plug are present. As for the order, nobody said that you're not allowed to see how someone else did it and then do it yourself.
Again, do what I asked. Find two people that know how to change spark plugs. Ask then independently to write down a specific set of instructions on how to do that. Tell them to be _very_ specific, including what tools to use, what to do, what order to do it in, etc. Specify the specific vehicle you are going to work on so that they have every possible bit of information they need.
Then compare the two. They will _not_ be the same. Simple examples. Assume a front-wheel-drive V6. Which plug do you remove first? 6 choices. I start on the back because they are the hardest. Others start on the front because they are easiest. 50-50. Once you pick a bank, which one first? Do you gap the plugs one at a time, or just before you install each? Do you remove them all and then replace, or do them one at a time? Do you mark the plug wires to avoid screwing up timing, or do you change one at a time to avoid any confusion on reconnecting? Do you re-clip the wires into the loom as you work, or at the end? There are so many ways to do this, that the two people won't agree step for step. Following either should get you a running motor. But the steps and their orders will be different. If they come up identical, what would you think? I would be certain that they either did the project together, or that one copied the other...
There's just one problem: this isn't a test over whether a person is able to change spark plugs on their own. Copying ideas is okay. We STILL haven't seen ANY copied evaluation code! All that we've basically seen is similar pseudocode in some places (to wit: Mark's report).
For the Nth time, look at Zach's report that I gave a link to. Scroll down passed the PST data. Then tell me you don't see exact code matches, with the code presented side-by-side, fruit on left, rybka 1.0 beta on right. As I have _repeatedly_ stated, you have to read the report, or you won't see anything. Zach's comparison is the first one mentioned in our report...
Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill