What do you folks make of this ?

[mballicora]

I've been writing parallel programs since 1978 and I would NEVER assume there are no bugs, just because nothing crashes. I have fixed more subtle bugs, and it really has nothing to do with threads vs processes. Except that threads are more efficient for some things (egtb access is one since egtb.cpp is thread-aware and you don't duplicate the cache N times...

But experience suggests that the term "debugged parallel program" is an oxymoron...

I don't assume I have no bugs because it doesn't crash. I assume I have bugs because I have been writing parallel programs with wooden sticks on clay disks and the wheel was a big thing at the time. I sure have bugs (last month I found one in my PGN handling code and it was 15 years old, and not in difficult code). I assume I have no SMP bugs that -affect- me because the SMP code is simple, passes my stress tests, plays strong chess on servers AND doesn't crash... At that point worrying about such bugs is not just low on my priority list, it is not on the list at all.

Regarding EGT: simplicity and processes is why I have placed the EGT data in a huge shared library and let the kernel handle the access and sharing. The EGT code is nearly absent because Linux provides it for me. I noticed Crafty doesn't use EGTs at all anymore and misses endgame wins because of that.

Crafty used them in the last ACCA tournament.

But back to the point: My program uses setjmp/longjmp and I don't agree that it is a sign of copying chess playing code. I got the idea from K&R, not from Fruit. I wasn't aware that Fruit was using it as well for the same purpose.

TSCP uses it as well as Thinker (I did not check TSCP, but it was mentioned). Lance Perkins already explained in one of the original threads about this F/R thing that it is even a modern way to handle exceptions. Some languages use try and catch, but you can do it in C too
http://en.wikipedia.org/wiki/Exception_handling_syntax

Miguel

[hyatt]

I've been writing parallel programs since 1978 and I would NEVER assume there are no bugs, just because nothing crashes. I have fixed more subtle bugs, and it really has nothing to do with threads vs processes. Except that threads are more efficient for some things (egtb access is one since egtb.cpp is thread-aware and you don't duplicate the cache N times...

But experience suggests that the term "debugged parallel program" is an oxymoron...

I don't assume I have no bugs because it doesn't crash. I assume I have bugs because I have been writing parallel programs with wooden sticks on clay disks and the wheel was a big thing at the time. I sure have bugs (last month I found one in my PGN handling code and it was 15 years old, and not in difficult code). I assume I have no SMP bugs that -affect- me because the SMP code is simple, passes my stress tests, plays strong chess on servers AND doesn't crash... At that point worrying about such bugs is not just low on my priority list, it is not on the list at all.

Regarding EGT: simplicity and processes is why I have placed the EGT data in a huge shared library and let the kernel handle the access and sharing. The EGT code is nearly absent because Linux provides it for me. I noticed Crafty doesn't use EGTs at all anymore and misses endgame wins because of that.

Crafty used them in the last ACCA tournament.

But back to the point: My program uses setjmp/longjmp and I don't agree that it is a sign of copying chess playing code. I got the idea from K&R, not from Fruit. I wasn't aware that Fruit was using it as well for the same purpose.

TSCP uses it as well as Thinker (I did not check TSCP, but it was mentioned). Lance Perkins already explained in one of the original threads about this F/R thing that it is even a modern way to handle exceptions. Some languages use try and catch, but you can do it in C too
http://en.wikipedia.org/wiki/Exception_handling_syntax

Miguel

If so, it was unintentional. I have had them turned off for well over a year since I did the cluster test. If they are "back" it is because of an oversight where I might have turned them on to test a position, and left that machine configured wrongly...

setjmp()/longjmp() by themselves are not an indication. But when you see the code surrounding them, and it mights up very accurately, it is "another clue". It is not that any one "clue" is overwhelming by itself, even the 0.0 issue. But with SO MANY clues, the chances of accidental co-discovery vanish.

[Rebel]

From what I understand there is nothing in Rybka 1 Beta that is a direct identical copy of Fruit.

Perhaps you should give this a looksee then.



https://webspace.utexas.edu/zzw57/rtc/eval/eval.html

The expert witness had already found the defendant guilty. All that remained was the writing of a suitable report. The language is biased, the reader is told what to think, where there are dissimilarities the reader is assured, for example, 'this is done for optimisation reasons only' and is left to assume the dissimilarity doesn't really exist. Where Rybka uses tables, the expert witness 'recreates' the code he imagines was used to build the table data (although he never saw the code in binary form!) and unsurprisingly it matches directly with Fruit code - well, if you want to find/prove something and are sufficiently biased and committed to the result ...... Please read that last bit carefully, again: the expert witness took a lookup table of data, imagined up the code required to recreate that data (this without access to the program that created the data which he has never seen), wrote the code as identical to some Fruit source, and says "it's the same, but optimised". Ridiculous, but it gets worse in this same code section ..... for the sub-function called in the above that looks at pawn defence in front of the king returns completely different values for each program, the sub-functions are given the same name by the witness, but they do different things. And, lastly on this section, what program doesn't look in some way at open files in front of the king? Just not good enough.

