I picked the "main one". You _did_ quote _both_ as being "verbatim copies" after all. So do we take the first one? Fine by me. here's the code from 19.0:Milos wrote:You are intentionally comparing this one, but not the other one from root.c. Coincidence? No I don't think so.bob wrote:Are you a programmer type? Do you know what you are doing? Because just looking at the loop initialization/termination code would show you that what is in Crafty is _not_ in Knuth's code.
for (movep = tree->last[ply - 1]; movep < tree->last[ply] - 1; movep++, sortv++)
Hmm. I am using pointers. Knuth uses a simple integer subscript. I even increment two values in the loop, while Knuth uses just one variable for the loop counter. Yeah, those are _identical_.
Code: Select all
do {
done=1;
for (i=0;i<lastm-rmoves-1;i++) {
if (sort_value[i] < sort_value[i+1]) {
temp=sort_value[i];
sort_value[i]=sort_value[i+1];
sort_value[i+1]=temp;
temp=rmoves[i];
rmoves[i]=rmoves[i+1];
rmoves[i+1]=temp;
done=0;
}
}
} while(!done);
[/quote]
Classic bubble sort. I see _nothing_ verbatim there. I am sorting _two_ values, not just one. I have a value, and a move. I am sorting the moves, but I am using the value as the sort key. So I move both around. Is Knuth doing that? Of course not. Code is different. I have not said "this is not a bubble sort, it is something original I wrote." I have said that "this is a bubble-sort that is my original code, it was not copied from _anywhere_." And that statement stands, and you have not contradicted it in the least.
Now that is 2 out of the 4 sorts you find in Crafty. Do we go through the other two as well. Again. _nothing_ has been copied.
[quote]
Btw. there is no concept of "pointer" in assembler code. There are just different types of addressing. Strange that you don't know that. [/quote]
There is a lot that you don't know. Did you know that the old Xerox sigma 6, 7 and 9 computers had pointers? if the high order bit of something used as an address was set, then that indicated that the value was "indirect" and had to be dereferenced. And it was recursive. Lot you don't know.
In assembly language, most of us consider this a pointer:
mov eax, [ebx]
where this is a simple value:
mov eax, ebx.
Yes, it is also called "register indirect". It's a pointer. The register doesn't contain the value, it contains the address of the value. That's a pointer.
[quote]
[quote]Sorry. But there are a couple of well-known bugs in Crafty 19.0. They are present in Rybka 1.6.1. There is no doubt that code was copied, as there is no possible reason those two bugs would have been written by another programmer, for reasons long since explained... Try again.[/quote]
Having no reason for bugs is not enough to prove verbatim copying, at least not according to your definition. And btw. in Crafty 19.0 you use pointers, there are no pointers in disassembled Rybka 1.6.1. So again no verbatim coping. Again you fall in you own trap.
[/quote]
I don't even want to guess what you are talking about. But it is certainly technically irrelevant and incorrect, so there's no point in trying to figure it out.
[quote]
[quote]Why don't you _try_ it rather than guessing? You might figure out that I did. The code is shorter. It is less "branchy". And again, for 2 or 3 values, it is almost impossible to beat it...[/quote]
And you know that by what, your hunch?
All that probability analysis Knuth gives is nothing compared to your hunch, right? :lol: [/quote]
Not a "hunch". It is more correctly called "experimental testing." Feel free to rip the insertion sort out of next.c and copy it into quiesce.c. It will plug in perfectly. See what happens. No guesswork. No wondering. Just run a 2 billion node search with each and see which one is faster. Then you don't need a hunch. I certainly didn't need one.
[quote]
[quote]Then I guess you are not going to ever retract that "verbatim copy" nonsense for starters? Didn't think so...[/quote]
You are the one who resorts to changing definitions on the way how it suits him. For Crafty/Rybka, Fruit/Rybka, Houdini/Robbo, etc. you have one definition, and for Knuth/Crafty you have another. Sorry, but that's not acceptable.[/quote]
I'm not changing _anything_. In our analysis of Rybka, we showed several complete functions from Rybka. Compared directly to the same functions in Crafty. The code was _identical_. You compile your "knuth code" and compare the compiler output to my sort and see how "identical they are." Then you can join the argument intelligently.
[quote]
[quote]I believe I asked you do do that first. So far you have not...[/quote]
You have actually never showed any code comparison by yourself on this forum. At least not in last two years. It was always someone else you was doing it. And you as usual just rely on your authority for ppl to believe you. Sorry, not this time.[/quote]
First things first. Still waiting on your "verbatim copy from Knuth to Crafty." Am also still waiting on your "lots of PD code in Crafty." Lest you try to forget, intentionally:
[quote="Milos"]
(since there is obviously quite a bit of PD code in Crafty)[/quote]
So far, you have shown zero. Which is what you typically show, technically. Let's get this cleaned up, then we can move on to either rybka 1.6.1/crafty if you want, or crafty/ippolit/robolito...
Right now, you are batting zero. I don't think it will change...
