Bob Hyatt says that....

[Tony Thomas]

Doesnt loop uses some sort of novel idea? I know that List was cleared by Chrilly Donninger once when it was accused of being a clone...Since I doubt the origins of Rybka 1.0 beta, I have no choice but to doubt Loop as well since the similarities are more profound.

[bob]

The following Crafty file names are exact matches:
attacks.c
hash.c
init.c
list.c
make.c
moves.c
next.c
phase.c
ponder.c
search.c
searchr.c
test.c
time.c
utility.c

It is still as absurd as it was, then. I mean, what are programmers talking about all the time, regarding ANY chess engine? Am I right that it are things like hash, moves, ponder, search...? If that's enough for a clone suspicion, than every engine is suspicious to be a copy & paste clone of every other enigne.

It's like taking a famous novel, selecting some frequent words form everyday talk which will be found in almost every book, and based on that claim that it is a copy of another novel. Because both contain words like "mother", "husband", "house", and maybe "airplane". By that criteria, almost any novel would be suspicious to be a clone of any other novel. How intelligent is that? It is moronic.

Nevertheless, the unscrupulous, reckless ICGA disqualified a participant who was not present on site, based on accusations of that ridiculous quality. I almost exploded about that excess of incompetence and injustice. In contrast, F.Reul did not care much about it and almost never wrote anything in a public forum. Appearantly he kept very cool about it and continued to do his things, not caring for internet message board noise. Enviable.

I disagree. I have been playing in these tournaments every year since 1976, skipping a fair number over the past 10 years because of excessive length and cost. But the policy has always been there, and I have always arrived with either my source on a laptop, or more commonly, with a complete listing printed in a 3-ring binder.

To refuse to show your source, with that requirement explicitly and clearly given in the rules, is tantamount to refusing to play, since you refuse to abide by the rules being used. The primary mistake was made by the author, as he could have shown his source to the protest committee and resolved this easily. Unless he had something to hide...

[bob]

show us specific lines of code that are equal to those from fruit.

http://pagesperso-orange.fr/ct_chess/Fr ... rt_go.html

Is this all?

My goodness. I stayed away from this riot but I thought there was more about it.
I can see a similarity that is easily explained in this manner: Vas looked at the code and said, "I see a loop with strtok to parse UCI" and he implemented it that way. Of course, UCI is "universal" and both codes will converge towards those commands. Several lines are mixed, so it does not make any sense to copy and paste a code and later mix it up for no purpose. No reason to obfuscate this... it is easier to rewrite it from scratch!

I see zero proof of violation of GPL from this file.

Miguel

Why would Vas look at the code for a UCI parser? It's a pretty simple specification - I don't understand why he would need to see someone else's code. I recently implemented a UCI parser myself and never used strtok at all - but then it's my style not to use strtok much anyway. It's strange that Vas's style is to use strtok in the same way someone else has. Hmmmm.

There is more than zero proof here...

This is a hopeless discussion.. Some are _not_ going to be convinced, because of whatever personal reasons they have. Evidence be damned. Discussions be damned. It is just not going to change their opinion or adamant refusal to accept any kind of evidence, period.

The best that can be hoped for is that enough questions are raised, enough evidence is produced, that eventually the question has to be answered in a way that is consistent with all the facts, whatever they are by then. Might be nothing to it. Might be a lot to it. But the detractors are not going to help in any way so it is just wasted bandwidth. I know, I know, I've been just as guilty of wasting bandwidth. But I'm 60 years old now so we can blame that on old age.

I stayed away from this discussion. I contributed only with that message. You answered to someone that answered me with a patronizing attitude. Indirectly, you are referring to me as someone that who damns evidence and discussion. You may be referring to the rest of the planet, maybe, but my name is there. This is rude. I better stop right now.

For the record, I could not care less about the result of this particular case. I just realized that I stuck my nose in a street fight that is not mine. My mistake.

Good luck in this crusade, to both sides.
Miguel

