setjmp() - another one

[bob]

I'm not going to list all the known issues, but in classical programming and software engineering, returning is the proper way to handle this. If you have a global board state as many do, who is going to restore that? Or are you going to the trouble of copying the board state from ply to ply which is a horrible performance hit?

In modern day programming, when you encouter an unexpected condition, you "throw" an exception. For a chess engine, running out of time or receiving a user input is just an unexpected condition. Whatever it is in the call stack is not useful anymore. Your last result is what you will give out.

And no, why would anyone copy board state from ply to ply? How about this:

Code: Select all

//C++
Iterate(TBoard &Board)
{
    TBoard SavedBoard = Board;
    try {
        for (int depth=1; depth<MaxDepth; depth++)
            SearchRoot (Board, depth, ...);
    }
    catch() {
    }
    Board = SavedBoard;
}
// C
Iterate(TBoard *pBoard)
{
    TBoard SavedBoard = *pBoard;
    if (setjmp(jumpbuffer)==0) {
        for (int depth=1; depth<MaxDepth; depth++)
            SearchRoot (pBoard, depth, ...);
    }
    *pBoard = SavedBoard;
}

You still see a lot of code out there where if there are 10 levels of calls, each one checks for the error condition. So, if the 10th level fails to allocate memory, each returning call will check that and eventually the root call notes the error.

That's just too archaic for me. Why should half of the code be just for error checking?

You do realize that there is a huge difference between code that is shorter, and code that is easier to understand and debug, of course?

Yes I do. And in that example of Crafty vs Thinker code, the longer Crafty code is actually harder to debug and harder to understad (all those checks that has nothing to do with the real logic gets in the way). What if you added a new call to Search(), and then you forgot to add the termintion check?

To me, checking for an abnormal condition after each call to search (and note that I could only do the check once with no serious side effect except for the loss of a few milliseconds since once the abort flag is set, nobody will search anything anyway) is a better design than dealing with the save/restore issues in setjmp(). That's why it is in such disfavor in C programming, it unwinds the stack and takes you back to where you were, but only if everything you did was on the stack. Global state is unaffected. So you end up back at the starting point, but you are not sure what data is good or bad. If the intent to use it to report an error condition and exit, that's one thing. But if the intent is to use it as a normal search termination approach, it leaves lots of room for very difficult-to-find bugs. And they are difficult because things are being changed behind-the-scenes that you can't see in the program and therefore you walk right into them blindly.

[chrisw]

Ahem. Excuse me. But Chief Technical Investigator Zach says:

where did anyone say that we are so sure that [we] have a watertight case against Vas

When did I say anything in that post about how strong my case was?

I haven't seen what I would consider proof.

I have seen plenty of _evidence_, but not _proof_. Have you seen _proof_ that nothing wrong has been done?

Well, I don't look for proof that something is ok, good, right, proper, I just assume it until proven otherwise. Sorry, but that's the way I am.

Then back to my house on fire example. How hot do the flames have to get before you begin to re-think your original conclusion and start looking around to see what really might be happening???

Personally, I hope that Vas has been completely honest. And that since he said he copied nothing, that somehow that is truthful. I see no real gain for anyone if Rybka is a copy, other than the truth will be known. I don't want to see _any_ copying going on. And if there is no more in the future, I'd consider that a real plus. But I suspect it will not happen, and we will see copy issues now and then. Contrary to what you might believe, I don't have the time, emotional energy, mental energy, or physical energy to spend a lot of time dwelling on what I might say to offend or discredit someone. Some here seem to delight in doing that. I do not. I am just interested in the circumstances that a few have brought up, which more or less directly affect me since I still compete in CC events.

Bob,

Rybka is going to be squeaky clean. The chances that someone with a world-beating product such as his has been released with problems in the copyright department are about zero - it would be too stupid.

If there were issues going back, they'll all have been taken out by support programmers and no trace left behind.

Are there Rybka 1 beta issues? Doubtful, Vas is a bright guy, as shown by his software, he won't be leaving hostages to fortune around the place.

Why, if a Fruit re-write, work all through the engine code, bitboard converslon, improvements, and leave a bunch of crap in the UCI knowing the mania for 'clone' hunting that exists in compchess? Makes no sense.

