setjmp() - another one

[chrisw]

Bob argued that the existence in the Rybka code of setjmp() was "interesting" because this also existed in Fruit and nowhere else.

Uri pointed out that Tom Kerrigan's public program TSCP also used setjmp() and that some other programs were likely/possibly developed, legally, off TSCP as basis.

I'm an engine programmer and always had user interface programmers working in support, so I got very lazy and understand very little about DOS, windows, C support functions and so on. setjmp() knowledge is no way a speciality of mine.

However, casting my mind back many years, I'm fairly sure that the Ren Wu Chess program which was also worked on by Ren at Oxford Softworks used setjmp() to unwind the search on a timeout. CSTal, by contrast, did a proper search unwind.

There are two ways to exit Search() on a timeout or user intervention. The 'correct' way, I suppose, is to unwind the Search back to the start using unmove simultaneously unstacking the variables.
The brutal and simple way is simply to jump straight out, reseting the stack pointer. I guess this is setjmp().

I'l be very surprised if numbers of programs, especially those designed years ago without SMP in mind, didn't use the brutal setjmp() technique to break the search.

Bottom line: setjmp() is not unique and its use doesn't imply anything, certainly it cannot imply copied code.

Leaving the setjmp() relevant or not argument aside for a moment, come on, you state that you believe that an engine used setjmp()? Isn't that a bit vague? You demand always hard facts and source and pretty aligned code from Zach and Christoph, so were are the facts of Ren Wu chess?
Would you believe Zach if he would write he believes that the eval of Rybka is identical to Fruit without further comment?
You always want to see facts, so please before you do a conclusion, gives us some facts.

When I look at the (far from complete) list of chess engines released in recent years at http://wbec-ridderkerk.nl/html/enginesindex.htm, I wonder how many of these engines use setjmp()? 10 of 200? More?
I think it is still a good indication, not a prove.

I do not know but movei used setjmp() at the beginning like tscp
and I simply learned from the code of tscp.

I got rid of setjmp later because I read people said it is not good
so it is not clear how many engines use setjmp.
old movei use it
new movei does not use it and you can download both old movei and new movei from wbec site.

Uri

So, you copied TSCP, which uses setjmp(). And then discovered it is a bad programming solution and removed it. Good. But notice where you got it from. That is the point of this minor side-issue. It is just another indication that perhaps something was copied, because good programmers do not use it for _many_ reasons. Perhaps Fruit started life as TSCP as well, who knows? But if programs that are suspected of being connected by common source, share a particular feature that is known to be bad programming, it is just another hint that things might have been copied...

I never claimed it to be the ultimate proof. I simply said it was another suspicious detail because it is such a lousy way of writing a program.

Ahem. Copied? I would prefer "used the idea". And if it's one line of code, there's not much else he can do, is there?

What if someone reads Crafty use of null move? The call is one line

value = -Search(ply-2); basically

how are we going to get a suitable value back from Search() without telling it to take 2 of the search depth?

Some things just are as they are.

Of course by dissecting the source code into individual lines you can use the argument "one line of code cannot possibly breach the GPL".

Considering that a 4000 lines program is composed of individual lines, and that no single line alone can breach any copyright license, then it follows that none of these lines can breach the GPL and so the program is clean.

We are talking of blocks of code that are identical or equivalent semantically. The probability of them happening in two programs writen independantly is so tiny that it makes them appear suspicious.

// Christophe

Your point is understood, but suffices only to take us round and round in circles.

You say "blocks of code that are identical or equivalent semantically".

We say "show us".

And Zach says "stop pressurising me, it takes time"

So we say "ok, we'll wait for the code"

And you say "blocks of code that are identical or equivalent semantically"

etc. etc. etc.

Shall we wait for your best shot at identical code chunks and take it from there?

Or at this point, you tell us you already have done?

We say where?

So you say, I'm not holding your hand, go look.

