Peter Aloysius wrote:Back when I was first year in college, all students in my class were given a simple assignment : to write a program that show a ball bouncing in the screen until user hit esc button. It was a very very SIMPLE task comparing to writing ANY PART of a chess engine.
And yet, each one who were not cheating (it's about 40-50 students) came with different approachs and different code, none look similiar or nearly similiar to others. Different person came with code that similiar can only has one meaning: someone must copy from other.
Peter, this is common knowledge in computer science departments. But you are not going to convince many here that it is actually true. I've been giving assignments for 38 years now, and duplicate programs just do not happen by accident. Never have, never will. There are _way_ too many ways to write a program that implements some algorithm. Actually there are always an infinite number of ways to write such programs, but most would be considered silly.
Consider this grey scale ....
there's an infinite number of ways to write a program if done by monkeys
there's many ways to write a program if done by your inexperienced students, for they have learnt no chunks yet
experienced programmers, especially those operating in a confined field, will use fewer different ways to write the same program because they know already which of the subset of chunks will suit
an experienced programmer who looked at another experienced programmer's program may well tend to write something similar
Peter Aloysius wrote:Back when I was first year in college, all students in my class were given a simple assignment : to write a program that show a ball bouncing in the screen until user hit esc button. It was a very very SIMPLE task comparing to writing ANY PART of a chess engine.
And yet, each one who were not cheating (it's about 40-50 students) came with different approachs and different code, none look similiar or nearly similiar to others. Different person came with code that similiar can only has one meaning: someone must copy from other.
and maybe I should add : some student try to cheating by copying from other and changing variable name, reversing variable declaration, and such. And those cheater always got caught. Always.
Can't be so. That would be dishonest reconstruction to get from B to A. I know that because it has been said here many times.
chrisw wrote:
I don't understand what you are doing. You told us you are producing and have more material and will be publishing it. I've said on many occasions now I don't want to keep having discussions until your new material is out. Vas says he is waiting for it. Yet, your side is continually harping back to this really quite weak, or maybe from your point of view, not exactly universally accepted UCI example. It clear that you know/knew that you needed more or something else to make progress with your case.
You realise it won't just be me who intuits that your hunt for more evidence has ground to a halt? Don't you? Why else are you here banging on about the old stuff? Why here now again on the old stuff? If not because the other hunt has failed?
these seem like reasonable questions to me at this point
Zach should at least "update" us as to the progress of his other evidence....just a word or two that he is still working on it with a guestimate as to its completion date..
in light of the fact that Vas is waiting for a complete list of questions and also because the General forum has basically now been overrun with programming type posts regarding the clone issue
perhaps Zach can mention if he is still working on the other evidence or if his position now is to stand pat and wait for Vas to answer the first and only question presented
if to stand pat...
then we have basically a stalemate here..
if this is the case i move that all technical posts regarding the clone issue be moved to the programming forum ..because in reality this has become a course in programming which really does not belong in General
IMHO Regards
Steve
we have been communicating via email since the signal/noise ratio here is abysmal. This analysis is still going on. The general consensus has been to say nothing more until there is a big body of information to present, so that we don't go down the same path over and over. Too many similarities can't be passed off as "just chance, since parse_go() is very specific in what it must do."
Decades of experience hasveshown that even simple assignments do not turn into identical source implementations, but that point is not going to be accepted except by those of use with either actual experience, or knowing those that have had this experience and seen the results.
Peter Aloysius wrote:Back when I was first year in college, all students in my class were given a simple assignment : to write a program that show a ball bouncing in the screen until user hit esc button. It was a very very SIMPLE task comparing to writing ANY PART of a chess engine.
And yet, each one who were not cheating (it's about 40-50 students) came with different approachs and different code, none look similiar or nearly similiar to others. Different person came with code that similiar can only has one meaning: someone must copy from other.
Peter, this is common knowledge in computer science departments. But you are not going to convince many here that it is actually true. I've been giving assignments for 38 years now, and duplicate programs just do not happen by accident. Never have, never will. There are _way_ too many ways to write a program that implements some algorithm. Actually there are always an infinite number of ways to write such programs, but most would be considered silly.
Consider this grey scale ....
there's an infinite number of ways to write a program if done by monkeys
there's many ways to write a program if done by your inexperienced students, for they have learnt no chunks yet
experienced programmers, especially those operating in a confined field, will use fewer different ways to write the same program because they know already which of the subset of chunks will suit
an experienced programmer who looked at another experienced programmer's program may well tend to write something similar
I am as experienced as anyone here. So feel free to look at my public source and show where there are lots of similarities and even a few identical blocks of code that match up with another program.
you do not get the point about "similar". We are talking about identical pieces here and there. That will absolutely _not_ happen. At least not naturally. Copying is the only viable explanation.
chrisw wrote:experienced programmers, especially those operating in a confined field, will use fewer different ways to write the same program because they know already which of the subset of chunks will suit
Experienced chessplayers play always nearly the same moves. Nevertheless there are millions of different GM Games.
Peter Aloysius wrote:Back when I was first year in college, all students in my class were given a simple assignment : to write a program that show a ball bouncing in the screen until user hit esc button. It was a very very SIMPLE task comparing to writing ANY PART of a chess engine.
And yet, each one who were not cheating (it's about 40-50 students) came with different approachs and different code, none look similiar or nearly similiar to others. Different person came with code that similiar can only has one meaning: someone must copy from other.
Peter, this is common knowledge in computer science departments. But you are not going to convince many here that it is actually true. I've been giving assignments for 38 years now, and duplicate programs just do not happen by accident. Never have, never will. There are _way_ too many ways to write a program that implements some algorithm. Actually there are always an infinite number of ways to write such programs, but most would be considered silly.
Consider this grey scale ....
there's an infinite number of ways to write a program if done by monkeys
there's many ways to write a program if done by your inexperienced students, for they have learnt no chunks yet
experienced programmers, especially those operating in a confined field, will use fewer different ways to write the same program because they know already which of the subset of chunks will suit
an experienced programmer who looked at another experienced programmer's program may well tend to write something similar
I am as experienced as anyone here. So feel free to look at my public source and show where there are lots of similarities and even a few identical blocks of code that match up with another program.
you do not get the point about "similar". We are talking about identical pieces here and there. That will absolutely _not_ happen. At least not naturally. Copying is the only viable explanation.
I would expect there are amateur programs with code 'similar' to yours. Some few perhaps by direct cut 'n paste, some by rewrite or studying your ideas and repeating in their own way.
Peter Aloysius wrote:Back when I was first year in college, all students in my class were given a simple assignment : to write a program that show a ball bouncing in the screen until user hit esc button. It was a very very SIMPLE task comparing to writing ANY PART of a chess engine.
And yet, each one who were not cheating (it's about 40-50 students) came with different approachs and different code, none look similiar or nearly similiar to others. Different person came with code that similiar can only has one meaning: someone must copy from other.
Peter, this is common knowledge in computer science departments. But you are not going to convince many here that it is actually true. I've been giving assignments for 38 years now, and duplicate programs just do not happen by accident. Never have, never will. There are _way_ too many ways to write a program that implements some algorithm. Actually there are always an infinite number of ways to write such programs, but most would be considered silly.
Consider this grey scale ....
there's an infinite number of ways to write a program if done by monkeys
there's many ways to write a program if done by your inexperienced students, for they have learnt no chunks yet
experienced programmers, especially those operating in a confined field, will use fewer different ways to write the same program because they know already which of the subset of chunks will suit
an experienced programmer who looked at another experienced programmer's program may well tend to write something similar
I am as experienced as anyone here. So feel free to look at my public source and show where there are lots of similarities and even a few identical blocks of code that match up with another program.
you do not get the point about "similar". We are talking about identical pieces here and there. That will absolutely _not_ happen. At least not naturally. Copying is the only viable explanation.
I would expect there are amateur programs with code 'similar' to yours. Some few perhaps by direct cut 'n paste, some by rewrite or studying your ideas and repeating in their own way.
You will probably expect pigs to fly. But I am not sitting around, waiting for some bacon to fly into my frying pan so that I can eat. I don't want to starve. If there is similar code, it was copied. It was not written by studying my ideas and repeating in their own way...
chrisw wrote:experienced programmers, especially those operating in a confined field, will use fewer different ways to write the same program because they know already which of the subset of chunks will suit
Experienced chessplayers play always nearly the same moves. Nevertheless there are millions of different GM Games.
Please don't confuse the discussion by introducing insightful comments.