In king_safety as another example both Fruit and Rybka look at piece attacks on the eight squares around the king. Er, who doesn't do this? But it is treated as a similarity proof. The expert witness skips over the fact that Rybka does it all very fast with btiboards (who wouldn't with a bb program?), while Fruit code is longer and slower, done without bb's (well it would be wouldn't it?). We're told that the 'sum of weights' for the attacks are different for each program, but the fact that pawns are treated as zero (what a surprise!!) is yet more 'proof' of similarity, while all differences (massive I would imagine) are just the result of 'optimisation' (again). Hahahaha!!!

Just for starters.

In a court the witness document would be torn apart and rapidly discredited. I am shocked that elements of comp chess community have placed so much weight on it.

Came across this beauty while following a link I found in the (older) RYB_FR_Feb21.pdf document.

My compliments Chris, you were right from the beginning.

[Rebel]

Feel free to quote this "ad hominem" you refer to. I have no idea what you are talking about, otherwise.

who cares? read your own post at CCC. I'm more interested in this .....


your argument is all very fine and dandy, were it to fit the facts of the case I referred to

your case (a) above (What matters is that (a) the two sets of values are similar or identical) is not met as the two sets of values are very different both in scale and in relation to each other. Since they are not the comparison between the code in Fruit and the lookuptable data in Rybka is completely misleading, he shouldn't have even tabled up the comparison without a huge "THIS DOES NOT PROVE ANYTHING" written next to it. I can see that skim-reading Zach's report will easily lead to the conclusion of rip-off, but actually reading it and cross-checking brings about an entirely different conclusion, namely that this report appears to have been written by the prosecution with one intent in mind. Guilt and conviction.

I agree with you that we need to stay on track, and keep it on topic. That said, I completely disagree with respect to two sets of values being identical data not met. Going on Vas' own words:

Generally, code theft is easy to show - just show the two sections of identical code, side-by-side. There isn't much to debate in such cases.

Rybka 1.0 beta is free. Take a look at the binary starting from address 004092E0 and compare it to Fruit protocol.cpp beginning from line 430 onwards -- there are lines there copied verbatim, line for line. And it does not stop there of course. Not that am breaking new grounds here by any means, but I think the case is pretty much shut. It doesn't mean that we take anything away from his accomplishments. He stood on shoulders of those before him, and it's only right for him to carry a little weight.

http://www.top-5000.nl/fen.htm

I don't see any verbatim copying.

[Rebel]

OK, it's true that Zach's report, as you say, under the microscope, has, shall we say, flaws, or preconceived guilt notions as I would call them. But I do get the message, behind the report there is a substantial body of similarities. However, it's a similarity of IDEAS rather than implentations of the ideas, and, if we ascribe to Vas good motives (difficult for you, I appreciate) to make a very strong program, all his own work, ultimately, via test bed or parallel approach - then we have evidence for that too.

I would disagree with "preconceived guilt notions". That's not what it is at all. I originally got involved in this after seeing the UCI parser, which was just too similar to be coincidence IMO. I then spent an awful lot of time looking over Fruit, Strelka, and eventually disassembling the vast majority of Rybka 1.0. I came to the conclusion, after seeing what I saw, that Rybka started its life as Fruit. Then I spent a lot more time producing the report. The report was intended to argue my opinion--I didn't start by trying to prove Vas guilty of something by any means necessary. Maybe some of the language is a bit too biased, and rewording some stuff would be productive. The main reason for that would be the climate of the community around the time it was written. The vast majority of people would never believe what I was saying, and I took a lot of heat for it. There's still a lot of people that refuse to believe the evidence (if they even bother to look at it). If you look at the evidence and come to a different conclusion though, I can respect that.

I would definitely not say that the similarities are just "ideas". What I would call implementation copying is everywhere, search, evaluation, UCI parser. The line between ideas and implementation is really quite blurry, as the R/F case shows and the R/I case just reinforced that. If you look at one small part of it, you can maybe say that it's just taking an idea, but IMO, looking at the big picture, there is just too much there to be dismissed as ideas. The 0.0 case proves that Vas copied and pasted some code--the question is just how much. And even if the amount of copying and pasting was just limited to this section, I think the other similarities (particularly the PST and passed pawn constants) are enough to say that what was done was ethically wrong.