Sorry, but I was not "damning you". If you had been following these many threads on the topic, you would have better understood my comments, which were applied to a small group that simply refuse to accept any kind of comparison.

[bob]

I read all of Fabians postings and to tell you the truth no one can say for sure whether is dicovered the search routine or maybe just the way it display the board on the screen. Remember he inserted what he thought were the names of the variables, because they are simple not there in the compiled code.
Years agp I dissambles the code of a chess program and to tell you the truth even following the 8080 dissassambler language it was almost impossible to tell what the program was doing.
Bill

I've been programming in assembly since 1968, and don't have that problem. I have to look at assembly code all the time and figure out what it is doing...

[bob]

...the argument that points how many programs or even all use the same algorythms is irrelevant as much they can be writen in so many different ways. So, he add, the reasonning that programs share lot of stuff, as Fabian said, would be not valid.
Ok. Then, if it is so and surely must be because, after all, Bob Hyatt and none other said that, if really the line of code and how was writen is the core of the issue, then let the attackers of Rybka originality show us specific lines of code that are equal to those from fruit.
Of course I wonder how they will do such a thing as much I presume the Rybka lines of code are not easily accesible.

Wondering regards
fern

What is being done is to take the executable, and run in thru a disassembler which produces the assembly language code the compiler produced when the source was compiled. An experienced programmer can then take that assembly language code and reconstruct the C source code it came from.

inc i => i++; in C for example.

It takes time because the optimizer in the compiler re-orders instructions to make them run as efficiently as possible, so the human reverse-engineer has to undo all of that...

Perhaps you should also point out that when the executable code is compiled from the source in the first place, enormous amounts of information are thrown away, so to re-generate the source from an executable requires creativity and massive amounts of creative guesswork from the reverse engineer. Better to call him reverse creative artist actually.

Your final alleged C source, rehashed from the executable is, shall we say, open to question.

Who tells you the label names, for example? Oh whoops, Reverse creative artist calls them himself, whatever he wants to call them, and so on.

Perhaps for you. Not for me. I can't reconstruct variable names. But I can figure out what code is doing and then deduce reasonable names, given enough interest to do so.

Yeah, yeah, yeah, Bob.

Only there won't be deduced "reasonable names", there will be deduced deliberately, names that cirrespond to names in the target program, to make it seem there are more correspondences than there really might be.

That's the creativity.

Do you deny the use of identical names as target program wherever possible will be used? No, of course you don't. Because already that is what has happened in the disassemblys we've been presented with.

Creative creation of variable and function names, deliberately to match the target.

Let's be quite honest to all the lays trying to follow this, shall we?

I will say it again. If the instructions match exactly, and I then copy the names from one program and use them in the other on the same instructions, and everything matches and works properly, and suddenly the two programs appear to be identical, is that "creating" evidence or "discovering" evidence.

28% appears "identical"?

28% lines up and matches "exactly"?

Variable and function names deliberately chosen to match?

Hahahahahaha

Maybe in Creative Art 101.

I thought this was computer science.

I believe it is the twilight zone, but there's no point in arguing about it...

What would be fun, however, is for you to write a novel, and copy 28% of the text from (say) Tom Clancy. And then see how long you laugh. Be sure to tell the judge "it is only 28%, not the whole damned thing. Shoot, your honor, I changed 3 words on page 3..."

The probabilities of two things being derivative of the same depends on the % of similarity *AND* the length. You give the example of a novel, which is very large (several thousands of words). That is a fallacy.
For instance, in biochemistry, If you have two protein sequences of 100 amino acids, 28% similarity is not enough to claim an evolutionary or structural relationship. With DNA, is even worse. If the length increases, you may need a lower % to claim it.

If we both write a bubble sort routine, I am pretty sure that it will be very easy to find 28% of similar lines (particularly after compiling and disassembly!),. It will be a different story if 28% is present in a whole program of 100000 lines.

Miguel

