What's Vasik Rajlich doing today?

[vittyvirus]

They argue with logic and proofs, and people will choose their paths anyway. You're telling Ed that he doesn't know Computer Science, do YOU know who Ed is?

Terry knows. What he is doing is trying to shut down this thread by posting insults. Nice tactic. Has often worked in the past.

That's a lie, but lying is something that comes easy to you.

You're sabotaging the thread and lying and blaming me. What a manipulator you are Ed. Now you will likely do what you can to have me ban. That's what I call a lowlife tactic.

You should get banned. You should not go around belittling a man who obviously is quite or at least was a substantial figure in computer chess. There are reasons why people have the opinions that they do, and everyone is entitled to their opinions. Ed has a lot of good, solid evidence to back up his case. More than likely he probably does have a lot of truth to what he is saying (he actually backs up his claims...). Your claim to simply suggest that any reasonaby intentlligent person should just listen to Hyatt (I do not care about his expert status) is ridiculous. Reasonably-intelligent individuals here in this community should understand that many authors within the ICGA had motives to find ways to get rid of Vas. The guy was winning all of their tournaments; Rybka was unstoppable. That is motive enough. I believe that Jealousy played a huge part into the ICGA's obvious desire to get rid of Vas; do you really think the copying of code had anything to do with this? Seriously?

Ultimately, do you not see how pointless this entire debate between both Hyatt and Ed is? Nobody cares about the ICGA (and Rybka is also now dead). They are a dying organization with engines extremely inferior to the world's best. The nTCEC has taken over, whether you like it or not, because Martin provides a tournament with many games and many months of competition compared to the joke run by the ICGA. They, to me, and to a lot of the computer-chess community are the ones lying since their rather bold claim that they run the "World Computer Chess Championship" is honestly sadly laughable. Again, it does not really matter. The community chooses where things rightfully go from here - and the ICGA is not found in the books. 