Everything is going to have an innocent explanation and the accusers are going to be left looking very bad indeed. You know this, hence the prepared exit strategy "I was only answering questions". Bob isn't stupid either.

N'est ce pas?

[bob]

Ahem. Excuse me. But Chief Technical Investigator Zach says:

where did anyone say that we are so sure that [we] have a watertight case against Vas

When did I say anything in that post about how strong my case was?

I haven't seen what I would consider proof.

I have seen plenty of _evidence_, but not _proof_. Have you seen _proof_ that nothing wrong has been done?

Well, I don't look for proof that something is ok, good, right, proper, I just assume it until proven otherwise. Sorry, but that's the way I am.

Then back to my house on fire example. How hot do the flames have to get before you begin to re-think your original conclusion and start looking around to see what really might be happening???

Personally, I hope that Vas has been completely honest. And that since he said he copied nothing, that somehow that is truthful. I see no real gain for anyone if Rybka is a copy, other than the truth will be known. I don't want to see _any_ copying going on. And if there is no more in the future, I'd consider that a real plus. But I suspect it will not happen, and we will see copy issues now and then. Contrary to what you might believe, I don't have the time, emotional energy, mental energy, or physical energy to spend a lot of time dwelling on what I might say to offend or discredit someone. Some here seem to delight in doing that. I do not. I am just interested in the circumstances that a few have brought up, which more or less directly affect me since I still compete in CC events.

Bob,

Rybka is going to be squeaky clean. The chances that someone with a world-beating product such as his has been released with problems in the copyright department are about zero - it would be too stupid.

If there were issues going back, they'll all have been taken out by support programmers and no trace left behind.

Are there Rybka 1 beta issues? Doubtful, Vas is a bright guy, as shown by his software, he won't be leaving hostages to fortune around the place.

Why, if a Fruit re-write, work all through the engine code, bitboard converslon, improvements, and leave a bunch of crap in the UCI knowing the mania for 'clone' hunting that exists in compchess? Makes no sense.

Everything is going to have an innocent explanation and the accusers are going to be left looking very bad indeed. You know this, hence the prepared exit strategy "I was only answering questions". Bob isn't stupid either.

N'est ce pas?

You say "stupid". It has happened _several_ times however. So it is not "rare" at all. Just google FSF lawsuits and read. Some are major players that were forced to comply...

[CThinker]

To me, checking for an abnormal condition after each call to search (and note that I could only do the check once with no serious side effect except for the loss of a few milliseconds since once the abort flag is set, nobody will search anything anyway) is a better design than dealing with the save/restore issues in setjmp(). That's why it is in such disfavor in C programming, it unwinds the stack and takes you back to where you were, but only if everything you did was on the stack. Global state is unaffected. So you end up back at the starting point, but you are not sure what data is good or bad. If the intent to use it to report an error condition and exit, that's one thing. But if the intent is to use it as a normal search termination approach, it leaves lots of room for very difficult-to-find bugs. And they are difficult because things are being changed behind-the-scenes that you can't see in the program and therefore you walk right into them blindly.

I still don't see the "issues" and "difficult to find bugs" that you are referring to. The board state is one "object". During the search, the object's reference gets passed around and the object gets modified. But once done, it is restored back in one line of code.

The try/catch model is bad in old days because there was no concept of objects (and encapsulation). There are bits and pieces of information scattered in global variables.

Here is an even simpler implementation which does away with "restore". Basically, you pass around the copy of the board, so, the current board is not touched at all.

Code: Select all

//C++ 
Iterate(TBoard &Board) 
{ 
    TBoard BoardForSeach = Board; 
    try { 
        for (int depth=1; depth<MaxDepth; depth++) 
            SearchRoot (BoardForSeach, depth, ...); 
    } 
    catch() { 
    } 
} 
// C 
Iterate(TBoard *pBoard) 
{ 
    TBoard BoardForSearch = *pBoard; 
    if (setjmp(jumpbuffer)==0) { 
        for (int depth=1; depth<MaxDepth; depth++) 
            SearchRoot (&BoardForSearch, depth, ...); 
    } 
}