So we find one thing, but actually you were referring to something else.

This has the advantage, you can flame us for being stupid.

... to be continued, thread page 94

[bob]

Entirely agreed its no good solution, but that's not the point. You said it was rare/unique whatever. It isn't. And therefore it's another nail in the probably used the same code coffin. It isn't.

You don't think it is rare? What, five total engines, one which has since been removed, out of how many hundreds??

Bob sums it up perfectly: "I never claimed it to be the ultimate proof. I simply said it was another suspicious detail because it is such a lousy way of writing a program."

Some people will always refuse to accept evidence when it is presented.

And some people don't like their evidence being challenged

It's spurious to say 5 out of 500 because no exhaustive search has been done on the 500. It's 5 only for the unscientific reason that two programmers happened to remember some past detail.

As to how many in total? Difficult. Some by random because they were old engines, SMP wasn't a problem and jumping out of the Search is a lazy but effective method, if politically incorrect. Some because they read TSCP. Some not because they read Crafty. What does Gnu do?

To pillory a programmer and his work it is necessary to produce evidence that stands beyond all reasonable doubt. This use of setjmp() is no longer in the beyond all reasonable doubt camp. Sorry about that, but that's the way it can go in adversarial investigation processes like this one.

Each point you bring will be challenged. Some will fall and some will stand, presumably. Do you want it any other way? Just blind acceptance because you're getting frustrated otherwise? If it were you, Zach, you'ld expect a vigorous defence and counter to each and every allegation and piece of evidence. Would you not?

setjmp() is not even a suspicious detail. It's history. Sorry.

It is suspicious to those of us that understand software development. Plagiarism involves copying good pieces of code most often, but when it is about copying a bad piece of code, it is just stronger evidence that copying was done.

[Graham Banks]

Let me get this clear.

You did not look up what setjmp() does. You saw it in TSCP, looked how it was used, and then used it the same way in Movei.

Now Uri, tell me.

Do you call that copying of ideas of copying code ?

Tony

Hmmm - so now you're after Uri as well. How many other engine authors are going to be brought before the kangaroo court?

As for private engines and their roots, how is anybody to know?

[Graham Banks]

