setjmp() - another one

[Tony]

The use of setjmp might be a small piece in the large "Rybka, is it or isn't it?" puzzle, but in and of itself I cannot see how the use of a standard library function is suspicious.

Your right. It's just using C keywords. I know a lot of programs that use C keywords.

If Fruit has +137 and Rybka has +137 that doesn't mean anything, I know a lot of programs that have +137

Is this so hard to understand ?

It's not about single statements. It's about a collection of statements. The bigger the collection, the more likely it is to be a copy.

Single statements don't mean a thing.
Single lines don't mean much.
Complete code blocks mean everything.

This can't be too difficult.

Anybody with any experience in programming knows this. But why are the people who don't have this knowledge making the most noise ?

Because Vas says so ? The defending person says something so that's true, but dozens of experienced people say it isn't but that doesn't mean anything. ( As judge by people whose only claims are : I don't know anything about this/ I don't understand this )

I really don't get this. Maybe some of those people want to by a piece of the moon from me ? I'm also offering some rare 37 euro notes.

Tony

[chrisw]

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

Clear to me from this that you want out. Also the thread title "end it all". Bob had his escape route / exit strategy "I was only answering questions" prepared from the start. I guess Zach will learn a useful lesson on CCC politics.

[tmokonen]

The use of setjmp might be a small piece in the large "Rybka, is it or isn't it?" puzzle, but in and of itself I cannot see how the use of a standard library function is suspicious.

Your right. It's just using C keywords. I know a lot of programs that use C keywords.

If Fruit has +137 and Rybka has +137 that doesn't mean anything, I know a lot of programs that have +137

Is this so hard to understand ?

Yes, I understand this point perfectly. That's why I wrote "The use of setjmp might be a small piece in the large "Rybka, is it or isn't it?" puzzle.". It is a bit unusual, and might be a clue, combined with other evidence. However, the use of setjmp, while uncommon, is not unheard of, as the list of programs I provided proved. That's why I also said the use of setjmp in and of itself is not suspicious.

I wanted to make these points because I got irritated at the vitriol being directed towards Uri, because he mentioned that he got the idea of using setjmp from TSCP. I related my own experience with the setjmp call, because to me it seemed very similar to what Uri did, and to show that one can use an idea from copyrighted source without having to feel that one has done something terribly wrong and evil. Certainly, I'd never seen setjmp in use before I looked at TSCP, and I'd never been taught about it in school, probably because it was too GOTO-ish.

Because Vas says so ? The defending person says something so that's true, but dozens of experienced people say it isn't but that doesn't mean anything. ( As judge by people whose only claims are : I don't know anything about this/ I don't understand this )

I really don't get this. Maybe some of those people want to by a piece of the moon from me ? I'm also offering some rare 37 euro notes.

Tony

Spare me the ad hom.

[bob]

The use of setjmp might be a small piece in the large "Rybka, is it or isn't it?" puzzle, but in and of itself I cannot see how the use of a standard library function is suspicious.

Your right. It's just using C keywords. I know a lot of programs that use C keywords.

If Fruit has +137 and Rybka has +137 that doesn't mean anything, I know a lot of programs that have +137

Is this so hard to understand ?

Yes, I understand this point perfectly. That's why I wrote "The use of setjmp might be a small piece in the large "Rybka, is it or isn't it?" puzzle.". It is a bit unusual, and might be a clue, combined with other evidence. However, the use of setjmp, while uncommon, is not unheard of, as the list of programs I provided proved. That's why I also said the use of setjmp in and of itself is not suspicious.

Perhaps you could explain why that even needs stating. I was the first to point out that setjmp()/longjmp() are considered bad programming practices, and that their occurrence in the source in question simple further reduces the probability that the two blocks of code were independently written.

Nobody has said "Aha, he uses setjmp()/longjmp() so it is obviously a copy." But as soon as I wrote my explanation, paraphrased above, that is exactly what I got in response. "setjmp()" does not prove it was copied. The problem is, I didn't say it proved anything, just that it was yet another small bit of data that strengthens my previous argument that duplicate blocks of code are _extremely_ rare in large programming systems. And if they contain the same odd and disliked (by most programmers) approach, it becomes rarer still.

Much of the discussion is more of an attempt to bury the actual information in a sea of noise so that it becomes lost. And in many cases it has worked. But it appears that the comparative process will continue in spite of a world of noise around a small nucleus of facts.

I wanted to make these points because I got irritated at the vitriol being directed towards Uri, because he mentioned that he got the idea of using setjmp from TSCP. I related my own experience with the setjmp call, because to me it seemed very similar to what Uri did, and to show that one can use an idea from copyrighted source without having to feel that one has done something terribly wrong and evil. Certainly, I'd never seen setjmp in use before I looked at TSCP, and I'd never been taught about it in school, probably because it was too GOTO-ish.

Or possibly because it is an even worse idea than using GOTO's. Much worse in fact. Looking at the source you have a _hard_ time figuring out where it is going and what it is going to change. That is why its use has become so limited in software engineering projects.

Because Vas says so ? The defending person says something so that's true, but dozens of experienced people say it isn't but that doesn't mean anything. ( As judge by people whose only claims are : I don't know anything about this/ I don't understand this )

I really don't get this. Maybe some of those people want to by a piece of the moon from me ? I'm also offering some rare 37 euro notes.

Tony

Spare me the ad hom.

[Zach Wegner]

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:
[snip]

That is one way of doing it. Another way would be to copy the string passed into the engine for the UCI "position" command, and re-parse it when you return from the longjmp().

[bob]

What he is saying is this:

To "look up what it does" I generally use a "man setjmp" command in unix. Or, should my laptop or a unix box not be handy, I would look in the index for any of the dozens of C books I have, find a reference to "setjmp" and go read that. There it explains what it does, the potential dangers for using it, etc. Then I can stick it in my program if I want.

To look at another program and see "setjmp()" over here and "longjmp()" over there does not explain what they are doing. Just like looking up some other thing in an existing program and then using it in your program.

So if you look at TSCP and discover "OK, you put the setjmp() here, and then later, when you do the longjmp() somewhere it returns back to the line after the setjmp(), I can use that." That is not "looking it up to see how it _works_. that is looking in a program to see how to _use_ it. And that is fraught with danger since you didn't get to see all the warnings about things that can go wrong here and there with such oddball constructs.

[BubbaTough]

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!
_________________
Regards,
Mike

This quote from Sherwin is definitely my favorite of this thread . I don't know if it is true, but I hope it is because it makes this whole discussion even funnier. I guess I am just tickled with the idea that Fruit is a "clone" of TSCP which is a "clone" of Crafty, and since everyone keeps saying all modern programs except Crafty are "clones" of Fruit, we have now established that ALL PROGRAMS ARE CLONES OF CRAFTY.

(please don't hurt me...I just have an odd sense of humor and no impulse control).

[Michael Sherwin]

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!
_________________
Regards,
Mike

This quote from Sherwin is definitely my favorite of this thread . I don't know if it is true, but I hope it is because it makes this whole discussion even funnier. I guess I am just tickled with the idea that Fruit is a "clone" of TSCP which is a "clone" of Crafty, and since everyone keeps saying all modern programs except Crafty are "clones" of Fruit, we have now established that ALL PROGRAMS ARE CLONES OF CRAFTY.

(please don't hurt me...I just have an odd sense of humor and no impulse control).

I'm just glad that my humor was not wasted!

And there seems to be some truth to it.