Bob,

0.0 was a minor case huh ?

[hyatt]

OK, it's true that Zach's report, as you say, under the microscope, has, shall we say, flaws, or preconceived guilt notions as I would call them. But I do get the message, behind the report there is a substantial body of similarities. However, it's a similarity of IDEAS rather than implentations of the ideas, and, if we ascribe to Vas good motives (difficult for you, I appreciate) to make a very strong program, all his own work, ultimately, via test bed or parallel approach - then we have evidence for that too.

I would disagree with "preconceived guilt notions". That's not what it is at all. I originally got involved in this after seeing the UCI parser, which was just too similar to be coincidence IMO. I then spent an awful lot of time looking over Fruit, Strelka, and eventually disassembling the vast majority of Rybka 1.0. I came to the conclusion, after seeing what I saw, that Rybka started its life as Fruit. Then I spent a lot more time producing the report. The report was intended to argue my opinion--I didn't start by trying to prove Vas guilty of something by any means necessary. Maybe some of the language is a bit too biased, and rewording some stuff would be productive. The main reason for that would be the climate of the community around the time it was written. The vast majority of people would never believe what I was saying, and I took a lot of heat for it. There's still a lot of people that refuse to believe the evidence (if they even bother to look at it). If you look at the evidence and come to a different conclusion though, I can respect that.

I would definitely not say that the similarities are just "ideas". What I would call implementation copying is everywhere, search, evaluation, UCI parser. The line between ideas and implementation is really quite blurry, as the R/F case shows and the R/I case just reinforced that. If you look at one small part of it, you can maybe say that it's just taking an idea, but IMO, looking at the big picture, there is just too much there to be dismissed as ideas. The 0.0 case proves that Vas copied and pasted some code--the question is just how much. And even if the amount of copying and pasting was just limited to this section, I think the other similarities (particularly the PST and passed pawn constants) are enough to say that what was done was ethically wrong.

Bob,

0.0 was a minor case huh ?

If you read his statement, nope. "proves that he copied SOME code. The question is just how much....." That was not even the tip of the proverbial iceberg...

You are spending WAY too much time trying to figure out what others were thinking, what their motives were, etc. Perhaps if you spent more time on the actual evidence??? Or are you trying to absolve yourself of some sense of guilt, since you claim that 0.0 was ALL that you considered when signing the Fabien letter? It was not as big a deal to me as the setjump/longjump stuff and that was not that big a deal in light of all the other evidence.

[Rebel]

OK, it's true that Zach's report, as you say, under the microscope, has, shall we say, flaws, or preconceived guilt notions as I would call them. But I do get the message, behind the report there is a substantial body of similarities. However, it's a similarity of IDEAS rather than implentations of the ideas, and, if we ascribe to Vas good motives (difficult for you, I appreciate) to make a very strong program, all his own work, ultimately, via test bed or parallel approach - then we have evidence for that too.

I would disagree with "preconceived guilt notions". That's not what it is at all. I originally got involved in this after seeing the UCI parser, which was just too similar to be coincidence IMO. I then spent an awful lot of time looking over Fruit, Strelka, and eventually disassembling the vast majority of Rybka 1.0. I came to the conclusion, after seeing what I saw, that Rybka started its life as Fruit. Then I spent a lot more time producing the report. The report was intended to argue my opinion--I didn't start by trying to prove Vas guilty of something by any means necessary. Maybe some of the language is a bit too biased, and rewording some stuff would be productive. The main reason for that would be the climate of the community around the time it was written. The vast majority of people would never believe what I was saying, and I took a lot of heat for it. There's still a lot of people that refuse to believe the evidence (if they even bother to look at it). If you look at the evidence and come to a different conclusion though, I can respect that.

I would definitely not say that the similarities are just "ideas". What I would call implementation copying is everywhere, search, evaluation, UCI parser. The line between ideas and implementation is really quite blurry, as the R/F case shows and the R/I case just reinforced that. If you look at one small part of it, you can maybe say that it's just taking an idea, but IMO, looking at the big picture, there is just too much there to be dismissed as ideas. The 0.0 case proves that Vas copied and pasted some code--the question is just how much. And even if the amount of copying and pasting was just limited to this section, I think the other similarities (particularly the PST and passed pawn constants) are enough to say that what was done was ethically wrong.

Bob,

0.0 was a minor case huh ?

If you read his statement, nope. "proves that he copied SOME code. The question is just how much....." That was not even the tip of the proverbial iceberg...

