Speaking of false evidence...

[CThinker]

not to hijack the thread, but I noticed duplicate posts from you. Are you seeing huge delays when you click submit? And I do mean sometimes _huge_ delays???

I thought the first one didn't make it. So, I did another one and removed the massive quote.

[Tony]

Should be interesting to see how the accusers respond to this!

I hope that they respond as follows:
1. Download the disassembly tools or use their favorite disassembler.
2. Disassemble the binaries themselves.
3. Examine the resulting listings carefully.
4. Form their own conclusions.

I will be genuinely interested in what they have to say if they actually perform these steps. I am not interested in discourse with anyone who has not done so, because they are running on hearsay evidence and evidence I believe to be largely fabricated.

Would you now like to perhaps retract that last statement? rather than someone fabricating something, you simply didn't understand how to use the tools you listed in order to conclude anything that was even close to being correct. That is the very kind of thing we _don't_ need to happen. It only hurts the discussion. I looked at the asm you posted. It appears that it might well be the binary for strtok(). the source for strtok() is quite large, because of the way it is written using other string functions, and if necessary I could easily compile the thing and produce the assembly output to show this... That is the code you said was not called and did not appear anywhere. Which is impossible to verify with a stripped executable. Stripping saves memory, but also hides much. It is not a 10 minute job (which it appears you thought it was) to make these kinds of determinations. it is more complicated than that because of conditions beyond anybody's control (stripping for one). If this were a linux executable we wouldn't even be having this discussion because strtok() would not be anywhere in the executable, it is in a shared lib that is a separate entity.

He isn't as neutral as he tries to appear to be ( see my response 1 page back)

Besides: If you can't recognize Fruit in the Strelka code, how big are the chances you can recognize simmularities in assembly.


Tony

I'm not so willing to jump that far to suspect bias. But clearly there was a gross misunderstanding of disassembled code somehow... To do this kind of stuff, you need one extra tool that he didn't mention, that being enough experience at looking at asm code to recognize it for what it is. This is not "obfuscated" intentionally but when something gets the symbol tables stripped away, the result is a real pain to read.

I've had the same discussion with Dan about the sourcecode of Strelka and Fruit.

Dan claimed they were not related.

Tony

[bob]

Should be interesting to see how the accusers respond to this!

I hope that they respond as follows:
1. Download the disassembly tools or use their favorite disassembler.
2. Disassemble the binaries themselves.
3. Examine the resulting listings carefully.
4. Form their own conclusions.

I will be genuinely interested in what they have to say if they actually perform these steps. I am not interested in discourse with anyone who has not done so, because they are running on hearsay evidence and evidence I believe to be largely fabricated.

Would you now like to perhaps retract that last statement? rather than someone fabricating something, you simply didn't understand how to use the tools you listed in order to conclude anything that was even close to being correct. That is the very kind of thing we _don't_ need to happen. It only hurts the discussion. I looked at the asm you posted. It appears that it might well be the binary for strtok(). the source for strtok() is quite large, because of the way it is written using other string functions, and if necessary I could easily compile the thing and produce the assembly output to show this... That is the code you said was not called and did not appear anywhere. Which is impossible to verify with a stripped executable. Stripping saves memory, but also hides much. It is not a 10 minute job (which it appears you thought it was) to make these kinds of determinations. it is more complicated than that because of conditions beyond anybody's control (stripping for one). If this were a linux executable we wouldn't even be having this discussion because strtok() would not be anywhere in the executable, it is in a shared lib that is a separate entity.

He isn't as neutral as he tries to appear to be ( see my response 1 page back)

Besides: If you can't recognize Fruit in the Strelka code, how big are the chances you can recognize simmularities in assembly.


Tony

I'm not so willing to jump that far to suspect bias. But clearly there was a gross misunderstanding of disassembled code somehow... To do this kind of stuff, you need one extra tool that he didn't mention, that being enough experience at looking at asm code to recognize it for what it is. This is not "obfuscated" intentionally but when something gets the symbol tables stripped away, the result is a real pain to read.

I've had the same discussion with Dan about the sourcecode of Strelka and Fruit.

Dan claimed they were not related.

Tony

Here's my take on that. Students will tell you that I can look at most any program they bring by and point out errors in seconds, and they wonder how. The answer is experience. Lots of experience. There's probably no bugs they can bring by that I haven't seen a hundred or a thousand times previously in 38 years of teaching.

