A Common Sense Proposal to all Vas & Rybka Doubters

[bob]

Well said, Uri. And a magic word: "bitboards".

Paulo Soares

Perhaps "well said" but also "completely irrelevant. We all count using digits 0-9. We write using characters a-z and A-Z. We are not talking about copying an array that converts a square number (0-63) into an algebraic coordinate (a1-h8). We are talking about blocks of code (instructions, executable, etc) that are duplicates. All this other stuff is just nonsense.

Yes, you're talking about it and talking about it and talking about it.

Since you're talking about it so much, you must obviously have many examples of these duplicated blocks of instructional and executable code.

Where are they?

I simply read what Zach and Christophe posted. The examples seemed quite clear to me. If you take 200 lines of code and the only difference is a couple of lines that have been moved around, then those two blocks of code have a common ancestry.

it really is that simple.

Ok, please point us to these two x 200 line posted common code segments. Where can we find them? Do you have a link?

Once I get out of class, I will see if I can find them. One of the threads was moved/edited/something. the other discusses ideas about a big block of code where setjmp() is used, etc. Just using "setjmp()" is interesting since it is _not_ thread safe, and I have never used it in a chess program because it is an ugly hack.

After class I will look thru all the sources I have on my cluster to see if any of those use setjmp/longjmp anywhere, which I doubt. As I suspected, one of the programs I have uses setjmp(). Care to guess which one? Fruit. Even that is a strange coincidence, eh?

If anybody finds another program using this, please post so that we might accurately count the frequency of this very rare kludge. That will also be interesting in light of the current discussion.

[chrisw]

Well said, Uri. And a magic word: "bitboards".

Paulo Soares

Perhaps "well said" but also "completely irrelevant. We all count using digits 0-9. We write using characters a-z and A-Z. We are not talking about copying an array that converts a square number (0-63) into an algebraic coordinate (a1-h8). We are talking about blocks of code (instructions, executable, etc) that are duplicates. All this other stuff is just nonsense.

Yes, you're talking about it and talking about it and talking about it.

Since you're talking about it so much, you must obviously have many examples of these duplicated blocks of instructional and executable code.

Where are they?

Chris, the reason why the allegations from Bob are fishy, are these: a scientist like him cant Prove by million code bits that something, his conclusions, is correct. Science means, you can disprove certain false conclusions in principle with a single bit, but you cant prove that something is true. From that angle already it's all nonsense here. What Bob and his helpers needed is that they had something to deal with - from Vas side. But he cant react on these insults and evil allegations and false factual assumptions.

He's already thought of that one. Hence the talk "proof beyond reasonable doubt" and other legal language.

Bob therefore wants weight of evidence. Trouble is he hasn't come up with one factual evidential thing, yet. Apparently CT and Zach have got it, shown it to Bob, but not anyone else. Apparently it takes time to produce. However, this begs the question, why don't they reveal the blocks of duplicate code he says he's seen so far?

They have not shown me anything in private. Everything I have seen was shown _here_. yes much of it is buried in threads that are too long and contain 99% noise.

As far as I recollect the only thing shown here was a disassembly of part of Rybka's search function. So how are you able to state you've seen duplicated code because the alleged Fruit duplicate has not been posted here?

Do you have the Fruit duplicate code from some other source somewhere? Please post it if so, then everybody can all see and compare.

[bob]

Well said, Uri. And a magic word: "bitboards".

Paulo Soares

Perhaps "well said" but also "completely irrelevant. We all count using digits 0-9. We write using characters a-z and A-Z. We are not talking about copying an array that converts a square number (0-63) into an algebraic coordinate (a1-h8). We are talking about blocks of code (instructions, executable, etc) that are duplicates. All this other stuff is just nonsense.

Yes, you're talking about it and talking about it and talking about it.

Since you're talking about it so much, you must obviously have many examples of these duplicated blocks of instructional and executable code.

Where are they?

Chris, the reason why the allegations from Bob are fishy, are these: a scientist like him cant Prove by million code bits that something, his conclusions, is correct. Science means, you can disprove certain false conclusions in principle with a single bit, but you cant prove that something is true. From that angle already it's all nonsense here. What Bob and his helpers needed is that they had something to deal with - from Vas side. But he cant react on these insults and evil allegations and false factual assumptions.