I believe your last statement is what I have been saying all along. Although I think the probability of even 10% match is very low when you look at blocks. And no, I don't look at individual lines as meaning anything. But common structure (procedures, functions they provide), data structures, semantical programming structures. All are revealing.

If you believe my statement is what you are saying all along, why do you come up with the novel example? So you know that is an exaggerated argument and you use it anyway?

Miguel

I agreed with your last statement, but not particularly the rest. A chess program is _far_ longer than a novel, in terms of characters, words or lines. the probabllity of two independent programmers writing sections of _identical_ code is effectively zero. Which has nothing to do with DNA. The programming space is far larger than the potential DNA combination space, for one thing.

[tmokonen]

There is a page with evidence to show that El Chinito is a clone of Crafty?

Thank you.

Pedro

There was an admission and apology from Eugenio Castillo on the Arena web site at one time, I don't know if it is still there.

[michiguel]

...the argument that points how many programs or even all use the same algorythms is irrelevant as much they can be writen in so many different ways. So, he add, the reasonning that programs share lot of stuff, as Fabian said, would be not valid.
Ok. Then, if it is so and surely must be because, after all, Bob Hyatt and none other said that, if really the line of code and how was writen is the core of the issue, then let the attackers of Rybka originality show us specific lines of code that are equal to those from fruit.
Of course I wonder how they will do such a thing as much I presume the Rybka lines of code are not easily accesible.

Wondering regards
fern

What is being done is to take the executable, and run in thru a disassembler which produces the assembly language code the compiler produced when the source was compiled. An experienced programmer can then take that assembly language code and reconstruct the C source code it came from.

inc i => i++; in C for example.

It takes time because the optimizer in the compiler re-orders instructions to make them run as efficiently as possible, so the human reverse-engineer has to undo all of that...

Perhaps you should also point out that when the executable code is compiled from the source in the first place, enormous amounts of information are thrown away, so to re-generate the source from an executable requires creativity and massive amounts of creative guesswork from the reverse engineer. Better to call him reverse creative artist actually.

Your final alleged C source, rehashed from the executable is, shall we say, open to question.

Who tells you the label names, for example? Oh whoops, Reverse creative artist calls them himself, whatever he wants to call them, and so on.

Perhaps for you. Not for me. I can't reconstruct variable names. But I can figure out what code is doing and then deduce reasonable names, given enough interest to do so.

Yeah, yeah, yeah, Bob.

Only there won't be deduced "reasonable names", there will be deduced deliberately, names that cirrespond to names in the target program, to make it seem there are more correspondences than there really might be.

That's the creativity.

Do you deny the use of identical names as target program wherever possible will be used? No, of course you don't. Because already that is what has happened in the disassemblys we've been presented with.

Creative creation of variable and function names, deliberately to match the target.

Let's be quite honest to all the lays trying to follow this, shall we?

I will say it again. If the instructions match exactly, and I then copy the names from one program and use them in the other on the same instructions, and everything matches and works properly, and suddenly the two programs appear to be identical, is that "creating" evidence or "discovering" evidence.

28% appears "identical"?

28% lines up and matches "exactly"?

Variable and function names deliberately chosen to match?

Hahahahahaha

Maybe in Creative Art 101.

I thought this was computer science.

I believe it is the twilight zone, but there's no point in arguing about it...

What would be fun, however, is for you to write a novel, and copy 28% of the text from (say) Tom Clancy. And then see how long you laugh. Be sure to tell the judge "it is only 28%, not the whole damned thing. Shoot, your honor, I changed 3 words on page 3..."

The probabilities of two things being derivative of the same depends on the % of similarity *AND* the length. You give the example of a novel, which is very large (several thousands of words). That is a fallacy.
For instance, in biochemistry, If you have two protein sequences of 100 amino acids, 28% similarity is not enough to claim an evolutionary or structural relationship. With DNA, is even worse. If the length increases, you may need a lower % to claim it.