All that is to say that those of us that work on these things every day pick up on things that a non-chess-programmer would have difficulty recognizing. Remember the old DeGroot experiments where GMs recalled positions far better than non-chess players? Same here. There are lots of things that just "stand out" to those of us that have been reading and writing this kind of code for years. same for me and operating system topics. I have been thru the linux source enough to know where most everything is done, and in many cases how it is done (if I happened to be interested in that topic at some point). It is just my nature to do that since I have worked on OS stuff for so long. I am the wrong person to look at some of the huge numerical simulation codes, such as one I am thinking of that is over 7,000,000 lines of FORTRAN at Los Alamos. I'm an avid sci fi fan. I'm not an avid british literature fan. So in areas where I am interested, I am pretty good at understanding what is going on. And I try to limit myself to working on things I am good at, whenever possible. My brother loves writing cobol. I would slit my wrists if I had to do that for 20 years.

[Uri Blass]

Should be interesting to see how the accusers respond to this!

I hope that they respond as follows:
1. Download the disassembly tools or use their favorite disassembler.
2. Disassemble the binaries themselves.
3. Examine the resulting listings carefully.
4. Form their own conclusions.

I will be genuinely interested in what they have to say if they actually perform these steps. I am not interested in discourse with anyone who has not done so, because they are running on hearsay evidence and evidence I believe to be largely fabricated.

Would you now like to perhaps retract that last statement? rather than someone fabricating something, you simply didn't understand how to use the tools you listed in order to conclude anything that was even close to being correct. That is the very kind of thing we _don't_ need to happen. It only hurts the discussion. I looked at the asm you posted. It appears that it might well be the binary for strtok(). the source for strtok() is quite large, because of the way it is written using other string functions, and if necessary I could easily compile the thing and produce the assembly output to show this... That is the code you said was not called and did not appear anywhere. Which is impossible to verify with a stripped executable. Stripping saves memory, but also hides much. It is not a 10 minute job (which it appears you thought it was) to make these kinds of determinations. it is more complicated than that because of conditions beyond anybody's control (stripping for one). If this were a linux executable we wouldn't even be having this discussion because strtok() would not be anywhere in the executable, it is in a shared lib that is a separate entity.

He isn't as neutral as he tries to appear to be ( see my response 1 page back)

Besides: If you can't recognize Fruit in the Strelka code, how big are the chances you can recognize simmularities in assembly.


Tony

I'm not so willing to jump that far to suspect bias. But clearly there was a gross misunderstanding of disassembled code somehow... To do this kind of stuff, you need one extra tool that he didn't mention, that being enough experience at looking at asm code to recognize it for what it is. This is not "obfuscated" intentionally but when something gets the symbol tables stripped away, the result is a real pain to read.

I've had the same discussion with Dan about the sourcecode of Strelka and Fruit.

Dan claimed they were not related.

Tony

This is not only the opinion of Dann and I remember that Tord also said something similiar.

The question is how much similiarity is allowed in chess programs and there are clearly different opinions about it.

Your opinion and Bob hyatt's opinion seem to be also against taking ideas
if you take too much because if you understand the code well and have a good memory then you may even write from scratch a code that is almost identical without copy and paste.

Chess programs are also different from book.
Every programmer want to be the best so if somebody has good ideas and you understand them it is not logical to modify it to inferior code.

This is the reason that I think that my opinion is that in chess programs(unlike books)sections of equivalent code are not always a proof for copying.

Uri

[Tony]

Should be interesting to see how the accusers respond to this!

I hope that they respond as follows:
1. Download the disassembly tools or use their favorite disassembler.
2. Disassemble the binaries themselves.
3. Examine the resulting listings carefully.
4. Form their own conclusions.

I will be genuinely interested in what they have to say if they actually perform these steps. I am not interested in discourse with anyone who has not done so, because they are running on hearsay evidence and evidence I believe to be largely fabricated.

Would you now like to perhaps retract that last statement? rather than someone fabricating something, you simply didn't understand how to use the tools you listed in order to conclude anything that was even close to being correct. That is the very kind of thing we _don't_ need to happen. It only hurts the discussion. I looked at the asm you posted. It appears that it might well be the binary for strtok(). the source for strtok() is quite large, because of the way it is written using other string functions, and if necessary I could easily compile the thing and produce the assembly output to show this... That is the code you said was not called and did not appear anywhere. Which is impossible to verify with a stripped executable. Stripping saves memory, but also hides much. It is not a 10 minute job (which it appears you thought it was) to make these kinds of determinations. it is more complicated than that because of conditions beyond anybody's control (stripping for one). If this were a linux executable we wouldn't even be having this discussion because strtok() would not be anywhere in the executable, it is in a shared lib that is a separate entity.

He isn't as neutral as he tries to appear to be ( see my response 1 page back)

Besides: If you can't recognize Fruit in the Strelka code, how big are the chances you can recognize simmularities in assembly.


Tony

