RegicideX wrote:1) The functions being compared are very similar in purpose and they are similar in purpose in most if not all chess programs.
OK, show us some similar code in, lets say, Crafty and Fruit. Or Glaurung and Slowchess. Or TSCP and Pepito.
I wait, ty.
Nobody will bite. This is supposedly a frequent occurrence, but only in the two programs being discussed (Fruit and Rybka).
As Alex's expression psychological "anchoring effect" of seeing and studying a piece of code -- the code structure sticks in one's head demonstrates is a perfectly frequent, natural and entirely legal occurence when the second programmer read, studied and absorbed the code of the first.
The only "anchoring effect" is that you now have "anchored" next to yet another bullshit explanation. you don't anchor to "specific algorithm design and code". That is so far beyond bullshit it is an insult to bullshit. High-level conceptual overviews? Of course. But not low-level implementations, until perhaps you have actually implemented one. Then you might tend to do it the same way next time, if you are a beginner. if you are sophisticated you are always looking for _better_ ways, not "familiar" ways.
Yup. The essential importance of optimisation to geekiest potential of the UCI code. How important it is. Takes so much computational time, so much memory. Not.
Let Vas spend his efforts bringing UCI code up to Bob standards. Such an important use of time. Not.
I can tell you one thing for sure. If that is your _real_ attitude, and you worked for me, you would be gone.
Perhaps you should apply at Microsoft. They seem to appreciate that kind of programming. I prefer to associate with the linux kernel guys and such, who write code more compatible with my standards...
Bob,
I didn't work for anyone for well over thirty years. More likely it would have a question of you working for me, if not for the fact, in my ever so humble opinion, that you're unemployable.
Best wishes and happy pension regards,
I have always heard that "bosses" don't like employees that are better than them. I suppose this proves that?
I have been "employable" for 38 years now, and have had exactly two jobs in that period of time. I left the first voluntarily to pursue a Ph.D. and the institution where I earned that degree asked me to remain on, where I have now been there for 23 years and counting. Your definition of "unemployable" must be just as good as your definition of "good code".
string.h should be included. I get no errors from ICC when compiling without it and did notice. The only risk is that the compiler assumes I am using strcmp() properly (which I am) so I might miss an important warning.
argc is the number of command line arguments +1.
argv[0] is a pointer to a string containing the name of the executable you are running.
argv[1] is a pointer to the first argument.
argv[2] same for second.
argc would be 4 since there are four total arguments, counting the name of the executable...
to run it, you just type "calc one + two" if you called the executable "calc".
BubbaTough wrote:I think "psychological anchoring" is a valid concept...if 10 people study a parser and then are asked to write one similarities are much more likely. I have no position on "how similar" things will end up naturally.
I also know I would not have a function called SEE if I had not been influenced by others...even if I had developed the exact same concept I would have definitely picked another name. Nor would I use terms like alpha or beta (in fact I don't, I use minScore and maxScore I think). I think my first chess program also had a1 = 0 and h8 = 63 instead of the other way around, but I switched in the next program I wrote because everyone else seemed to do it different and it got confusing. Lots of little things like that can be influential in legitimate ways. I think Chris has perhaps been tempted into an overly strong way of stating certain things, that make some folks (including me sometimes) want to argue against everything he says even when valid.
-Sam
Everyone else?
Strelka is using a1=0 and I also use a1=0
I remember that Crafty and old Danchess used a1=63 and it was one of the reasons that old DanChess was considered by Bob to be a derivative of Crafty.
Bob did not object DanChess only because of this reason(that of course is not enough) and I remember that I was also against DanChess and considered it unacceptable based on the evidence.
RegicideX wrote:1) The functions being compared are very similar in purpose and they are similar in purpose in most if not all chess programs.
OK, show us some similar code in, lets say, Crafty and Fruit. Or Glaurung and Slowchess. Or TSCP and Pepito.
I wait, ty.
Nobody will bite. This is supposedly a frequent occurrence, but only in the two programs being discussed (Fruit and Rybka).
As Alex's expression psychological "anchoring effect" of seeing and studying a piece of code -- the code structure sticks in one's head demonstrates is a perfectly frequent, natural and entirely legal occurence when the second programmer read, studied and absorbed the code of the first.
The only "anchoring effect" is that you now have "anchored" next to yet another bullshit explanation. you don't anchor to "specific algorithm design and code". That is so far beyond bullshit it is an insult to bullshit. High-level conceptual overviews? Of course. But not low-level implementations, until perhaps you have actually implemented one. Then you might tend to do it the same way next time, if you are a beginner. if you are sophisticated you are always looking for _better_ ways, not "familiar" ways.
Yup. The essential importance of optimisation to geekiest potential of the UCI code. How important it is. Takes so much computational time, so much memory. Not.
Let Vas spend his efforts bringing UCI code up to Bob standards. Such an important use of time. Not.
I can tell you one thing for sure. If that is your _real_ attitude, and you worked for me, you would be gone.
Perhaps you should apply at Microsoft. They seem to appreciate that kind of programming. I prefer to associate with the linux kernel guys and such, who write code more compatible with my standards...
Bob,
I didn't work for anyone for well over thirty years. More likely it would have a question of you working for me, if not for the fact, in my ever so humble opinion, that you're unemployable.
Best wishes and happy pension regards,
I have always heard that "bosses" don't like employees that are better than them. I suppose this proves that?
I have been "employable" for 38 years now, and have had exactly two jobs in that period of time. I left the first voluntarily to pursue a Ph.D. and the institution where I earned that degree asked me to remain on, where I have now been there for 23 years and counting. Your definition of "unemployable" must be just as good as your definition of "good code".
I just draw the line at staff who are stubborn as mules.
BubbaTough wrote:I think "psychological anchoring" is a valid concept...if 10 people study a parser and then are asked to write one similarities are much more likely. I have no position on "how similar" things will end up naturally.
I also know I would not have a function called SEE if I had not been influenced by others...even if I had developed the exact same concept I would have definitely picked another name. Nor would I use terms like alpha or beta (in fact I don't, I use minScore and maxScore I think). I think my first chess program also had a1 = 0 and h8 = 63 instead of the other way around, but I switched in the next program I wrote because everyone else seemed to do it different and it got confusing. Lots of little things like that can be influential in legitimate ways. I think Chris has perhaps been tempted into an overly strong way of stating certain things, that make some folks (including me sometimes) want to argue against everything he says even when valid.
-Sam
I currently use a1=0 in crafty. I switched _to_ that approach because of how Intel numbers bits, with 0 being the LSB and 63 being the MSB.
"psychological anchoring" refers to high-level things, not low-level memorizations. Most anyone writing a chess engine would be thinking "alpha/beta", move generation, making/unmaking moves, and such high-level concepts. but they would not have any "anchoring" with respect to low-level details such as which bit means what, what should go into this structure rather than that one, etc...
BubbaTough wrote:I think "psychological anchoring" is a valid concept...if 10 people study a parser and then are asked to write one similarities are much more likely. I have no position on "how similar" things will end up naturally.
I also know I would not have a function called SEE if I had not been influenced by others...even if I had developed the exact same concept I would have definitely picked another name. Nor would I use terms like alpha or beta (in fact I don't, I use minScore and maxScore I think). I think my first chess program also had a1 = 0 and h8 = 63 instead of the other way around, but I switched in the next program I wrote because everyone else seemed to do it different and it got confusing. Lots of little things like that can be influential in legitimate ways. I think Chris has perhaps been tempted into an overly strong way of stating certain things, that make some folks (including me sometimes) want to argue against everything he says even when valid.
-Sam
I currently use a1=0 in crafty. I switched _to_ that approach because of how Intel numbers bits, with 0 being the LSB and 63 being the MSB.
"psychological anchoring" refers to high-level things, not low-level memorizations. Most anyone writing a chess engine would be thinking "alpha/beta", move generation, making/unmaking moves, and such high-level concepts. but they would not have any "anchoring" with respect to low-level details such as which bit means what, what should go into this structure rather than that one, etc...
No it doesn't. It applies perfectly to writing a fucntion such as Go-parser. Take a look at someone else's code for the same thing and ....... similar code production by second programmer.
It's a great concept. It's fractal, applies at whatever level is being considered.
RegicideX wrote:1) The functions being compared are very similar in purpose and they are similar in purpose in most if not all chess programs.
OK, show us some similar code in, lets say, Crafty and Fruit. Or Glaurung and Slowchess. Or TSCP and Pepito.
I wait, ty.
Nobody will bite. This is supposedly a frequent occurrence, but only in the two programs being discussed (Fruit and Rybka).
As Alex's expression psychological "anchoring effect" of seeing and studying a piece of code -- the code structure sticks in one's head demonstrates is a perfectly frequent, natural and entirely legal occurence when the second programmer read, studied and absorbed the code of the first.
The only "anchoring effect" is that you now have "anchored" next to yet another bullshit explanation. you don't anchor to "specific algorithm design and code". That is so far beyond bullshit it is an insult to bullshit. High-level conceptual overviews? Of course. But not low-level implementations, until perhaps you have actually implemented one. Then you might tend to do it the same way next time, if you are a beginner. if you are sophisticated you are always looking for _better_ ways, not "familiar" ways.
Yup. The essential importance of optimisation to geekiest potential of the UCI code. How important it is. Takes so much computational time, so much memory. Not.
Let Vas spend his efforts bringing UCI code up to Bob standards. Such an important use of time. Not.
I can tell you one thing for sure. If that is your _real_ attitude, and you worked for me, you would be gone.
Perhaps you should apply at Microsoft. They seem to appreciate that kind of programming. I prefer to associate with the linux kernel guys and such, who write code more compatible with my standards...
Bob,
I didn't work for anyone for well over thirty years. More likely it would have a question of you working for me, if not for the fact, in my ever so humble opinion, that you're unemployable.
Best wishes and happy pension regards,
I have always heard that "bosses" don't like employees that are better than them. I suppose this proves that?
I have been "employable" for 38 years now, and have had exactly two jobs in that period of time. I left the first voluntarily to pursue a Ph.D. and the institution where I earned that degree asked me to remain on, where I have now been there for 23 years and counting. Your definition of "unemployable" must be just as good as your definition of "good code".
I just draw the line at staff who are stubborn as mules.
And I will bet you have missed _many_ a creative solution as a result. "do it my way, g**dammit, or don't do it at all..." I've had creative people working under me multiple times, and I always listened and we discussed things until we all were in agreement before progressing. Sometimes I was right, sometimes wrong, but we _always_ took the best path. I dropped my own idea of rotated bitboards because I saw where magic bitboards would offer more functionality in the future, although not immediately. But then us academic types tend to be creative _and_ adaptable, that is what we do...
BubbaTough wrote:I think "psychological anchoring" is a valid concept...if 10 people study a parser and then are asked to write one similarities are much more likely. I have no position on "how similar" things will end up naturally.
I also know I would not have a function called SEE if I had not been influenced by others...even if I had developed the exact same concept I would have definitely picked another name. Nor would I use terms like alpha or beta (in fact I don't, I use minScore and maxScore I think). I think my first chess program also had a1 = 0 and h8 = 63 instead of the other way around, but I switched in the next program I wrote because everyone else seemed to do it different and it got confusing. Lots of little things like that can be influential in legitimate ways. I think Chris has perhaps been tempted into an overly strong way of stating certain things, that make some folks (including me sometimes) want to argue against everything he says even when valid.
-Sam
I currently use a1=0 in crafty. I switched _to_ that approach because of how Intel numbers bits, with 0 being the LSB and 63 being the MSB.
"psychological anchoring" refers to high-level things, not low-level memorizations. Most anyone writing a chess engine would be thinking "alpha/beta", move generation, making/unmaking moves, and such high-level concepts. but they would not have any "anchoring" with respect to low-level details such as which bit means what, what should go into this structure rather than that one, etc...
No it doesn't. It applies perfectly to writing a fucntion such as Go-parser. Take a look at someone else's code for the same thing and ....... similar code production by second programmer.
It's a great concept. It's fractal, applies at whatever level is being considered.
OK, before we continue, go read about "psychological anchoring". which is _not_ what one does by glancing at A while writing B. We need to at least use a common vocabulary here, communication is already quite difficult.
chrisw wrote:No it doesn't. It applies perfectly to writing a fucntion such as Go-parser. Take a look at someone else's code for the same thing and ....... similar code production by second programmer.
It's a great concept. It's fractal, applies at whatever level is being considered.
RegicideX wrote:1) The functions being compared are very similar in purpose and they are similar in purpose in most if not all chess programs.
OK, show us some similar code in, lets say, Crafty and Fruit. Or Glaurung and Slowchess. Or TSCP and Pepito.
I wait, ty.
Nobody will bite. This is supposedly a frequent occurrence, but only in the two programs being discussed (Fruit and Rybka).
As Alex's expression psychological "anchoring effect" of seeing and studying a piece of code -- the code structure sticks in one's head demonstrates is a perfectly frequent, natural and entirely legal occurence when the second programmer read, studied and absorbed the code of the first.
The only "anchoring effect" is that you now have "anchored" next to yet another bullshit explanation. you don't anchor to "specific algorithm design and code". That is so far beyond bullshit it is an insult to bullshit. High-level conceptual overviews? Of course. But not low-level implementations, until perhaps you have actually implemented one. Then you might tend to do it the same way next time, if you are a beginner. if you are sophisticated you are always looking for _better_ ways, not "familiar" ways.
Yup. The essential importance of optimisation to geekiest potential of the UCI code. How important it is. Takes so much computational time, so much memory. Not.
Let Vas spend his efforts bringing UCI code up to Bob standards. Such an important use of time. Not.
I can tell you one thing for sure. If that is your _real_ attitude, and you worked for me, you would be gone.
Perhaps you should apply at Microsoft. They seem to appreciate that kind of programming. I prefer to associate with the linux kernel guys and such, who write code more compatible with my standards...
Bob,
I didn't work for anyone for well over thirty years. More likely it would have a question of you working for me, if not for the fact, in my ever so humble opinion, that you're unemployable.
Best wishes and happy pension regards,
I have always heard that "bosses" don't like employees that are better than them. I suppose this proves that?
I have been "employable" for 38 years now, and have had exactly two jobs in that period of time. I left the first voluntarily to pursue a Ph.D. and the institution where I earned that degree asked me to remain on, where I have now been there for 23 years and counting. Your definition of "unemployable" must be just as good as your definition of "good code".
I just draw the line at staff who are stubborn as mules.
And I will bet you have missed _many_ a creative solution as a result. "do it my way, g**dammit, or don't do it at all..." I've had creative people working under me multiple times, and I always listened and we discussed things until we all were in agreement before progressing. Sometimes I was right, sometimes wrong, but we _always_ took the best path. I dropped my own idea of rotated bitboards because I saw where magic bitboards would offer more functionality in the future, although not immediately. But then us academic types tend to be creative _and_ adaptable, that is what we do...
Well, I have a different approach. I write code that makes products that people want to buy and I'm also good at motivating others to do the same. Geeko-factors such as rotated this, magic that are fine and there's a need for some geeky programmers in any organisation to do this sort of stuff, but for me, I'll gladly give up on a 'creative solution' to make my code look Hyattian-correct in exchange for getting stuff that works out fast before anyone else. But then I'm commercial and you're academic. Commercials have no tenure and they have to work to the rules of capitalism not socialised education systems.