If we both write a bubble sort routine, I am pretty sure that it will be very easy to find 28% of similar lines (particularly after compiling and disassembly!),. It will be a different story if 28% is present in a whole program of 100000 lines.

Miguel

I believe your last statement is what I have been saying all along. Although I think the probability of even 10% match is very low when you look at blocks. And no, I don't look at individual lines as meaning anything. But common structure (procedures, functions they provide), data structures, semantical programming structures. All are revealing.

If you believe my statement is what you are saying all along, why do you come up with the novel example? So you know that is an exaggerated argument and you use it anyway?

Miguel

I agreed with your last statement, but not particularly the rest. A chess program is _far_ longer than a novel, in terms of characters, words or lines. the probabllity of two independent programmers writing sections of _identical_ code is effectively zero. Which has nothing to do with DNA. The programming space is far larger than the potential DNA combination space, for one thing.

Not really. It depends on the length of both, the programs and the length of DNA. It is all about information content or entropy (as defined by C. Shannon in his Information Theory).

You cannot keep comparing things with different lengths. The case in point was 110 lines. The novel example does not apply.

Miguel

[chrisw]

Chris, I guess I know what you are doing right now. You talked to Vas, asking about all this stuff here. He is a really nice guy and you believed him that he didn't do anything wrong.

I believed him too when I asked right after the Rybka 1.0 release.

I hope you will not get disapointed to much one day. I mean that honestly.

Yes, his POV is mainly based on personal feelings -- it seems that for him is most important to contradict with all Bob Hyatt is saying on the matter. And to challenge EVERY point Bob Hyatt made.

He (ChrisW) is ready to deny that 2+2=4 written by two different people is the same because it's wriiten with different handwritings.

No, no!! I say 33 out of 114 is 28% and is different hand

Writing 2+2=4 is is not wrong, even if it was cribbed in class room

More often 2+2 makes 5 - it's what to look for

as in 100% identical = 28% identical

4000 corresponding identical code lines = metaphorical 4000 code lines

they will provide more examples, it's only a matter of time .....

Where did I wrote that there were "4000 corresponding identical code lines"?

At least until now your reasoning was just stubborn like "one line means nothing, let's go to the next, loop". Now you are making things up.

// Christophe

You are talking continuously about 4000 code lines. So they're neither corresponding, nor identical, nor consecutive? Just any old code lines?

Various examples below, accompanied by comments like: get 100000 monkeys off your hat, or "smart idiot" or "arrogant" or some other insult from you.

Christophe Theron wrote:
Another one: one line of code alone cannot breach the GPL. Let's look at this 4000 lines program. Line 1: cannot breach the GPL. OK check this one. Line 2: cannot breach the GPL. OK fine. Line 3: cannot breach... And so on.

Finally you will get your 1000000 monkeys off your hat.

You are (were) a programmer and deliberately play the smart idiot here. This is what I would call arrogant, because 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 Theron wrote:
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 Theron wrote:
(warning: the above is use of the argument: "one single line of code cannot violate any copyright, so 4000 of them cannot either")

[bob]

Several of the signs of pseudoscience are evident in this thread.

CCC members are encouraged to review them.

The problem is the "signs" are not in the things being presented with respect to potential code similiarities, it is in the rebuttals to this data which are just all over the place. Comparing two executables is absolute science at its best.

[bob]

...the argument that points how many programs or even all use the same algorythms is irrelevant as much they can be writen in so many different ways. So, he add, the reasonning that programs share lot of stuff, as Fabian said, would be not valid.
Ok. Then, if it is so and surely must be because, after all, Bob Hyatt and none other said that, if really the line of code and how was writen is the core of the issue, then let the attackers of Rybka originality show us specific lines of code that are equal to those from fruit.
Of course I wonder how they will do such a thing as much I presume the Rybka lines of code are not easily accesible.

Wondering regards
fern

What is being done is to take the executable, and run in thru a disassembler which produces the assembly language code the compiler produced when the source was compiled. An experienced programmer can then take that assembly language code and reconstruct the C source code it came from.