He's already thought of that one. Hence the talk "proof beyond reasonable doubt" and other legal language.

Bob therefore wants weight of evidence. Trouble is he hasn't come up with one factual evidential thing, yet. Apparently CT and Zach have got it, shown it to Bob, but not anyone else. Apparently it takes time to produce. However, this begs the question, why don't they reveal the blocks of duplicate code he says he's seen so far?

They have not shown me anything in private. Everything I have seen was shown _here_. yes much of it is buried in threads that are too long and contain 99% noise.

As far as I recollect the only thing shown here was a disassembly of part of Rybka's search function. So how are you able to state you've seen duplicated code because the alleged Fruit duplicate has not been posted here?

Do you have the Fruit duplicate code from some other source somewhere? Please post it if so, then everybody can all see and compare.

Did you not see where Zach went thru those line by line saying both are identical to here, then Rybka does something odd in one line, then they synch up again for many lines? And as I mentioned, after looking around, setjmp() is a rarity in chess programs. So rare I only found it in one of the dozen+ I have here. And Zach found it in Rybka. Coincidence? certainly possible. But since it is an unsafe and rarely used function it is "interesting".

[Uri Blass]

Bob

He's not really a primary player in this at this point. It should be left to Zach and the others who are gathering evidence to present it.

After the stuff i read that he said today, i was shocked. I want to see what he says after a one on one with Vas- sort of a Rybka- Crafty matchup, so to speak.

What have I said that is shocking? That you will not "accidentally" produce a couple of hundred lines of identical code here, a couple of hundred lines there? That is all I have stated from the beginning. _IF_ there is duplicate code to any significant extent (not single lines, but blocks of code) then there is no way it is an "accident". If that is shocking, not much I can say. Anybody that deals with large numbers of programming assignments on a regular basis will say the same.

This is no accident but also proves nothing.
No accident because programmers do not start from scratch but start from known ideas that they read.

If the task is to write chess programs when people start from no idea that they read then you can expect more difference but if people learn about bitboards and learn tricks to write faster firstone function then you cannot
blame them for not being original and writing a slower code.

My FirstOne() function has been copied by many. It is simply a way of accessing the single instruction BSF. I have repeatedly said that I am not talking about a single line of code. But _blocks_ of identical lines. That is a difference. The examples shown have been 200 lines and up. that will _not_ happen "innocently".


firstone is only one example so it does not seem obvious to me that few hundrends of lines of equivalent code is a proof for using copy and paste
without looking at the code(I need to look at the lines to decide).

Here is an example about different bitboard programs that is not the case of fruit and rybka because fruit is not a bitboard program.

Based on looking at the code of strelka
one bitboard dictate many bitboards so if one bitboard is the same many bitboards are going to be the same.
If you use A1=0,B1=1,...H1=7,A2=8,...H8=63 you can expect arrays of bitboard of the squares that the king control to be the same and you have 64 numbers(squares that the king control at A1 squares that the king control at B1,....)