I'm not so willing to jump that far to suspect bias. But clearly there was a gross misunderstanding of disassembled code somehow... To do this kind of stuff, you need one extra tool that he didn't mention, that being enough experience at looking at asm code to recognize it for what it is. This is not "obfuscated" intentionally but when something gets the symbol tables stripped away, the result is a real pain to read.

I've had the same discussion with Dan about the sourcecode of Strelka and Fruit.

Dan claimed they were not related.

Tony

Here's my take on that. Students will tell you that I can look at most any program they bring by and point out errors in seconds, and they wonder how. The answer is experience. Lots of experience. There's probably no bugs they can bring by that I haven't seen a hundred or a thousand times previously in 38 years of teaching.

All that is to say that those of us that work on these things every day pick up on things that a non-chess-programmer would have difficulty recognizing. Remember the old DeGroot experiments where GMs recalled positions far better than non-chess players? Same here. There are lots of things that just "stand out" to those of us that have been reading and writing this kind of code for years. same for me and operating system topics. I have been thru the linux source enough to know where most everything is done, and in many cases how it is done (if I happened to be interested in that topic at some point). It is just my nature to do that since I have worked on OS stuff for so long. I am the wrong person to look at some of the huge numerical simulation codes, such as one I am thinking of that is over 7,000,000 lines of FORTRAN at Los Alamos. I'm an avid sci fi fan. I'm not an avid british literature fan. So in areas where I am interested, I am pretty good at understanding what is going on. And I try to limit myself to working on things I am good at, whenever possible. My brother loves writing cobol. I would slit my wrists if I had to do that for 20 years.

I have been at a chesstournement where a new guy was participating. At the bar, I helped him taking out some bugs. I had a couple of beers (too much) and had to close one eye to avoid seeing the screen double, but his bugs still "jumped out" so much that that didn't matter.

No problems with people who can't do that.

I have problems with people not having this knowledge, claiming to have it, and questioning the credibility of people who do have this knowledge, by saying things that are more popular / fit their own agenda better.

Tony

[Osipov Jury]

I will also note that the Strelka assembly you posted does not contain the word strtok

Strelka 1.0 beta not contain strtok() because it not contain UCI-parser. This version was Winboard engine, and WB-parser was stolen from Beowulf of Dann Corbit. Therefore Strelka 1.0 beta may be consider as clone of Beowulf, not clone of Fruit or Rybka.

[tiger]

Should be interesting to see how the accusers respond to this!

I hope that they respond as follows:
1. Download the disassembly tools or use their favorite disassembler.
2. Disassemble the binaries themselves.
3. Examine the resulting listings carefully.
4. Form their own conclusions.

I will be genuinely interested in what they have to say if they actually perform these steps. I am not interested in discourse with anyone who has not done so, because they are running on hearsay evidence and evidence I believe to be largely fabricated.

Would you now like to perhaps retract that last statement? rather than someone fabricating something, you simply didn't understand how to use the tools you listed in order to conclude anything that was even close to being correct. That is the very kind of thing we _don't_ need to happen. It only hurts the discussion. I looked at the asm you posted. It appears that it might well be the binary for strtok(). the source for strtok() is quite large, because of the way it is written using other string functions, and if necessary I could easily compile the thing and produce the assembly output to show this... That is the code you said was not called and did not appear anywhere. Which is impossible to verify with a stripped executable. Stripping saves memory, but also hides much. It is not a 10 minute job (which it appears you thought it was) to make these kinds of determinations. it is more complicated than that because of conditions beyond anybody's control (stripping for one). If this were a linux executable we wouldn't even be having this discussion because strtok() would not be anywhere in the executable, it is in a shared lib that is a separate entity.

He isn't as neutral as he tries to appear to be ( see my response 1 page back)

Besides: If you can't recognize Fruit in the Strelka code, how big are the chances you can recognize simmularities in assembly.


Tony

I'm not so willing to jump that far to suspect bias. But clearly there was a gross misunderstanding of disassembled code somehow... To do this kind of stuff, you need one extra tool that he didn't mention, that being enough experience at looking at asm code to recognize it for what it is. This is not "obfuscated" intentionally but when something gets the symbol tables stripped away, the result is a real pain to read.

I've had the same discussion with Dan about the sourcecode of Strelka and Fruit.

Dan claimed they were not related.

Tony

This is not only the opinion of Dann and I remember that Tord also said something similiar.

The question is how much similiarity is allowed in chess programs and there are clearly different opinions about it.

Your opinion and Bob hyatt's opinion seem to be also against taking ideas
if you take too much because if you understand the code well and have a good memory then you may even write from scratch a code that is almost identical without copy and paste.