inc i => i++; in C for example.

It takes time because the optimizer in the compiler re-orders instructions to make them run as efficiently as possible, so the human reverse-engineer has to undo all of that...

Perhaps you should also point out that when the executable code is compiled from the source in the first place, enormous amounts of information are thrown away, so to re-generate the source from an executable requires creativity and massive amounts of creative guesswork from the reverse engineer. Better to call him reverse creative artist actually.

Your final alleged C source, rehashed from the executable is, shall we say, open to question.

Who tells you the label names, for example? Oh whoops, Reverse creative artist calls them himself, whatever he wants to call them, and so on.

Perhaps for you. Not for me. I can't reconstruct variable names. But I can figure out what code is doing and then deduce reasonable names, given enough interest to do so.

Yeah, yeah, yeah, Bob.

Only there won't be deduced "reasonable names", there will be deduced deliberately, names that cirrespond to names in the target program, to make it seem there are more correspondences than there really might be.

That's the creativity.

Do you deny the use of identical names as target program wherever possible will be used? No, of course you don't. Because already that is what has happened in the disassemblys we've been presented with.

Creative creation of variable and function names, deliberately to match the target.

Let's be quite honest to all the lays trying to follow this, shall we?

I will say it again. If the instructions match exactly, and I then copy the names from one program and use them in the other on the same instructions, and everything matches and works properly, and suddenly the two programs appear to be identical, is that "creating" evidence or "discovering" evidence.

28% appears "identical"?

28% lines up and matches "exactly"?

Variable and function names deliberately chosen to match?

Hahahahahaha

Maybe in Creative Art 101.

I thought this was computer science.

I believe it is the twilight zone, but there's no point in arguing about it...

What would be fun, however, is for you to write a novel, and copy 28% of the text from (say) Tom Clancy. And then see how long you laugh. Be sure to tell the judge "it is only 28%, not the whole damned thing. Shoot, your honor, I changed 3 words on page 3..."

The probabilities of two things being derivative of the same depends on the % of similarity *AND* the length. You give the example of a novel, which is very large (several thousands of words). That is a fallacy.
For instance, in biochemistry, If you have two protein sequences of 100 amino acids, 28% similarity is not enough to claim an evolutionary or structural relationship. With DNA, is even worse. If the length increases, you may need a lower % to claim it.

If we both write a bubble sort routine, I am pretty sure that it will be very easy to find 28% of similar lines (particularly after compiling and disassembly!),. It will be a different story if 28% is present in a whole program of 100000 lines.

Miguel

I believe your last statement is what I have been saying all along. Although I think the probability of even 10% match is very low when you look at blocks. And no, I don't look at individual lines as meaning anything. But common structure (procedures, functions they provide), data structures, semantical programming structures. All are revealing.

If you believe my statement is what you are saying all along, why do you come up with the novel example? So you know that is an exaggerated argument and you use it anyway?

Miguel

I agreed with your last statement, but not particularly the rest. A chess program is _far_ longer than a novel, in terms of characters, words or lines. the probabllity of two independent programmers writing sections of _identical_ code is effectively zero. Which has nothing to do with DNA. The programming space is far larger than the potential DNA combination space, for one thing.

Not really. It depends on the length of both, the programs and the length of DNA. It is all about information content or entropy (as defined by C. Shannon in his Information Theory).

You cannot keep comparing things with different lengths. The case in point was 110 lines. The novel example does not apply.

Miguel

It wasn't 110 lines. It was 110 lines that were very similar out of 40,000 total lines or however long the two specific programs are. That 110 lines was _remarkably_ similar when you consider that it is just one sample (so far). As a case is presented, there is always a "first piece of evidence" that is presented, but fortunately in a courtroom, you get to present it all, then the defense gets to start picking it apart if they can. This has just gotten started. So trying to say that a couple of hundred lines is not enough is (a) wrong, as that kind of similarity is nowhere near normal and (b) premature as more will be coming.