bob wrote:Sven Schüle wrote:bob wrote:Sven Schüle wrote:bob wrote:As far as "If he might be correct" I have looked at the code. I've already verified that this is a duck. No point in trying to waste any time to attempt to convince me it is a pig in a duck's suit.
Just to confirm: does that mean you have looked in detail into the disassembled R1 binary?
In case you have, what have you seen when comparing that to the Fruit 2.1 source? Which parts of R1 did you look at: only those listed by Zach, or more (which)?
In case you haven't, and I misunderstood your remark, what else did you mean by "I have looked at the code"?
I looked at what Zach has posted. I looked at other small pieces when this first started.
So what Zach has posted is "the code" for you. Up to now I had thought you had participated in the detailled analysis itself, I was mistaken in assuming that
Please stop trying to imagine what I did. We had a _ton_ of "offline_ discussions via email. Zach, Theron, and I don't remember who else. _THAT_ is the stuff I looked it, not just what he released on his web page so far...
You can calm down again, no need to get angry. I'm not writing BS. I just show how you say things differently from time to time (see above)
If that is what you looked at then you have seen more than what is currently known to the public. But as long as you insist that the proof is already there for everyone, we can only consider the "public" part, not what has been discussed privately. You could not claim "there is the proof for everyone" in one second, but then say that the important part were non-public. I know you don't, so our current base is what is published for everyone to compare. Agreed?
bob wrote:You verified his publication by looking at his publication. Good. Let's assume this is science. "Looks like a duck - is a duck."
Actually, how about not "let's assume" anything? We tried to discuss this on CCC. Got way too noisy so we took it offline for quite a while. That was what convinced me something was amiss. Clear enough, now? I have said this plenty of times in the past, by the way, so it isn't exactly "headline news."
You know as well as I do how my sentence "Let's assume this is science." was meant. One of my points is still that I don't know how much you have really looked into the assembler code of R1. You may have written a lot around that topic but I can't recall you ever made *this* clear enough.
bob wrote:But since you know the Zach examples, which of these points would serve "best" from your viewpoint to prove that code was literally copied from Fruit 2.1 to Rybka 1.0 beta? Just one example is sufficient in the beginning.
The first one that jumped out at me when we started the process was the code segment containing the setjmp()/longjmp() construct. You can find references to this in the past. It is an unusual way to unwind a search that is not thread-happy, and invites very subtle bugs. The usage was identical in both programs with the surrounding code. There were others.
I remember that we had some PMs about this setjmp() usage. My opinion has not changed much since then. There are not many possible ways how setjmp()/longjmp() can be used to break from an arbitrary level of recursion and return to a defined point of control by unwinding the stack. No need to explain this to you, just for everyone else: there is always exactly one "setjmp()" call that defines the point to return to, and one or more places where calling longjmp() causes that unwinding, e.g. to interrupt the search. Not many choices to implement this basic technique. And no, it is *not* unusual to do so, even if *you* claim it. I accept the note about that concept being potentially error-prone but this is what a software developer can be able to deal with. It *can* be implemented safely under certain conditions (single-threaded may be one), and when doing so it also slightly improves readability of the search code itself since you do not need "if (search is stopped)" conditions here and there. So using setjmp()/longjmp() like another program does is *not* an indication of code copying, it is reusing an idea at best.
Your turn again? I think you did not start with the "best" candidate but with the first that came into mind.
Sven
P.S.: Btw, do you know
this book? Have a look at the top of page 3 of chapter one. “transformative derivative work” - didn't know that term up to now. Any change after that?