In writing a book, you use the letters a-z also. We are not talking about copying individual characters. Or individual numbering schemes, of which there are a finite (and small) number of alternatives (four for numbering squares using bitboards for example. So let's get back to the topic at hand. Duplicate blocks of code in the engine. we are not talking about silly examples like an array of numbers that equate specific chess squares to specific bits. We are talking about parts of an engine, such as the search, the evaluation, communication with the outside world, etc. Simple functions that convert a square number to a two-character algebraic coordinate and such is not what is being discussed.

Same is for squares that the knight control and squares that the pawns control and for bitboards that tell you information about blocking squares and continue in this way.
All these constants can be easily hundreds of lines of code so you get hundrends of lines that are basically the same.

Nobody is discussing such arrays of constants, this has been dismissed in discussions about things like endgame tables where everybody is using the same exact everything. Arrays used in evaluation are a different thing because those are creative, rather than just enumerations.

You can have different functions to generate them but
the programmer may simply use constant array and in this case the constant array is the same.

Uri

And nobody cares about that kind of similarity. Everyone uses 1, 2, 3, etc as well. We are looking one level higher than that.

My point is that we do not know what are the common parts between rybka and fruit and it may be possible that there are some common parts of strelka and fruit that are not in rybka.

The example of bitboards was only to show that number of similiar lines prove nothing.

I also think that you can expect bigger similiarity between good programmers because when there are less ways to write a strong chess program relative to number of ways to write a weak chess program
espacially when programmers start from some known ideas and do not start from nothing.

Uri

I'd like to see the discussion remain "on track". The question being discussed is "is Rybka derived from Fruit?" If there is any part of the code from Fruit in Rybka, the answer is "yes". Vas added strelka to the mix by his claim that strelka was identical to the first version of Rybka.

As far as the "less ways" that is simply wrong. There are an _infinite_ number of ways to write a strong chess program without having a single identical line of code between any two examples. Having large chunks of duplicate code is not going to happen unless the programs are related as is being discussed.

I wish we could stop this nonsense of "just a few ways". Lincoln's famous address is not very long. How many different ways could you write text to say the same thing? At least a million? And that pales to the amount of text in a chess engine's instructions. This concept is complete and utter nonsense. And anybody with _any_ significant programming experience realizes that.

It is obvious that Rybka is not identical to strelka because they do not generate exactly the same output but only similiar output.

Vas said:

"Strelka contains Rybka code. Whether Strelka also contains Fruit code, I don't know and don't really care."

see the following link for the quote of Vas words
http://rybkaforum.net/cgi-bin/rybkaforu ... 2#pid99683

It means that you need to prove identical code between fruit and rybka without strelka.

I think that it was not proved and I do not agree that every identical code prove that Vas is quilty and you cannot decide only based on the size
of the identical code and you need to look at the relevant lines.

I agree that you cannot expect 2 good programs to be the same but it is not illogical to expect more similiarities between good original programs relative to the case of bad original programs.

The idea (numbers may be different) is that
there may be 10^10000 ways to write bad chess program and 10^400 ways to write a good chess program.

My opinion is that progams that are the same or almost the same are not likely to appear but program that have few components that are the same or almost the same are more likely to appear with good programs.

Uri

[Uri Blass]

Well said, Uri. And a magic word: "bitboards".

Paulo Soares

Perhaps "well said" but also "completely irrelevant. We all count using digits 0-9. We write using characters a-z and A-Z. We are not talking about copying an array that converts a square number (0-63) into an algebraic coordinate (a1-h8). We are talking about blocks of code (instructions, executable, etc) that are duplicates. All this other stuff is just nonsense.

Yes, you're talking about it and talking about it and talking about it.

Since you're talking about it so much, you must obviously have many examples of these duplicated blocks of instructional and executable code.

Where are they?

I simply read what Zach and Christophe posted. The examples seemed quite clear to me. If you take 200 lines of code and the only difference is a couple of lines that have been moved around, then those two blocks of code have a common ancestry.

it really is that simple.

Ok, please point us to these two x 200 line posted common code segments. Where can we find them? Do you have a link?

Once I get out of class, I will see if I can find them. One of the threads was moved/edited/something. the other discusses ideas about a big block of code where setjmp() is used, etc. Just using "setjmp()" is interesting since it is _not_ thread safe, and I have never used it in a chess program because it is an ugly hack.

After class I will look thru all the sources I have on my cluster to see if any of those use setjmp/longjmp anywhere, which I doubt. As I suspected, one of the programs I have uses setjmp(). Care to guess which one? Fruit. Even that is a strange coincidence, eh?

If anybody finds another program using this, please post so that we might accurately count the frequency of this very rare kludge. That will also be interesting in light of the current discussion.

tscp search is using setjmp

here is tscp search's code:

Code: Select all

/*
 *	SEARCH.C
 *	Tom Kerrigan's Simple Chess Program (TSCP)
 *
 *	Copyright 1997 Tom Kerrigan
 */


#include <stdio.h>
#include <string.h>
#include "defs.h"
#include "data.h"
#include "protos.h"


/* see the beginning of think() */
#include <setjmp.h>
jmp_buf env;
BOOL stop_search;


/* think() calls search() iteratively. Search statistics
   are printed depending on the value of output:
   0 = no output
   1 = normal output
   2 = xboard format output */

void think(int output)
{
	int i, j, x;

	/* try the opening book first */
	pv[0][0].u = book_move();
	if (pv[0][0].u != -1)
		return;

	/* some code that lets us longjmp back here and return
	   from think() when our time is up */
	stop_search = FALSE;
	setjmp(env);
	if (stop_search) {
		
		/* make sure to take back the line we were searching */
		while (ply)
			takeback();
		return;
	}

	start_time = get_ms();
	stop_time = start_time + max_time;

	ply = 0;
	nodes = 0;

	memset(pv, 0, sizeof(pv));
	memset(history, 0, sizeof(history));
	if (output == 1)
		printf("ply      nodes  score  pv\n");
	for (i = 1; i <= max_depth; ++i) {
		follow_pv = TRUE;
		x = search(-10000, 10000, i);
		if (output == 1)
			printf("%3d  %9d  %5d ", i, nodes, x);
		else if (output == 2)
			printf("%d %d %d %d",
					i, x, (get_ms() - start_time) / 10, nodes);
		if (output) {
			for (j = 0; j < pv_length[0]; ++j)
				printf(" %s", move_str(pv[0][j].b));
			printf("\n");
			fflush(stdout);
		}
		if (x > 9000 || x < -9000)
			break;
	}
}


/* search() does just that, in negamax fashion */

int search(int alpha, int beta, int depth)
{
	int i, j, x;
	BOOL c, f;

	/* we're as deep as we want to be; call quiesce() to get
	   a reasonable score and return it. */
	if (!depth)
		return quiesce(alpha,beta);
	++nodes;

	/* do some housekeeping every 1024 nodes */
	if ((nodes & 1023) == 0)
		checkup();

	pv_length[ply] = ply;

	/* if this isn't the root of the search tree (where we have
	   to pick a move and can't simply return 0) then check to
	   see if the position is a repeat. if so, we can assume that
	   this line is a draw and return 0. */
	if (ply && reps())
		return 0;

	/* are we too deep? */
	if (ply >= MAX_PLY - 1)
		return eval();
	if (hply >= HIST_STACK - 1)
		return eval();

	/* are we in check? if so, we want to search deeper */
	c = in_check(side);
	if (c)
		++depth;
	gen();
	/*
	 if(depth > 3) { 
     for (i = first_move[ply]; i < first_move[ply + 1]; ++i) { 
        sort(i); 
        if (!makemove(gen_dat[i].m.b)) 
           continue; 
		gen_dat[i].score = -search(-beta - 100, -alpha + 100, depth/4 - 1); 
    //    gen_dat[i].score = -search(-beta - 100, -alpha + 100, depth/2-2); 

//		gen_dat[i].score = -search(-beta - 100, -alpha + 100, 0); 
        takeback(); 
    } 
  } 
  */

	if (follow_pv)  /* are we following the PV? */
		sort_pv();
	f = FALSE;

	/* loop through the moves */
	for (i = first_move[ply]; i < first_move[ply + 1]; ++i) {
		sort(i);
		if (!makemove(gen_dat[i].m.b))
			continue;
		f = TRUE;
		x = -search(-beta, -alpha, depth - 1);
		takeback();
		if (x > alpha) {

			/* this move caused a cutoff, so increase the history
			   value so it gets ordered high next time we can
			   search it */
			history[(int)gen_dat[i].m.b.from][(int)gen_dat[i].m.b.to] += depth;
			if (x >= beta)
				return beta;
			alpha = x;

			/* update the PV */
			pv[ply][ply] = gen_dat[i].m;
			for (j = ply + 1; j < pv_length[ply + 1]; ++j)
				pv[ply][j] = pv[ply + 1][j];
			pv_length[ply] = pv_length[ply + 1];
		}
	}

	/* no legal moves? then we're in checkmate or stalemate */
	if (!f) {
		if (c)
			return -10000 + ply;
		else
			return 0;
	}

	/* fifty move draw rule */
	if (fifty >= 100)
		return 0;
	return alpha;
}


/* quiesce() is a recursive minimax search function with
   alpha-beta cutoffs. In other words, negamax. It basically
   only searches capture sequences and allows the evaluation
   function to cut the search off (and set alpha). The idea
   is to find a position where there isn't a lot going on
   so the static evaluation function will work. */

int quiesce(int alpha,int beta)
{
	int i, j, x;

	++nodes;

	/* do some housekeeping every 1024 nodes */
	if ((nodes & 1023) == 0)
		checkup();

	pv_length[ply] = ply;

	/* are we too deep? */
	if (ply >= MAX_PLY - 1)
		return eval();
	if (hply >= HIST_STACK - 1)
		return eval();

	/* check with the evaluation function */
	x = eval();
	if (x >= beta)
		return beta;
	if (x > alpha)
		alpha = x;

	gen_caps();
	if (follow_pv)  /* are we following the PV? */
		sort_pv();

	/* loop through the moves */
	for (i = first_move[ply]; i < first_move[ply + 1]; ++i) {
		sort(i);
		if (!makemove(gen_dat[i].m.b))
			continue;
		x = -quiesce(-beta, -alpha);
		takeback();
		if (x > alpha) {
			if (x >= beta)
				return beta;
			alpha = x;

			/* update the PV */
			pv[ply][ply] = gen_dat[i].m;
			for (j = ply + 1; j < pv_length[ply + 1]; ++j)
				pv[ply][j] = pv[ply + 1][j];
			pv_length[ply] = pv_length[ply + 1];
		}
	}
	return alpha;
}


/* reps() returns the number of times the current position
   has been repeated. It compares the current value of hash
   to previous values. */

int reps()
{
	int i;
	int r = 0;

	for (i = hply - fifty; i < hply; ++i)
		if (hist_dat[i].hash == hash)
			++r;
	return r;
}


/* sort_pv() is called when the search function is following
   the PV (Principal Variation). It looks through the current
   ply's move list to see if the PV move is there. If so,
   it adds 10,000,000 to the move's score so it's played first
   by the search function. If not, follow_pv remains FALSE and
   search() stops calling sort_pv(). */

void sort_pv()
{
	int i;

	follow_pv = FALSE;
	for(i = first_move[ply]; i < first_move[ply + 1]; ++i)
		if (gen_dat[i].m.u == pv[0][ply].u) {
			follow_pv = TRUE;
			gen_dat[i].score += 10000000;
			return;
		}
}


/* sort() searches the current ply's move list from 'from'
   to the end to find the move with the highest score. Then it
   swaps that move and the 'from' move so the move with the
   highest score gets searched next, and hopefully produces
   a cutoff. */

void sort(int from)
{
	int i;
	int bs;  /* best score */
	int bi;  /* best i */
	gen_t g;

	bs = -1;
	bi = from;
	for (i = from; i < first_move[ply + 1]; ++i)
		if (gen_dat[i].score > bs) {
			bs = gen_dat[i].score;
			bi = i;
		}
	g = gen_dat[from];
	gen_dat[from] = gen_dat[bi];
	gen_dat[bi] = g;
}


/* checkup() is called once in a while during the search. */

void checkup()
{
	/* is the engine's time up? if so, longjmp back to the
	   beginning of think() */
	if (get_ms() >= stop_time) {
		stop_search = TRUE;
		longjmp(env, 0);
	}
}

[chrisw]

Well said, Uri. And a magic word: "bitboards".

Paulo Soares

Perhaps "well said" but also "completely irrelevant. We all count using digits 0-9. We write using characters a-z and A-Z. We are not talking about copying an array that converts a square number (0-63) into an algebraic coordinate (a1-h8). We are talking about blocks of code (instructions, executable, etc) that are duplicates. All this other stuff is just nonsense.

Yes, you're talking about it and talking about it and talking about it.

Since you're talking about it so much, you must obviously have many examples of these duplicated blocks of instructional and executable code.

Where are they?

Chris, the reason why the allegations from Bob are fishy, are these: a scientist like him cant Prove by million code bits that something, his conclusions, is correct. Science means, you can disprove certain false conclusions in principle with a single bit, but you cant prove that something is true. From that angle already it's all nonsense here. What Bob and his helpers needed is that they had something to deal with - from Vas side. But he cant react on these insults and evil allegations and false factual assumptions.

He's already thought of that one. Hence the talk "proof beyond reasonable doubt" and other legal language.

Bob therefore wants weight of evidence. Trouble is he hasn't come up with one factual evidential thing, yet. Apparently CT and Zach have got it, shown it to Bob, but not anyone else. Apparently it takes time to produce. However, this begs the question, why don't they reveal the blocks of duplicate code he says he's seen so far?

They have not shown me anything in private. Everything I have seen was shown _here_. yes much of it is buried in threads that are too long and contain 99% noise.

As far as I recollect the only thing shown here was a disassembly of part of Rybka's search function. So how are you able to state you've seen duplicated code because the alleged Fruit duplicate has not been posted here?

Do you have the Fruit duplicate code from some other source somewhere? Please post it if so, then everybody can all see and compare.

Did you not see where Zach went thru those line by line saying both are identical to here, then Rybka does something odd in one line, then they synch up again for many lines? And as I mentioned, after looking around, setjmp() is a rarity in chess programs. So rare I only found it in one of the dozen+ I have here. And Zach found it in Rybka. Coincidence? certainly possible. But since it is an unsafe and rarely used function it is "interesting".

And no, I didn't see Zach going through anything line by line comparing. In fact he said something quite different:

Zach wrote:
That's fine. I haven't looked at the Fruit disassembly, only at the source. It might be worthwhile at some point to try to compile it with certain compilers and see if the instruction scheduling etc. match up with the binary, but I haven't done it yet.

It's hard to show a comparison, because the huge block of assembly I posted are equivalent to about 20 lines of Fruit code. I will try to make a side-by-side with a line of Fruit next to 10 or so lines of assembly, but it might look crappy. Just warning you.

"Identical here. Rybka does something different. Then sync up again." appears unposted as far as I can see. Quite the opposite: "I haven't looked at the Fruit disassembly", says Zach.


btw Uri has just posted he found setjmp() in TCSP, so it appears to be less rare than you make out. Which is "interesting".

[bob]

Well said, Uri. And a magic word: "bitboards".

Paulo Soares

Perhaps "well said" but also "completely irrelevant. We all count using digits 0-9. We write using characters a-z and A-Z. We are not talking about copying an array that converts a square number (0-63) into an algebraic coordinate (a1-h8). We are talking about blocks of code (instructions, executable, etc) that are duplicates. All this other stuff is just nonsense.

Yes, you're talking about it and talking about it and talking about it.

Since you're talking about it so much, you must obviously have many examples of these duplicated blocks of instructional and executable code.

Where are they?

Chris, the reason why the allegations from Bob are fishy, are these: a scientist like him cant Prove by million code bits that something, his conclusions, is correct. Science means, you can disprove certain false conclusions in principle with a single bit, but you cant prove that something is true. From that angle already it's all nonsense here. What Bob and his helpers needed is that they had something to deal with - from Vas side. But he cant react on these insults and evil allegations and false factual assumptions.

He's already thought of that one. Hence the talk "proof beyond reasonable doubt" and other legal language.

Bob therefore wants weight of evidence. Trouble is he hasn't come up with one factual evidential thing, yet. Apparently CT and Zach have got it, shown it to Bob, but not anyone else. Apparently it takes time to produce. However, this begs the question, why don't they reveal the blocks of duplicate code he says he's seen so far?

They have not shown me anything in private. Everything I have seen was shown _here_. yes much of it is buried in threads that are too long and contain 99% noise.

As far as I recollect the only thing shown here was a disassembly of part of Rybka's search function. So how are you able to state you've seen duplicated code because the alleged Fruit duplicate has not been posted here?

Do you have the Fruit duplicate code from some other source somewhere? Please post it if so, then everybody can all see and compare.

Did you not see where Zach went thru those line by line saying both are identical to here, then Rybka does something odd in one line, then they synch up again for many lines? And as I mentioned, after looking around, setjmp() is a rarity in chess programs. So rare I only found it in one of the dozen+ I have here. And Zach found it in Rybka. Coincidence? certainly possible. But since it is an unsafe and rarely used function it is "interesting".

And no, I didn't see Zach going through anything line by line comparing. In fact he said something quite different:

Zach wrote:
That's fine. I haven't looked at the Fruit disassembly, only at the source. It might be worthwhile at some point to try to compile it with certain compilers and see if the instruction scheduling etc. match up with the binary, but I haven't done it yet.

It's hard to show a comparison, because the huge block of assembly I posted are equivalent to about 20 lines of Fruit code. I will try to make a side-by-side with a line of Fruit next to 10 or so lines of assembly, but it might look crappy. Just warning you.

"Identical here. Rybka does something different. Then sync up again." appears unposted as far as I can see. Quite the opposite: "I haven't looked at the Fruit disassembly", says Zach.


btw Uri has just posted he found setjmp() in TCSP, so it appears to be less rare than you make out. Which is "interesting".

Just find the post where he mentions setjmp() among other things. I didn't imagine it and we have not shared information privately.

[bob]

OK. now we have three. Fruit and Rybka that are high-quality programs, and one "bare-bones this is how it is done" program. That is still less than 1%. setjmp() is a horrible approach to doing anything.

[geots]

Well said, Uri. And a magic word: "bitboards".

Paulo Soares

Perhaps "well said" but also "completely irrelevant. We all count using digits 0-9. We write using characters a-z and A-Z. We are not talking about copying an array that converts a square number (0-63) into an algebraic coordinate (a1-h8). We are talking about blocks of code (instructions, executable, etc) that are duplicates. All this other stuff is just nonsense.

Yes, you're talking about it and talking about it and talking about it.

Since you're talking about it so much, you must obviously have many examples of these duplicated blocks of instructional and executable code.

Where are they?

Chris, the reason why the allegations from Bob are fishy, are these: a scientist like him cant Prove by million code bits that something, his conclusions, is correct. Science means, you can disprove certain false conclusions in principle with a single bit, but you cant prove that something is true. From that angle already it's all nonsense here. What Bob and his helpers needed is that they had something to deal with - from Vas side. But he cant react on these insults and evil allegations and false factual assumptions.

He's already thought of that one. Hence the talk "proof beyond reasonable doubt" and other legal language.

Bob therefore wants weight of evidence. Trouble is he hasn't come up with one factual evidential thing, yet. Apparently CT and Zach have got it, shown it to Bob, but not anyone else. Apparently it takes time to produce. However, this begs the question, why don't they reveal the blocks of duplicate code he says he's seen so far?

They have not shown me anything in private. Everything I have seen was shown _here_. yes much of it is buried in threads that are too long and contain 99% noise.

As far as I recollect the only thing shown here was a disassembly of part of Rybka's search function. So how are you able to state you've seen duplicated code because the alleged Fruit duplicate has not been posted here?

Do you have the Fruit duplicate code from some other source somewhere? Please post it if so, then everybody can all see and compare.

Did you not see where Zach went thru those line by line saying both are identical to here, then Rybka does something odd in one line, then they synch up again for many lines? And as I mentioned, after looking around, setjmp() is a rarity in chess programs. So rare I only found it in one of the dozen+ I have here. And Zach found it in Rybka. Coincidence? certainly possible. But since it is an unsafe and rarely used function it is "interesting".

And no, I didn't see Zach going through anything line by line comparing. In fact he said something quite different:

Zach wrote:
That's fine. I haven't looked at the Fruit disassembly, only at the source. It might be worthwhile at some point to try to compile it with certain compilers and see if the instruction scheduling etc. match up with the binary, but I haven't done it yet.

It's hard to show a comparison, because the huge block of assembly I posted are equivalent to about 20 lines of Fruit code. I will try to make a side-by-side with a line of Fruit next to 10 or so lines of assembly, but it might look crappy. Just warning you.

"Identical here. Rybka does something different. Then sync up again." appears unposted as far as I can see. Quite the opposite: "I haven't looked at the Fruit disassembly", says Zach.


btw Uri has just posted he found setjmp() in TCSP, so it appears to be less rare than you make out. Which is "interesting".

Chris, apparently Bob isnt aware of the old adage- "When you find yourself in a hole- quit digging"

[chrisw]

Well said, Uri. And a magic word: "bitboards".

Paulo Soares

Perhaps "well said" but also "completely irrelevant. We all count using digits 0-9. We write using characters a-z and A-Z. We are not talking about copying an array that converts a square number (0-63) into an algebraic coordinate (a1-h8). We are talking about blocks of code (instructions, executable, etc) that are duplicates. All this other stuff is just nonsense.

Yes, you're talking about it and talking about it and talking about it.

Since you're talking about it so much, you must obviously have many examples of these duplicated blocks of instructional and executable code.

Where are they?

Chris, the reason why the allegations from Bob are fishy, are these: a scientist like him cant Prove by million code bits that something, his conclusions, is correct. Science means, you can disprove certain false conclusions in principle with a single bit, but you cant prove that something is true. From that angle already it's all nonsense here. What Bob and his helpers needed is that they had something to deal with - from Vas side. But he cant react on these insults and evil allegations and false factual assumptions.

He's already thought of that one. Hence the talk "proof beyond reasonable doubt" and other legal language.

Bob therefore wants weight of evidence. Trouble is he hasn't come up with one factual evidential thing, yet. Apparently CT and Zach have got it, shown it to Bob, but not anyone else. Apparently it takes time to produce. However, this begs the question, why don't they reveal the blocks of duplicate code he says he's seen so far?

They have not shown me anything in private. Everything I have seen was shown _here_. yes much of it is buried in threads that are too long and contain 99% noise.

As far as I recollect the only thing shown here was a disassembly of part of Rybka's search function. So how are you able to state you've seen duplicated code because the alleged Fruit duplicate has not been posted here?

Do you have the Fruit duplicate code from some other source somewhere? Please post it if so, then everybody can all see and compare.

Did you not see where Zach went thru those line by line saying both are identical to here, then Rybka does something odd in one line, then they synch up again for many lines? And as I mentioned, after looking around, setjmp() is a rarity in chess programs. So rare I only found it in one of the dozen+ I have here. And Zach found it in Rybka. Coincidence? certainly possible. But since it is an unsafe and rarely used function it is "interesting".

And no, I didn't see Zach going through anything line by line comparing. In fact he said something quite different:

Zach wrote:
That's fine. I haven't looked at the Fruit disassembly, only at the source. It might be worthwhile at some point to try to compile it with certain compilers and see if the instruction scheduling etc. match up with the binary, but I haven't done it yet.

It's hard to show a comparison, because the huge block of assembly I posted are equivalent to about 20 lines of Fruit code. I will try to make a side-by-side with a line of Fruit next to 10 or so lines of assembly, but it might look crappy. Just warning you.

"Identical here. Rybka does something different. Then sync up again." appears unposted as far as I can see. Quite the opposite: "I haven't looked at the Fruit disassembly", says Zach.


btw Uri has just posted he found setjmp() in TCSP, so it appears to be less rare than you make out. Which is "interesting".

Just find the post where he mentions setjmp() among other things. I didn't imagine it and we have not shared information privately.

setjmp() post was post #1, reproduced below.

Bob wrote:Did you not see where Zach went thru those line by line saying both are identical to here, then Rybka does something odd in one line, then they synch up again for many lines?

No, I don't see it. Where does he say what you suggest, going thru line by line ... identical to here ... Rybka different ... sync again ...?

Zach wrote:
The topic came up in another thread about the issue of comparing Strelka to Fruit vs. comparing Rybka 1.0 to Fruit. I am doing some disassembling of Rybka 1.0, so I will post the assembly that is equivalent to the last piece of code I had in Fruit. Just to let you know, this is by no means complete. I have filled in most of the function names and some of the variable names, but there is a lot left to do. This is just the result of a few day's work, more will come later.

< disassembly snipped >

The interesting thing that I found is that for this piece of code, Rybka 1.0 is more similar to Fruit than Strelka. Here are the differences:
--Setjmp is called after the move generation, as in Fruit
--Something very strange: whereas in Strelka a failed setjmp call simply results in a return, in Rybka 1.0 it involves a function call, like in Fruit (there it is search_update_current()). The weird part is, it appears to be calling parse_position(). That is what the "call sub_4092E0" is for. Why would Rybka 1.0 be parsing the position after a setjmp call?
--The timer is started after the setjmp call
--depth is limited to 4 when there's only 1 legal move (commented out in Strelka, as noted in the other thread).
--I noted earlier that the history initialization was different. Strelka and Rybka 1.0 are the same here, using memset(History, 256, 12 * 64 * sizeof(int)); But what I didn't notice is, 256 is out of range for an unsigned char. So that code is the same as Fruit's memset(History, 0, 12 * 64 * sizeof(int)); Why would Rybka 1.0 have 256? Is it the optimizer gone wild, or a deliberate attempt at obfuscation?