[ it would be better to tell me directly that you are not interested in looking at the evidence and that all you want is that people stop posting it and go directly to the FSF.

// Christophe

Why don't you go directly to the FSF if you guys think that you're 100% on solid ground with your case?

[bob]

Entirely agreed its no good solution, but that's not the point. You said it was rare/unique whatever. It isn't. And therefore it's another nail in the probably used the same code coffin. It isn't.

You don't think it is rare? What, five total engines, one which has since been removed, out of how many hundreds??

Bob sums it up perfectly: "I never claimed it to be the ultimate proof. I simply said it was another suspicious detail because it is such a lousy way of writing a program."

Some people will always refuse to accept evidence when it is presented.

And some people don't like their evidence being challenged

It's spurious to say 5 out of 500 because no exhaustive search has been done on the 500. It's 5 only for the unscientific reason that two programmers happened to remember some past detail.

As to how many in total? Difficult. Some by random because they were old engines, SMP wasn't a problem and jumping out of the Search is a lazy but effective method, if politically incorrect. Some because they read TSCP. Some not because they read Crafty. What does Gnu do?

To pillory a programmer and his work it is necessary to produce evidence that stands beyond all reasonable doubt. This use of setjmp() is no longer in the beyond all reasonable doubt camp. Sorry about that, but that's the way it can go in adversarial investigation processes like this one.

Each point you bring will be challenged. Some will fall and some will stand, presumably. Do you want it any other way? Just blind acceptance because you're getting frustrated otherwise? If it were you, Zach, you'ld expect a vigorous defence and counter to each and every allegation and piece of evidence. Would you not?

setjmp() is not even a suspicious detail. It's history. Sorry.

[chrisw]

Entirely agreed its no good solution, but that's not the point. You said it was rare/unique whatever. It isn't. And therefore it's another nail in the probably used the same code coffin. It isn't.

You don't think it is rare? What, five total engines, one which has since been removed, out of how many hundreds??

Bob sums it up perfectly: "I never claimed it to be the ultimate proof. I simply said it was another suspicious detail because it is such a lousy way of writing a program."

Some people will always refuse to accept evidence when it is presented.

And some people don't like their evidence being challenged

It's spurious to say 5 out of 500 because no exhaustive search has been done on the 500. It's 5 only for the unscientific reason that two programmers happened to remember some past detail.

As to how many in total? Difficult. Some by random because they were old engines, SMP wasn't a problem and jumping out of the Search is a lazy but effective method, if politically incorrect. Some because they read TSCP. Some not because they read Crafty. What does Gnu do?

To pillory a programmer and his work it is necessary to produce evidence that stands beyond all reasonable doubt. This use of setjmp() is no longer in the beyond all reasonable doubt camp. Sorry about that, but that's the way it can go in adversarial investigation processes like this one.

Each point you bring will be challenged. Some will fall and some will stand, presumably. Do you want it any other way? Just blind acceptance because you're getting frustrated otherwise? If it were you, Zach, you'ld expect a vigorous defence and counter to each and every allegation and piece of evidence. Would you not?

setjmp() is not even a suspicious detail. It's history. Sorry.

It is suspicious to those of us that understand software development. Plagiarism involves copying good pieces of code most often, but when it is about copying a bad piece of code, it is just stronger evidence that copying was done.

Six users of setjmp() now, another "bad" programmer using "bad" techniques crawled out of the woodwork this afternoon.

Perhaps there are several ways to skin a cat, Bob? Your way isn't necessarily the "unique", "real programmer" and most "interesting" one?

Could it be so?

[bob]

Entirely agreed its no good solution, but that's not the point. You said it was rare/unique whatever. It isn't. And therefore it's another nail in the probably used the same code coffin. It isn't.

You don't think it is rare? What, five total engines, one which has since been removed, out of how many hundreds??

Bob sums it up perfectly: "I never claimed it to be the ultimate proof. I simply said it was another suspicious detail because it is such a lousy way of writing a program."

Some people will always refuse to accept evidence when it is presented.

And some people don't like their evidence being challenged

It's spurious to say 5 out of 500 because no exhaustive search has been done on the 500. It's 5 only for the unscientific reason that two programmers happened to remember some past detail.

As to how many in total? Difficult. Some by random because they were old engines, SMP wasn't a problem and jumping out of the Search is a lazy but effective method, if politically incorrect. Some because they read TSCP. Some not because they read Crafty. What does Gnu do?

To pillory a programmer and his work it is necessary to produce evidence that stands beyond all reasonable doubt. This use of setjmp() is no longer in the beyond all reasonable doubt camp. Sorry about that, but that's the way it can go in adversarial investigation processes like this one.

Each point you bring will be challenged. Some will fall and some will stand, presumably. Do you want it any other way? Just blind acceptance because you're getting frustrated otherwise? If it were you, Zach, you'ld expect a vigorous defence and counter to each and every allegation and piece of evidence. Would you not?

setjmp() is not even a suspicious detail. It's history. Sorry.

It is suspicious to those of us that understand software development. Plagiarism involves copying good pieces of code most often, but when it is about copying a bad piece of code, it is just stronger evidence that copying was done.

I've never said it was absolute proof of anything. But a fingerprint here, a drop of blood there, a little DNA over there, a photo taken over yonder, all can add up to paint a convincing picture.

What everyone is _trying_ to do is to say "no specific thing you, or Zach or Christophe, or Norma, or anyone else has shown is proof of copying." And I would not disagree. But when you take everything as a whole, the picture is becoming quite a bit less certain. "the whole is greater than the sum of its parts" applies, and right now, everyone wants to disassemble and destroy each part independently. But they are all related, and help toward developing a complete understanding of what has happened.

It will take some time for those interested in the disassembly process to do their work. It is a royal pain. I spent a couple of weeks doing this back in the crafty clone cases, so that I had a piece of code that would search through a program looking for what I considered to be "well-defined signatures", which were large blocks of 64 bit masks that while anyone might certainly develop them on their own, they would not declare and initialize them in exactly the same order.

So give them a chance to see what they come up with. When they reveal something that I think is interesting, I will comment. If someone makes a statement that I think is "outside the reality box" I will say something to try to keep the posts centered on reaching a reasonable conclusion.

Unfortunately there is so much noise here, the signals keep getting lost and we get even more noise asking for links to the signals...

[bob]

Ahem, Bob, I have some deja-vus when reading your posts. Are you trapped in a time loop?

Sort of. Somehow the post operation is taking forever at times, and I can only suspect that after some time-out interval, firefox re-submits. I have seen two and even three duplicates, and today has been particularly atrocious in terms of delays. I received a couple of PM's here and responding to them went instantly, but posting an article is taking 1-2 minutes, and is producing duplicates here and there, sometimes mysteriously, sometimes when I hit submit a second time after nothing has happened for a minute or two.

[Rolf]

Entirely agreed its no good solution, but that's not the point. You said it was rare/unique whatever. It isn't. And therefore it's another nail in the probably used the same code coffin. It isn't.

You don't think it is rare? What, five total engines, one which has since been removed, out of how many hundreds??

Bob sums it up perfectly: "I never claimed it to be the ultimate proof. I simply said it was another suspicious detail because it is such a lousy way of writing a program."

Some people will always refuse to accept evidence when it is presented.

And some people don't like their evidence being challenged

It's spurious to say 5 out of 500 because no exhaustive search has been done on the 500. It's 5 only for the unscientific reason that two programmers happened to remember some past detail.

As to how many in total? Difficult. Some by random because they were old engines, SMP wasn't a problem and jumping out of the Search is a lazy but effective method, if politically incorrect. Some because they read TSCP. Some not because they read Crafty. What does Gnu do?

To pillory a programmer and his work it is necessary to produce evidence that stands beyond all reasonable doubt. This use of setjmp() is no longer in the beyond all reasonable doubt camp. Sorry about that, but that's the way it can go in adversarial investigation processes like this one.

Each point you bring will be challenged. Some will fall and some will stand, presumably. Do you want it any other way? Just blind acceptance because you're getting frustrated otherwise? If it were you, Zach, you'ld expect a vigorous defence and counter to each and every allegation and piece of evidence. Would you not?

setjmp() is not even a suspicious detail. It's history. Sorry.

It is suspicious to those of us that understand software development. Plagiarism involves copying good pieces of code most often, but when it is about copying a bad piece of code, it is just stronger evidence that copying was done.

I've never said it was absolute proof of anything. But a fingerprint here, a drop of blood there, a little DNA over there, a photo taken over yonder, all can add up to paint a convincing picture.

What everyone is _trying_ to do is to say "no specific thing you, or Zach or Christophe, or Norma, or anyone else has shown is proof of copying." And I would not disagree. But when you take everything as a whole, the picture is becoming quite a bit less certain. "the whole is greater than the sum of its parts" applies, and right now, everyone wants to disassemble and destroy each part independently. But they are all related, and help toward developing a complete understanding of what has happened.

It will take some time for those interested in the disassembly process to do their work. It is a royal pain. I spent a couple of weeks doing this back in the crafty clone cases, so that I had a piece of code that would search through a program looking for what I considered to be "well-defined signatures", which were large blocks of 64 bit masks that while anyone might certainly develop them on their own, they would not declare and initialize them in exactly the same order.

So give them a chance to see what they come up with. When they reveal something that I think is interesting, I will comment. If someone makes a statement that I think is "outside the reality box" I will say something to try to keep the posts centered on reaching a reasonable conclusion.

Unfortunately there is so much noise here, the signals keep getting lost and we get even more noise asking for links to the signals...

Problem is what this already now all means if later we''ll say that it was just a dream? Will you take responsibilities? Or this way: dont you realise now how that will backfire also to you if nothing can be proven for sure? Also: the climate here doesnt play a role for you?

Bob please make a little post for me: declare what you will write in future about the reasons when all was a dream? How would YOU defend your participation. Just do it please. Perhaps you will see what I am thinking about. Bob this isnt a seminary in your classes. This is a public forum. And you deal with a single commerciasl program but Fritz, Shredder, Junior et all are of no interest for you. Please justify this in a little add-on. Just to explain for me that you have and can have a sane and clean conscience.

[bob]

And some people don't like their evidence being challenged

Then why exactly did I so openly welcome Gerd's comments in my other thread??

It's spurious to say 5 out of 500 because no exhaustive search has been done on the 500. It's 5 only for the unscientific reason that two programmers happened to remember some past detail.

As to how many in total? Difficult. Some by random because they were old engines, SMP wasn't a problem and jumping out of the Search is a lazy but effective method, if politically incorrect. Some because they read TSCP. Some not because they read Crafty. What does Gnu do?

There might be a few more. Any chess programmer who knows his stuff will say that it is rare.

Gnuchess 5.06 does not use setjmp(). I just grepped for it in the source code. So that one is easy enough to answer.

To pillory a programmer and his work it is necessary to produce evidence that stands beyond all reasonable doubt. This use of setjmp() is no longer in the beyond all reasonable doubt camp. Sorry about that, but that's the way it can go in adversarial investigation processes like this one.

It never was in the "beyond reasonable doubt" camp. You can't just take each point one by one in a case like this. Each point could taken as a coincidence, or of course, "use of ideas". It is exactly as Christophe said: If you take each line of code in isolation, then it is reasonable to assume that it could be original. But when these start adding up, that method just doesn't cut it.

Your logic says this: You can't use fingerprints, because there is certainly a possibility that two people can have the same fingerprint, since there is not an infinite variety of ways for the loops and whorls to form. You can't use DNA because we _know_ there are a finite number of DNA protein combinations, and a finite number means duplicates _must_ be possible. You can't use photographic evidence because we know there are twins, doctored photos, etc. You can't use eyewitness testimony because humans make visual identification mistakes all the time. In short, you can find fault with every individual piece of evidence presented. But you overlook probability theory when you say it is all no good. What is the probability of duplicate fingerprints? A very small (but non-zero) number. What is the probability of duplicate DNA? A very small number. But both leave room for doubt. But what is the probability of duplicate fingerprints _and_ duplicate DNA? Multiply two very small numbers together and you get a _really_ small number.

This is why nobody is saying setjmp() is the smoking gun. It is a clue. The more clues we have to consider, the lower the probability that they are leading to a flawed decision.

Sooner or later, we will come to a "beyond reasonable doubt" conclusion. Whether that is "copied or not copied" is not yet known. But so far, all evidence seems to lead toward "copied". And each new piece reduces the uncertainty.

Now granted, _some_ are not going to be convinced even with 100% code matching, output matching, binary comparisons, and so forth. IE they are not "impartial". That can't be helped.

Each point you bring will be challenged. Some will fall and some will stand, presumably. Do you want it any other way? Just blind acceptance because you're getting frustrated otherwise? If it were you, Zach, you'ld expect a vigorous defence and counter to each and every allegation and piece of evidence. Would you not?

I want a reasonable defense. You have to look at these things holistically. For each point that I posted, there might be a few other engines with the same details. But as you add each one up, you see that only two engines share all of these details.

setjmp() is not even a suspicious detail. It's history. Sorry.

Sorry, but you are wrong.