I think the try/catch model is bad for the kind of code that Crafty is, with all its global variables. But for the majority of the OO coding today (C++,Java,C#), it is the default mode.

Interestingly, how this model is used in chess engines vary, and so I don't think there is copying of code here:

1. TSCP - after the longjump/catch, it does a "move undo" for all the moves that has been made, since it knows what they are and how many.

2. Fruit - has several copies of the board. The one used for searching is initialized from the game board just before the root search.

3. Strelka - the board is saved just before Iterate() and then restored after longjump/catch.

[swami]

Ahem, Bob, I have some deja-vus when reading your posts. Are you trapped in a time loop?

Sort of. Somehow the post operation is taking forever at times, and I can only suspect that after some time-out interval, firefox re-submits. I have seen two and even three duplicates, and today has been particularly atrocious in terms of delays. I received a couple of PM's here and responding to them went instantly, but posting an article is taking 1-2 minutes, and is producing duplicates here and there, sometimes mysteriously, sometimes when I hit submit a second time after nothing has happened for a minute or two.

Hi Bob,

Can you take this up with member named Sam Hull (TCAdmin)? He'd be happy to respond.

[bob]

To me, checking for an abnormal condition after each call to search (and note that I could only do the check once with no serious side effect except for the loss of a few milliseconds since once the abort flag is set, nobody will search anything anyway) is a better design than dealing with the save/restore issues in setjmp(). That's why it is in such disfavor in C programming, it unwinds the stack and takes you back to where you were, but only if everything you did was on the stack. Global state is unaffected. So you end up back at the starting point, but you are not sure what data is good or bad. If the intent to use it to report an error condition and exit, that's one thing. But if the intent is to use it as a normal search termination approach, it leaves lots of room for very difficult-to-find bugs. And they are difficult because things are being changed behind-the-scenes that you can't see in the program and therefore you walk right into them blindly.

I still don't see the "issues" and "difficult to find bugs" that you are referring to. The board state is one "object". During the search, the object's reference gets passed around and the object gets modified. But once done, it is restored back in one line of code.

The try/catch model is bad in old days because there was no concept of objects (and encapsulation). There are bits and pieces of information scattered in global variables.

Here is an even simpler implementation which does away with "restore". Basically, you pass around the copy of the board, so, the current board is not touched at all.

Code: Select all

//C++ 
Iterate(TBoard &Board) 
{ 
    TBoard BoardForSeach = Board; 
    try { 
        for (int depth=1; depth<MaxDepth; depth++) 
            SearchRoot (BoardForSeach, depth, ...); 
    } 
    catch() { 
    } 
} 
// C 
Iterate(TBoard *pBoard) 
{ 
    TBoard BoardForSearch = *pBoard; 
    if (setjmp(jumpbuffer)==0) { 
        for (int depth=1; depth<MaxDepth; depth++) 
            SearchRoot (&BoardForSearch, depth, ...); 
    } 
}

I think the try/catch model is bad for the kind of code that Crafty is, with all its global variables. But for the majority of the OO coding today (C++,Java,C#), it is the default mode.

Interestingly, how this model is used in chess engines vary, and so I don't think there is copying of code here:

1. TSCP - after the longjump/catch, it does a "move undo" for all the moves that has been made, since it knows what they are and how many.

2. Fruit - has several copies of the board. The one used for searching is initialized from the game board just before the root search.

3. Strelka - the board is saved just before Iterate() and then restored after longjump/catch.

Let's just say there is a significant amount of program "state" that is not a part of any stack, and longjmp() will not restore them to the way they were when the setjmp() was called. OO or no OO.

In any case, the _right_ way is to return. If you think longjmp() is better, you are in a small minority, but that's ok since it is your code.

[Michael Sherwin]

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.

You don't think it is rare? What, five total engines, one which has since been removed, out of how many hundreds??

Bob sums it up perfectly: "I never claimed it to be the ultimate proof. I simply said it was another suspicious detail because it is such a lousy way of writing a program."

Some people will always refuse to accept evidence when it is presented.

And some people don't like their evidence being challenged

It's spurious to say 5 out of 500 because no exhaustive search has been done on the 500. It's 5 only for the unscientific reason that two programmers happened to remember some past detail.

As to how many in total? Difficult. Some by random because they were old engines, SMP wasn't a problem and jumping out of the Search is a lazy but effective method, if politically incorrect. Some because they read TSCP. Some not because they read Crafty. What does Gnu do?

To pillory a programmer and his work it is necessary to produce evidence that stands beyond all reasonable doubt. This use of setjmp() is no longer in the beyond all reasonable doubt camp. Sorry about that, but that's the way it can go in adversarial investigation processes like this one.

Each point you bring will be challenged. Some will fall and some will stand, presumably. Do you want it any other way? Just blind acceptance because you're getting frustrated otherwise? If it were you, Zach, you'ld expect a vigorous defence and counter to each and every allegation and piece of evidence. Would you not?

setjmp() is not even a suspicious detail. It's history. Sorry.

It is suspicious to those of us that understand software development. Plagiarism involves copying good pieces of code most often, but when it is about copying a bad piece of code, it is just stronger evidence that copying was done.

Six users of setjmp() now, another "bad" programmer using "bad" techniques crawled out of the woodwork this afternoon.

Perhaps there are several ways to skin a cat, Bob? Your way isn't necessarily the "unique", "real programmer" and most "interesting" one?

Could it be so?

I missed #6. Movei was copied from TSCP so it does not count. It appears that Rybka/Strelka were copied from fruit. So that is two legitimate users. Which program did I miss? I did post earlier that gnu does not use setjmp. I also checked arasan, glaurung and a couple of others I have on my box. Nothing. I use fruit 2.1 on my cluster testing, it has it as we have heard and I verified it as well.

You mentioned a program you "thought" used it, but I have been counting concrete cases. And so far, there appear to be two legitimate users of setjmp()/longjmp(), fruit and TSCP.

When the total number reaches say 10, out of probably at least 500 chess engines, then that will be 1 in 50 which is still rare, but becoming "less" rare. But we are nowhere near that yet.

When Fruit 1.5 came out I looked at its source code. I did not notice the use of setjmp(), however, I remarked to myself that Fruit started life out as TSCP, but I forget why. The use of setjmp() in Fruit just reinforces my original (very subjective) observation.

However, IMO TSCP is derived from Faile, a dumbed down version for instructional purposes.

And Faile is a mailbox derivitive of an early Crafty!

[tiger]

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.

Leaving the setjmp() relevant or not argument aside for a moment, come on, you state that you believe that an engine used setjmp()? Isn't that a bit vague? You demand always hard facts and source and pretty aligned code from Zach and Christoph, so were are the facts of Ren Wu chess?
Would you believe Zach if he would write he believes that the eval of Rybka is identical to Fruit without further comment?
You always want to see facts, so please before you do a conclusion, gives us some facts.

When I look at the (far from complete) list of chess engines released in recent years at http://wbec-ridderkerk.nl/html/enginesindex.htm, I wonder how many of these engines use setjmp()? 10 of 200? More?
I think it is still a good indication, not a prove.

I do not know but movei used setjmp() at the beginning like tscp
and I simply learned from the code of tscp.

I got rid of setjmp later because I read people said it is not good
so it is not clear how many engines use setjmp.
old movei use it
new movei does not use it and you can download both old movei and new movei from wbec site.

Uri

So, you copied TSCP, which uses setjmp(). And then discovered it is a bad programming solution and removed it. Good. But notice where you got it from. That is the point of this minor side-issue. It is just another indication that perhaps something was copied, because good programmers do not use it for _many_ reasons. Perhaps Fruit started life as TSCP as well, who knows? But if programs that are suspected of being connected by common source, share a particular feature that is known to be bad programming, it is just another hint that things might have been copied...

I never claimed it to be the ultimate proof. I simply said it was another suspicious detail because it is such a lousy way of writing a program.

Ahem. Copied? I would prefer "used the idea". And if it's one line of code, there's not much else he can do, is there?

What if someone reads Crafty use of null move? The call is one line

value = -Search(ply-2); basically

how are we going to get a suitable value back from Search() without telling it to take 2 of the search depth?

Some things just are as they are.

Of course by dissecting the source code into individual lines you can use the argument "one line of code cannot possibly breach the GPL".

Considering that a 4000 lines program is composed of individual lines, and that no single line alone can breach any copyright license, then it follows that none of these lines can breach the GPL and so the program is clean.

We are talking of blocks of code that are identical or equivalent semantically. The probability of them happening in two programs writen independantly is so tiny that it makes them appear suspicious.

// Christophe

Your point is understood, but suffices only to take us round and round in circles.

You say "blocks of code that are identical or equivalent semantically".

We say "show us".

And Zach says "stop pressurising me, it takes time"

So we say "ok, we'll wait for the code"

And you say "blocks of code that are identical or equivalent semantically"

etc. etc. etc.

Shall we wait for your best shot at identical code chunks and take it from there?

Or at this point, you tell us you already have done?

We say where?

So you say, I'm not holding your hand, go look.

So we find one thing, but actually you were referring to something else.

This has the advantage, you can flame us for being stupid.

... to be continued, thread page 94

I would certainly not flame you for being stupid. You are not.

And there are enough other reasons to flame you anyway. For one, you are as stubborn as I am.



// Christophe

[Tony]

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.

Leaving the setjmp() relevant or not argument aside for a moment, come on, you state that you believe that an engine used setjmp()? Isn't that a bit vague? You demand always hard facts and source and pretty aligned code from Zach and Christoph, so were are the facts of Ren Wu chess?
Would you believe Zach if he would write he believes that the eval of Rybka is identical to Fruit without further comment?
You always want to see facts, so please before you do a conclusion, gives us some facts.

When I look at the (far from complete) list of chess engines released in recent years at http://wbec-ridderkerk.nl/html/enginesindex.htm, I wonder how many of these engines use setjmp()? 10 of 200? More?
I think it is still a good indication, not a prove.

I do not know but movei used setjmp() at the beginning like tscp
and I simply learned from the code of tscp.

I got rid of setjmp later because I read people said it is not good
so it is not clear how many engines use setjmp.
old movei use it
new movei does not use it and you can download both old movei and new movei from wbec site.

Uri

Let me get this clear.

You did not look up what setjmp() does. You saw it in TSCP, looked how it was used, and then used it the same way in Movei.

Now Uri, tell me.

Do you call that copying of ideas of copying code ?

Tony

This is not correct.
I looked at what setjmp() does

In your hypothetical situation it is copying code and not copying ideas but your hypotetical case did not happen.

Uri

Where did you lookup what it does ? in TSCP ? That's not looking up, that looking what it does.

That's exactly what I wrote.

YOU stated you didn't know what setJump does, and now you do ?

Tony

[Uri Blass]

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.

Leaving the setjmp() relevant or not argument aside for a moment, come on, you state that you believe that an engine used setjmp()? Isn't that a bit vague? You demand always hard facts and source and pretty aligned code from Zach and Christoph, so were are the facts of Ren Wu chess?
Would you believe Zach if he would write he believes that the eval of Rybka is identical to Fruit without further comment?
You always want to see facts, so please before you do a conclusion, gives us some facts.

When I look at the (far from complete) list of chess engines released in recent years at http://wbec-ridderkerk.nl/html/enginesindex.htm, I wonder how many of these engines use setjmp()? 10 of 200? More?
I think it is still a good indication, not a prove.

I do not know but movei used setjmp() at the beginning like tscp
and I simply learned from the code of tscp.

I got rid of setjmp later because I read people said it is not good
so it is not clear how many engines use setjmp.
old movei use it
new movei does not use it and you can download both old movei and new movei from wbec site.

Uri

Let me get this clear.

You did not look up what setjmp() does. You saw it in TSCP, looked how it was used, and then used it the same way in Movei.

Now Uri, tell me.

Do you call that copying of ideas of copying code ?

Tony

This is not correct.
I looked at what setjmp() does

In your hypothetical situation it is copying code and not copying ideas but your hypotetical case did not happen.

Uri

Where did you lookup what it does ? in TSCP ? That's not looking up, that looking what it does.

That's exactly what I wrote.

YOU stated you didn't know what setJump does, and now you do ?

Tony

Maybe there is a misunderstanding because my native language is not english.

I did not understand
"You did not look up what setjmp() does." and simply translated it to not understanding what setjmp does.

Uri