Chess programs are also different from book.
Every programmer want to be the best so if somebody has good ideas and you understand them it is not logical to modify it to inferior code.

This is the reason that I think that my opinion is that in chess programs(unlike books)sections of equivalent code are not always a proof for copying.

Uri

As you already told us that you program mainly by copying and pasting short sections of code from examples, is there a possibility that you feel that your way of building your chess program could be considered illegal?



// Christophe

[Sven]

Hi Jury,

maybe you answered this already, but now that you are posting here I'm just curious to know:

Can you give a statement as to how much code, and approximately which code, was taken from Rybka binary (which version) and how much/which from Fruit 2.1 source, when creating Strelka (> 1.0)? Especially the part that was taken from Fruit but not from Rybka would be interesting for me.

I only ask because your answer _might_ give us some hints in the current "Rybka derived from Fruit?" analysis.

For me only the facts are important, I'm not interested in any personal or economic aspects here, I want to help to find out a bit more of the truth.

Sven

[Uri Blass]

Should be interesting to see how the accusers respond to this!

I hope that they respond as follows:
1. Download the disassembly tools or use their favorite disassembler.
2. Disassemble the binaries themselves.
3. Examine the resulting listings carefully.
4. Form their own conclusions.

I will be genuinely interested in what they have to say if they actually perform these steps. I am not interested in discourse with anyone who has not done so, because they are running on hearsay evidence and evidence I believe to be largely fabricated.

Would you now like to perhaps retract that last statement? rather than someone fabricating something, you simply didn't understand how to use the tools you listed in order to conclude anything that was even close to being correct. That is the very kind of thing we _don't_ need to happen. It only hurts the discussion. I looked at the asm you posted. It appears that it might well be the binary for strtok(). the source for strtok() is quite large, because of the way it is written using other string functions, and if necessary I could easily compile the thing and produce the assembly output to show this... That is the code you said was not called and did not appear anywhere. Which is impossible to verify with a stripped executable. Stripping saves memory, but also hides much. It is not a 10 minute job (which it appears you thought it was) to make these kinds of determinations. it is more complicated than that because of conditions beyond anybody's control (stripping for one). If this were a linux executable we wouldn't even be having this discussion because strtok() would not be anywhere in the executable, it is in a shared lib that is a separate entity.

He isn't as neutral as he tries to appear to be ( see my response 1 page back)

Besides: If you can't recognize Fruit in the Strelka code, how big are the chances you can recognize simmularities in assembly.


Tony

I'm not so willing to jump that far to suspect bias. But clearly there was a gross misunderstanding of disassembled code somehow... To do this kind of stuff, you need one extra tool that he didn't mention, that being enough experience at looking at asm code to recognize it for what it is. This is not "obfuscated" intentionally but when something gets the symbol tables stripped away, the result is a real pain to read.

I've had the same discussion with Dan about the sourcecode of Strelka and Fruit.

Dan claimed they were not related.

Tony

This is not only the opinion of Dann and I remember that Tord also said something similiar.

The question is how much similiarity is allowed in chess programs and there are clearly different opinions about it.

Your opinion and Bob hyatt's opinion seem to be also against taking ideas
if you take too much because if you understand the code well and have a good memory then you may even write from scratch a code that is almost identical without copy and paste.

Chess programs are also different from book.
Every programmer want to be the best so if somebody has good ideas and you understand them it is not logical to modify it to inferior code.

This is the reason that I think that my opinion is that in chess programs(unlike books)sections of equivalent code are not always a proof for copying.

Uri

As you already told us that you program mainly by copying and pasting short sections of code from examples, is there a possibility that you feel that your way of building your chess program could be considered illegal?



// Christophe

I did not say that I program mainly by copying and pasting short section of code from examples.

It is a distortion of my words and most of movei's code is clearly not based on copying and pasting and certainly most of the time of coding is not about copying and pasting.

I worked a lot of time on my move generator.
I have original structure of the board that is not 0x88 or bitboards
so I certainly could not use copy and paste for that code.

Note that I practically did not understand much of fruit or strelka
so part of the reason that movei is more original is the fact that
I did not fully undertstand code of others and used ideas that I did not read from other sources.

I will probably quit chess programming(not that I worked on it in the last months) because it seems to me that if I understand the code of other people and use ideas to improve my program then people are going to consider it as non original and even if I use ideas from fruit to write a go playing program people may blame me that it is against the gpl so I am probably not going to program even non chess game playing program.

Uri

[Osipov Jury]

What's the difference how much code was borrowed/stolen from Fruit by Vas and me? As a result now we have Rybka 3. It is a very great achievement of human race. We all must be very happy, and express many thanks to Vas.