Rybka is its own engine. Its Elo being that of approximately 3160 found on the CCRL website is evidence enough. Vas was no idiot. He knew exactly what he was doing. And he clearly is a more talented programmer than a lot of the authors from the ICGA (his engine's dominance proves this despite the accusations). 

No matter the words discussed here on this forum, Rybka will always go down in history as being one of the strongest computer chess engines relative to its time period of course. 

Vas did exactly the right thing walking away from an obviously pretty sad ICGA organization. 

I am happy to see someone with stature stand up for Vasik.

I couldn't have agreed more...

[michiguel]

It's what I said all along, if you can't proof a derivative work then what the verdict was about is the usuage of "too many" ideas.

And even that is wrong.

Every major evaluation ingredient is coded differently, mobility, king safety, passed pawns, double pawns, backward pawns, Rybka is missing Fruit's late endgame knowledge, Rybka has a material table – different from Fruit. Rybka does not contain Fruit's quad function, Rybka’s trapped bishop evaluation is different, rook evaluation is different, bishop pair evaluation different and most importantly, Fruit evaluates in stages in a unique way whereas Rybka adds directly to its score (as every other program on the planet does).

Other key differences between Fruit and Rybka:

1.Time control is different
2.Fen parsing is different
3.Rybka extracts the mainline from the transposition table (TT), Fruit via the classic triangle table
4.Rybka 1.0 beta displays a mainline of maximum of 10 moves, Fruit produces much longer variations
5.Rybka uses a bitboard board representation whereas Fruit is mailbox
6.Rybka’s pawn value is 3200 (which is unique), Fruit uses the classic value of 100
7.The order in the evaluations of Fruit and Rybka are not similar
8.Rybka has lazy evaluation, which is absent in Fruit
9.Futility pruning is different between the two programs
10.Rybka uses Late Move Reductions (LMR) whereas Fruit uses history reductions
11.Fruit uses a history table which is absent Rybka.
12.Fruit only has one evaluation table (king safety) while Rybka has many
13.The two programs have a different move format
14.Rybka does not handle promotions to minor pieces
15.The two programs have different hash table code
16.They have different handling of repetitions and the 50-move rule in search
17.Fruit maintains piece-lists which are not present in Rybka
18.Fruit maintains a pseudo "bitboard" for pawns, Rybka has the real thing.
19.Contrary to Fruit, Rybka needs to update 4 rotations of occupancy bitboard
20.Contrary to Fruit, Rybka updates a rough estimate of material balance with weights of 1:3:3:5:10 (in the evaluation this value is then corrected by a delta obtained from the material table)
21.Fruit has a 16*16 square mailbox, Rybka has an 8*8
22.The programs have different Zobrist hash keys
23.The programs have different user interface options

We found 35 indisputable differences (some of which are very fundamental), not counting the ones that are debatable such as the Piece Square Tables (PSTs) and the contents of the TT.

Doesn't fit the definition of a derivative work.

Differences do not matter, it is the similarities and the number of them that violate rule 2. 75% of what you cite above comes from the mailbox/bitboard differences. Irrelevant in this context.

Nice try, no cigar.

All the evaluation elements were removed from their data structure, either mailbox or bitbaord. Every evaluation ingrediënt is coded differently, thus NO SIMILARITY.

What's left for you was to find traces of clear code copying. And as you admitted you did a lousy job. No surprise, because it wasn't there.

Double strike.

Not even a reasonable try. One can read Zach's report to see that there WERE many similarities. One can look at parts of the C from fruit, and compare it to the asm from rebuke and see the similarities.

Like Andrew Dalke said, The Zach Wegner document is highly misleading.

Furtmermore -

1. Its style is accusing from the beginning to the end, the reader is told what to think, it doesn't meet any scientific standard.

2. The many errors Zach made, especially his analysis of the Material Imbalance Table (a total new evalution technique now in use by many) is total garbage and yet Zach couldn't resist the temptation to link it anyway to Fruit as a similarity. Shameful.

3. In his fervor and already closed mind that Vas copied Fruit he missed all the evidence that unburdens the alleged similarity accusation at every evaluation element. In mobility, king safety, passed pawns, double pawns, backward pawns, even the trapped bishop evaluation, rook evaluation, bishop pair evaluation different and most importantly, Fruit evaluates in stages in a unique way whereas Rybka adds directly to its score (as every other program on the planet does) which Zach totally ignored also. No surprise here, Zach wasn't looking unburden evidences that would plea Vas free, no, convinced in his mind as he was Vas copied Fruit he only looked for signs of similarity, classic tunnel vision thinking. In science you you present the facts objectively. That's not what Zach did.

Some of us programmers have done more than just believing Zach's accusing document and critically scrutinized every accusation Zach made and concluded it is a bogus document.

One can look at Vida's decompilation of Rybka's hashing code, showing both bugs and unnecessary information. The SAME bugs and unnecessary information found in BOTH.

1. There are no bugs another sign that you don't have done your homework again. Both gents (Vas and Fabien) have discussed various search techniques in public (CCC) in the years 2003/4. Look it up! For that purpose I have written a special utility [ http://www.top-5000.nl/ccc.htm ] because I wanted to know what kind of information was shared during the pre-Rybka years.

They discussed and both tried the then much hyped and popular MTD(f) search technique among chess programmers, in the end both decided it did not help their program. Now as you very well know MTD(f) requires a strict data structure with 2 extra scores. Claiming similarity is bogus because the data structure for MTD(f) is OBLIGED.

What you call a bug is also wrong, switching back to a non MTD(f) search has the advantage you can leave the data structure in tact (including the 2 extra scores) and easily can try out other search techniques without rewriting the whole TT again. What you call a bug in fact is FLEXIBILITY. Read the old threads of 2003/04, it's all there.

2. Hash-table code contains 2 main elements:
2a. the update part, position is stored in the HT;
2b. the retrieve part, position is checked if present in the HT.

Regarding 2a - you know very well this part is where the intelligence and creativity of the programmer resides and it is TOTAL different than Fruit. And you know that.

Regarding 2b - Pretty much forced code based on the data structure, you know that as well. Not much choice in coding.

Like Zach, it's your subjective (and already closed) mind that wants to interprete things as evidence against Vas without looking at it from an objective point of view.

Last (and once again), you guys investigated the wrong version, a version that did not play in an ICGA tournament. The first Rybka version that played was 2.32a. In there the HT is completely rewritten from 16 to 8 bytes per entry and any programmer knows what that means: Nothing like Fruit.

I am going to defend Zach a bit. At the time Zach wrote his analysis, it was not done for formal prosecution purposes. It was done to catch every single drop of similarity as part of previous forum discussions trying to understand the relationship between R and F. He wrote the document, as anybody would naturally be in that situation, in a biased form. He shared it with me long before it saw the light. I truly appreciated his work because it allowed to understand many things. It served an important historical purpose, which was to understand the big influence Fruit had on Rybka (Vas acknowledged that, but we did not know where and how). For that reason, you would poke on R1 and not R2. I would understand that in that context.
**BUT**, fast forward two years, that document cannot be used as an element of uncontested evidence in a case like this. It is quite possible that the document could have been written differently in different circumstances.

We need to understand what he did, when he did it.

Miguel

[bob]

Not sure what this has got to do with the issue of whether rule #2 is about copyrights. And it seems to me that in either case it is not the number of differences that is relevant, but how much was similar.

Did you read? Nothing is similar.

Every major evaluation ingredient is coded differently, mobility, king safety, passed pawns, double pawns, backward pawns, Rybka is missing Fruit's late endgame knowledge, Rybka has a material table – different from Fruit. Rybka does not contain Fruit's quad function, Rybka’s trapped bishop evaluation is different, rook evaluation is different, bishop pair evaluation different and most importantly, Fruit evaluates in stages in a unique way whereas Rybka adds directly to its score (as every other program on the planet does).

You never looked at the evidence.

Even the most simple evaluation of all (the double pawn) is evaluated differently. Fruit has a fixed penalty value for the mid and endgame. Rybka only evaluates for the endgame. Just to give you an example.

Seriously, "nothing is similar"??? Hashing is almost a perfect match, the one difference came because he split it up into separate pieces as a speed optimization. Nothing similar in parse_go, no mysterious 0.0 constants in more than one place? Nothing similar in the evaluation? And then there were the earlier rybkas as well. Nothing copied in those either???

Again with the 0.0? gosh...

Miguel

Still sitting there in plain sight in multiple places. Still no explanation other than maybe a typo, which is less likely than maybe it was copied.

[Rebel]

Sure, my time to say something positive. I never questioned Zach's integrity. On the contrary he has been quite honest, not afraid to admit mistakes, even in public, example from Rybka forum.

This analogy only makes sense if you believe that the people claiming that R1 is a Fruit derivative are deliberately misleading. I know you can't take my word for it, but I certainly haven't been trying to mislead.

In retrospect, I regret only publishing evidence relating to the evaluation, since it's fuzzy in many ways, and people can easily see it as "circumstantial". A lot of the evidence hasn't even been written up properly. I view this as my own failure in many ways, but there's only so much effort I'm willing to put into this.

He didn't expect the magnitude of what his document set in motion neither the magnitude it would backfire on him.

[bob]

It's what I said all along, if you can't proof a derivative work then what the verdict was about is the usuage of "too many" ideas.

And even that is wrong.

Every major evaluation ingredient is coded differently, mobility, king safety, passed pawns, double pawns, backward pawns, Rybka is missing Fruit's late endgame knowledge, Rybka has a material table – different from Fruit. Rybka does not contain Fruit's quad function, Rybka’s trapped bishop evaluation is different, rook evaluation is different, bishop pair evaluation different and most importantly, Fruit evaluates in stages in a unique way whereas Rybka adds directly to its score (as every other program on the planet does).

Other key differences between Fruit and Rybka:

1.Time control is different
2.Fen parsing is different
3.Rybka extracts the mainline from the transposition table (TT), Fruit via the classic triangle table
4.Rybka 1.0 beta displays a mainline of maximum of 10 moves, Fruit produces much longer variations
5.Rybka uses a bitboard board representation whereas Fruit is mailbox
6.Rybka’s pawn value is 3200 (which is unique), Fruit uses the classic value of 100
7.The order in the evaluations of Fruit and Rybka are not similar
8.Rybka has lazy evaluation, which is absent in Fruit
9.Futility pruning is different between the two programs
10.Rybka uses Late Move Reductions (LMR) whereas Fruit uses history reductions
11.Fruit uses a history table which is absent Rybka.
12.Fruit only has one evaluation table (king safety) while Rybka has many
13.The two programs have a different move format
14.Rybka does not handle promotions to minor pieces
15.The two programs have different hash table code
16.They have different handling of repetitions and the 50-move rule in search
17.Fruit maintains piece-lists which are not present in Rybka
18.Fruit maintains a pseudo "bitboard" for pawns, Rybka has the real thing.
19.Contrary to Fruit, Rybka needs to update 4 rotations of occupancy bitboard
20.Contrary to Fruit, Rybka updates a rough estimate of material balance with weights of 1:3:3:5:10 (in the evaluation this value is then corrected by a delta obtained from the material table)
21.Fruit has a 16*16 square mailbox, Rybka has an 8*8
22.The programs have different Zobrist hash keys
23.The programs have different user interface options

We found 35 indisputable differences (some of which are very fundamental), not counting the ones that are debatable such as the Piece Square Tables (PSTs) and the contents of the TT.

Doesn't fit the definition of a derivative work.

Differences do not matter, it is the similarities and the number of them that violate rule 2. 75% of what you cite above comes from the mailbox/bitboard differences. Irrelevant in this context.

Nice try, no cigar.

All the evaluation elements were removed from their data structure, either mailbox or bitbaord. Every evaluation ingrediënt is coded differently, thus NO SIMILARITY.

What's left for you was to find traces of clear code copying. And as you admitted you did a lousy job. No surprise, because it wasn't there.

Double strike.

Not even a reasonable try. One can read Zach's report to see that there WERE many similarities. One can look at parts of the C from fruit, and compare it to the asm from rebuke and see the similarities.

Like Andrew Dalke said, The Zach Wegner document is highly misleading.

Furtmermore -

1. Its style is accusing from the beginning to the end, the reader is told what to think, it doesn't meet any scientific standard.

2. The many errors Zach made, especially his analysis of the Material Imbalance Table (a total new evalution technique now in use by many) is total garbage and yet Zach couldn't resist the temptation to link it anyway to Fruit as a similarity. Shameful.

3. In his fervor and already closed mind that Vas copied Fruit he missed all the evidence that unburdens the alleged similarity accusation at every evaluation element. In mobility, king safety, passed pawns, double pawns, backward pawns, even the trapped bishop evaluation, rook evaluation, bishop pair evaluation different and most importantly, Fruit evaluates in stages in a unique way whereas Rybka adds directly to its score (as every other program on the planet does) which Zach totally ignored also. No surprise here, Zach wasn't looking unburden evidences that would plea Vas free, no, convinced in his mind as he was Vas copied Fruit he only looked for signs of similarity, classic tunnel vision thinking. In science you you present the facts objectively. That's not what Zach did.

Some of us programmers have done more than just believing Zach's accusing document and critically scrutinized every accusation Zach made and concluded it is a bogus document.

One can look at Vida's decompilation of Rybka's hashing code, showing both bugs and unnecessary information. The SAME bugs and unnecessary information found in BOTH.

1. There are no bugs another sign that you don't have done your homework again. Both gents (Vas and Fabien) have discussed various search techniques in public (CCC) in the years 2003/4. Look it up! For that purpose I have written a special utility [ http://www.top-5000.nl/ccc.htm ] because I wanted to know what kind of information was shared during the pre-Rybka years.

They discussed and both tried the then much hyped and popular MTD(f) search technique among chess programmers, in the end both decided it did not help their program. Now as you very well know MTD(f) requires a strict data structure with 2 extra scores. Claiming similarity is bogus because the data structure for MTD(f) is OBLIGED.

What you call a bug is also wrong, switching back to a non MTD(f) search has the advantage you can leave the data structure in tact (including the 2 extra scores) and easily can try out other search techniques without rewriting the whole TT again. What you call a bug in fact is FLEXIBILITY. Read the old threads of 2003/04, it's all there.

2. Hash-table code contains 2 main elements:
2a. the update part, position is stored in the HT;
2b. the retrieve part, position is checked if present in the HT.

Regarding 2a - you know very well this part is where the intelligence and creativity of the programmer resides and it is TOTAL different than Fruit. And you know that.

Regarding 2b - Pretty much forced code based on the data structure, you know that as well. Not much choice in coding.

Like Zach, it's your subjective (and already closed) mind that wants to interprete things as evidence against Vas without looking at it from an objective point of view.

Last (and once again), you guys investigated the wrong version, a version that did not play in an ICGA tournament. The first Rybka version that played was 2.32a. In there the HT is completely rewritten from 16 to 8 bytes per entry and any programmer knows what that means: Nothing like Fruit.

There is a glaring bug. You just want to close your eyes. The hash entries use buckets of 64 bytes. But both fruit and rybka mangle that because they BOTH incorrectly failed to force 64 byte memory alignment so that a bucket would sit in one cache block. Interestingly, the previous versions of Rybka did this correctly, because that code was copied from Crafty which has done it correctly forever. Note I am not talking about the double-bound quirk, which is still a smoking gun here.

There is a glaring quirk. BOTH store both upper and lower bounds, but also store THREE depth values. That's not from mtd(f). I (and many others) played with mtd(f) when Don became a fan of it. We all stored two depths and two bounds. Yet Rybka and Fruit magically store three. mtd(f) doesn't require "two extra scores" so I assume you really meant "mtd(f) requires storing two bounds, rather than just one as is normally done." Leaving that in is not a "smart decision". It adds code, complexity, that is completely unnecessary outside of mtd(f).

Finally, you want to ignore evidence of copying even if it was later replaced. I don't remember the exact version where Vas went to 8 byte entries, but initially he did it JUST LIKE FRUIT. The origin was not original. And we did investigate that version. Mark Watkin's report was specifically addressed to the version (I think 2.3.2b, possibly a, I am not going back to look) that played in the WCCC.

The "style" of Zach's report was certainly accusatory. Ever heard a prosecutor at a trial say "the defendant might have done this..." His job is to make a statement and produce evidence to support that statement. The defendant's job is to produce evidence that refutes the prosecutor's statement and evidence.

The hash implementation is NOT forced. Do you use buckets or do you not? Do you probe once or search a chain? How do you replace? Depth-preferred? Always store? Both? Or do you go further and replace old search entries before current search entries? Do you try to constrain what is stored so that deep-draft entries don't end up dominating the table in long searches? There is not just one way to do ANY of this.

[bob]

One more note. This "you guys searched the wrong version" is a red-herring. Every new version of my chess program, dating ALL the way back to 1968, including major versions, minor versions, or rewrites, had MAJOR parts of the earlier version included. You do not rewrite 30-40-50K lines of code for each version. Much of what is in Rybka 1.0 beta remains in Rybka 4. Yes there are many changes. But less modified code than original code that appeared in 1.0b. If you compare any two versions of a chess program (Crafty is a good example, there are MANY versions publicly available to look at) you will notice that as abs(versionX - versionY) increases (move version numbers between the two) the similarities fade in parts of the code. But they do not go away. You talk like 2.3.2 is a brand new program. Completely different from 1.0beta. It is not. And no rational programmer would claim that it is. You could never make progress writing everything from scratch. The original code (if copied or not) certainly becomes diluted over time. But YOU are still the same basic "being" as you were when you were born. A geneticist could take the original you and the current you and show that you are the same, excluding what you have learned. same DNA however. There was never any evidence, nor any claim, that Rybka 2 was a total rewrite, nor Rybka 3, nor Rybka 4. For good reason. Which means that much of what was in 1.0 beta remains in later versions.

I doubt anybody REALLY wants a more thorough investigation at this point. The last time someone new was invited in, he (Richard) exposed MORE similarities, not less. Zach pointed out he focused mainly on the evaluation, plus the 0.0 issue. There is much more code to analyze, which would require a lot of effort, and at the end we would still be right where we are today. Rybka did not meet the requirements of rule 2. It is unfortunate.

Personally, I would like to see StockFish participate in CC tournaments. I would NOT want to see any of the dozens of derivatives, however. I suppose one could make a case for Ippolit since its origins were never officially discovered. But no derivative of ippolit, for obvious reasons. This copy/modify is a reasonable way for someone to investigate interesting ideas in computer chess, but it won't meet the requirements of rule 2 for move computer chess tournaments. Nor should it.

[mvk]

One more note. This "you guys searched the wrong version" is a red-herring. Every new version of my chess program, dating ALL the way back to 1968, including major versions, minor versions, or rewrites, had MAJOR parts of the earlier version included. You do not rewrite 30-40-50K lines of code for each version..

VR is not Hyatt. How often do you make that mistake.

My major versions (five times: v0, v1, v2, v3 and mscp) were always 100% rewrites from scratch, no code reuse between them. I'm not the only one.

[Sean Evans]

This discussion should be in the Engine Origins forum, you know the forum that Bob Hyatt created!

[Rebel]

One more note. This "you guys searched the wrong version" is a red-herring. Every new version of my chess program, dating ALL the way back to 1968, including major versions, minor versions, or rewrites, had MAJOR parts of the earlier version included. You do not rewrite 30-40-50K lines of code for each version..

VR is not Hyatt. How often do you make that mistake.

My major versions (five times: v0, v1, v2, v3 and mscp) were always 100% rewrites from scratch, no code reuse between them. I'm not the only one.

Reminds me of a Tord quote, something like, you can never rewrite your engine from scratch too many times.

[bob]

One more note. This "you guys searched the wrong version" is a red-herring. Every new version of my chess program, dating ALL the way back to 1968, including major versions, minor versions, or rewrites, had MAJOR parts of the earlier version included. You do not rewrite 30-40-50K lines of code for each version..

VR is not Hyatt. How often do you make that mistake.

My major versions (five times: v0, v1, v2, v3 and mscp) were always 100% rewrites from scratch, no code reuse between them. I'm not the only one.

If that is true, you are one really unusual (and inefficient) software developer. You rewrote the move parsing (input and output) five times? Why? I won't ask about all the other things that rarely need to change.

But in any case, there was no guesswork between 1.0 beta and 2.2.2b. Mark looked at the evaluation (again) in 2.3.2a so there is no question as to what was retained in those specific examples... Which makes this pretty much a pointless angle for discussion.