You are spending WAY too much time trying to figure out what others were thinking, what their motives were, etc. Perhaps if you spent more time on the actual evidence??? Or are you trying to absolve yourself of some sense of guilt, since you claim that 0.0 was ALL that you considered when signing the Fabien letter? It was not as big a deal to me as the setjump/longjump stuff and that was not that big a deal in light of all the other evidence.

Apologize for the (new) lie and I might answer you.

[hyatt]

OK, it's true that Zach's report, as you say, under the microscope, has, shall we say, flaws, or preconceived guilt notions as I would call them. But I do get the message, behind the report there is a substantial body of similarities. However, it's a similarity of IDEAS rather than implentations of the ideas, and, if we ascribe to Vas good motives (difficult for you, I appreciate) to make a very strong program, all his own work, ultimately, via test bed or parallel approach - then we have evidence for that too.

I would disagree with "preconceived guilt notions". That's not what it is at all. I originally got involved in this after seeing the UCI parser, which was just too similar to be coincidence IMO. I then spent an awful lot of time looking over Fruit, Strelka, and eventually disassembling the vast majority of Rybka 1.0. I came to the conclusion, after seeing what I saw, that Rybka started its life as Fruit. Then I spent a lot more time producing the report. The report was intended to argue my opinion--I didn't start by trying to prove Vas guilty of something by any means necessary. Maybe some of the language is a bit too biased, and rewording some stuff would be productive. The main reason for that would be the climate of the community around the time it was written. The vast majority of people would never believe what I was saying, and I took a lot of heat for it. There's still a lot of people that refuse to believe the evidence (if they even bother to look at it). If you look at the evidence and come to a different conclusion though, I can respect that.

I would definitely not say that the similarities are just "ideas". What I would call implementation copying is everywhere, search, evaluation, UCI parser. The line between ideas and implementation is really quite blurry, as the R/F case shows and the R/I case just reinforced that. If you look at one small part of it, you can maybe say that it's just taking an idea, but IMO, looking at the big picture, there is just too much there to be dismissed as ideas. The 0.0 case proves that Vas copied and pasted some code--the question is just how much. And even if the amount of copying and pasting was just limited to this section, I think the other similarities (particularly the PST and passed pawn constants) are enough to say that what was done was ethically wrong.

Bob,

0.0 was a minor case huh ?

If you read his statement, nope. "proves that he copied SOME code. The question is just how much....." That was not even the tip of the proverbial iceberg...

You are spending WAY too much time trying to figure out what others were thinking, what their motives were, etc. Perhaps if you spent more time on the actual evidence??? Or are you trying to absolve yourself of some sense of guilt, since you claim that 0.0 was ALL that you considered when signing the Fabien letter? It was not as big a deal to me as the setjump/longjump stuff and that was not that big a deal in light of all the other evidence.

Apologize for the (new) lie and I might answer you.

What new lie? You want to claim you didn't say something to the effect that "if I knew about the >= vs > mistake, I would not have signed, the 0.0 was the thing that convinced me."

I'll be happy to post the exact quite if you prefer...

[Rebel]

What new lie? You want to claim you didn't say something to the effect that "if I knew about the >= vs > mistake, I would not have signed, the 0.0 was the thing that convinced me."

Will you stop misremembering 9 months of discussion as if signed the Fabien because of 0.0 alone ?

When Fabien contacted me for my signature I had a discussion with Mark and Fabien first because at that time I was hovering between VII and VIG. In that discussion 0.0 by Fabien was emphasized as evidence in a court case. Eventually I gave my permission.

Hi Fabien,

Okay, you can put my name under the document. Provided I receive a copy of the email to David so I can elaborate my position to David, just in case I feel the need.

I think the evidence speaks volumes nevertheless my concern is the major danger of a tunnel-vision that is always present in cases with zillions of variables such as this one. This still keeps me a bit worried, the 10% I wrote you about.

But then again the evidence is pretty overwhelming and VR can always escape by appointing 1 or 2 experts that he trust, send them the Rybka 1.0 beta source code for a comparison to disembarrass himself from the (upcoming) shame.

As for me the most striking trace he left is the conversion of the time-control from float to integer leaving "0.0".

So I hope the ICGA will take away all his WC titles until he will have done his GPL duties.

Ed
____________________________________________________________________________________________

Do you have a problem with truth finding Bob ?

If not, then don't resort making false accusations.

Thanks so much.

[Rebel]

In addition I have asked the first signers of the Fabien letter (Fabien, Zach, SMK and Mark Uniacke) 2 questions:

1. Did you know that "if (movetime >= 0.0)" was false ?

2. How much influence had "if (movetime >= 0.0)" in your decision making process.

Pending their answers.