Wait just a minute. "Rare; adj. occurring infrequently. etc."chrisw wrote:Entirely agreed its no good solution, but that's not the point. You said it was rare/unique whatever. It isn't. And therefore it's another nail in the probably used the same code coffin. It isn't.bob wrote:Again, "I think..." "if I remember"... I said it is rare. It appears to be so. So the presence is both programs is still "interesting". The problem is that longjmp() does not restore the board to the starting position, nor anything else other than whatever is on the stack. That's why it is considered a bad solution to any known problem, because you can get back to the starting point with contradictory state information.chrisw wrote:Bob argued that the existence in the Rybka code of setjmp() was "interesting" because this also existed in Fruit and nowhere else.
Uri pointed out that Tom Kerrigan's public program TSCP also used setjmp() and that some other programs were likely/possibly developed, legally, off TSCP as basis.
I'm an engine programmer and always had user interface programmers working in support, so I got very lazy and understand very little about DOS, windows, C support functions and so on. setjmp() knowledge is no way a speciality of mine.
However, casting my mind back many years, I'm fairly sure that the Ren Wu Chess program which was also worked on by Ren at Oxford Softworks used setjmp() to unwind the search on a timeout. CSTal, by contrast, did a proper search unwind.
There are two ways to exit Search() on a timeout or user intervention. The 'correct' way, I suppose, is to unwind the Search back to the start using unmove simultaneously unstacking the variables.
The brutal and simple way is simply to jump straight out, reseting the stack pointer. I guess this is setjmp().
I'l be very surprised if numbers of programs, especially those designed years ago without SMP in mind, didn't use the brutal setjmp() technique to break the search.
Bottom line: setjmp() is not unique and its use doesn't imply anything, certainly it cannot imply copied code.
It is in fruit, it is in Rybka, it is in TSCP, and it is in Movei where it was _copied_ from TSCP. So we have four programs, out of hundreds. I believe 1 in 100 would be considered "rare" by anybody's definition. And when one of the four has admitted to copying the code from another of the four, and when one of the four is suspected of copying the code from another of the four, then it becomes 2 out of hundreds and is even rarer.
Rare is not an arbitrary word . Nobody would call 25 out of 100 rare. Probably not even 10 out of 100. But one out of 100 or less? that is rare. But what is _more_ telling is that someone would have the same _bad_ code.
