![[us]](/mwf/v12/flags/us.png "United States")
The "criterion" was to look at all evaluation features. Why do you think there are some terms with 100% match, some with less? If we were just "cherry-picking" wouldn't we just focus on the 100% matches only?
Think before you accuse, and you won't look so foolish.
Evaluating knights on a8/h8 as "trapped" is certainly an evaluation term. Whether it is implemented in a PST or as a direct comparison. The PST is more efficient, but you don't get to add any "qualifiers" to it (knight at a8, pawn at b7, making Nc6 an impossible escape plan).
Neither do that, by the way. I did at one point...
Think before you accuse, and you won't look so foolish.
Evaluating knights on a8/h8 as "trapped" is certainly an evaluation term. Whether it is implemented in a PST or as a direct comparison. The PST is more efficient, but you don't get to add any "qualifiers" to it (knight at a8, pawn at b7, making Nc6 an impossible escape plan).
Neither do that, by the way. I did at one point...
The "criterion" was to look at all evaluation features. Why do you think there are some terms with 100% match, some with less? If we were just "cherry-picking" wouldn't we just focus on the 100% matches only?
This is exactly what was done to come up with "almost identical" evaluation functions.
Evaluating knights on a8/h8 as "trapped" is certainly an evaluation term.
It is certainly an evaluation term that didn't originate with Fruit.
The PST is more efficient, but you don't get to add any "qualifiers" to it (knight at a8, pawn at b7, making Nc6 an impossible escape plan).
And what does this have to do with the price of eggs on the NYSE?
Neither do that, by the way. I did at one point...
Can't think of anything less relevant than this.
This is exactly what was done to come up with "almost identical" evaluation functions.
Evaluating knights on a8/h8 as "trapped" is certainly an evaluation term.
It is certainly an evaluation term that didn't originate with Fruit.
The PST is more efficient, but you don't get to add any "qualifiers" to it (knight at a8, pawn at b7, making Nc6 an impossible escape plan).
And what does this have to do with the price of eggs on the NYSE?
Neither do that, by the way. I did at one point...
Can't think of anything less relevant than this.
Nobody said ANY of these "ideas" originated with fruit. So I don't get your point. That particular implementation certainly was in fruit. And the more parts, implemented the same way, that two different programs "share" the more suspicious things become.
Of course YOU won't see any relevance in ANY of this, because you don't understand any of it. Why state the obvious, then?
Of course YOU won't see any relevance in ANY of this, because you don't understand any of it. Why state the obvious, then?
OK, it didn't originate in Fruit and wasn't implemented the same way in R1B. But both programs had different code for penalizing a knight in the corner, so Vas must be guilty. Your logic is only comprehensible to inbred hillbillies.
"Different code?"
Both have a knight on a8/h8 in their PSTs.
What are you talking about?
Both have a knight on a8/h8 in their PSTs.
What are you talking about?
Both have a knight on a8/h8 in their PSTs.
You think it's strange, or unusual, to penalize the knight in the corner? Or to do this with the PST? And this is a key piece of your evidence?
You think it's strange, or unusual, to penalize the knight in the corner? Or to do this with the PST? And this is a key piece of your evidence?
There is no "key piece". Just a LOT of small pieces. It is not so common to penalize a knight on a8/h8, no. It is more common to penalize a knight on the edge of the board anywhere. a8/h8 are a specific issue for a specific infrequent type of position where one gives up a piece, in return for forking king and rook and ending up a piece down, and a rook up, but with the knight on a8 and unable to escape.
Not many (if any at all, I certainly don't) do this any longer...
One might evaluate a knight trapped on a8, similar to what we do with a bishop trapped at a7, but not through a PST.
Not many (if any at all, I certainly don't) do this any longer...
One might evaluate a knight trapped on a8, similar to what we do with a bishop trapped at a7, but not through a PST.
You're supposed to establish your criteria before testing. Not after the fact. When you admit that an arrangement is very unusual, yet it appears as one of the features to be compared, you are admitting that it was picked after examining the features included in each engine. This is also known as cherry picking the data.
Isnt this exactly what mathematical proofs are all about? When I started my studies students met hours before deadline for the weekly tasks, those who had almost all ready and the many who had either no clue or not time enough to finish. I was one of the less genial because I couldnt figure how the results should look like in advance. No chance to find it by chance. So, that meant copying the given solutions, who were no nuclear science style at all but how to do it without the vision of about end solution? All my years in college I was trained to do it straight forward but not backwards! In chess the same. You try to find good moves, you dont pre-occupy yourself with imaginations about how to check-mate the other King on h7. That isnt practical chess competition but more the art of problems or studies.
At the instant when I read that R/E could never result into 1-to-1 pictures of one language into the other I knew that something had been done terribly wrong style because how did they prove the certainty that their assumption was the only valid one?? So, it comes rather late with the evidence that indeed they did it wrong, but late isnbt too late. When I started this little thread I had this fallacy of typically mathematical errors in mind. It's really dull to watch them crucifying someone with that hoax. Very sad situation.
Isnt this exactly what mathematical proofs are all about? When I started my studies students met hours before deadline for the weekly tasks, those who had almost all ready and the many who had either no clue or not time enough to finish. I was one of the less genial because I couldnt figure how the results should look like in advance. No chance to find it by chance. So, that meant copying the given solutions, who were no nuclear science style at all but how to do it without the vision of about end solution? All my years in college I was trained to do it straight forward but not backwards! In chess the same. You try to find good moves, you dont pre-occupy yourself with imaginations about how to check-mate the other King on h7. That isnt practical chess competition but more the art of problems or studies.
At the instant when I read that R/E could never result into 1-to-1 pictures of one language into the other I knew that something had been done terribly wrong style because how did they prove the certainty that their assumption was the only valid one?? So, it comes rather late with the evidence that indeed they did it wrong, but late isnbt too late. When I started this little thread I had this fallacy of typically mathematical errors in mind. It's really dull to watch them crucifying someone with that hoax. Very sad situation.
I don't know what to say. I was given proofs to work out all through college. I did not copy the solutions of others. If I ran into a problem I could not figure out, we had group meetings to discuss such things. But the meetings were to understand the problem, and how to attack it to reach a solution, not to have someone write the answers on the board. Something told me that would not be beneficial when exam time came along. I was right.
You continue to not understand the comparison we did. And you continue to use the WRONG concept in the first place.
RE is about taking a binary and turning it into a source program that one can read or modify. We did NOT do that. We took the Fruit source, and the Rybka asm (from the binary) and compared them looking for semantic equivalence. Has nothing to do with "reverse-engineering" as you are using the term. That's been a red herring from the get-go, because that was not done ANYWHERE in the investigation. There are no "mistakes to be made" when semantic equivalence techniques (which are well-known and frequently used by compiler people) are followed.
We never tried to prove that "our solution" was the ONLY valid one. We only wanted to prove that the Rybka binary matches the Fruit source perfectly in some cases, or semantically (due to bitboard vs mailbox differences) in others. At that point, one could argue one of the two following positions:
(1) Vas copied fruit, translated it to bitboards, and we base this on the exact semantic matches in so many of the evaluation terms, or in the case of crafty / rybka 1.6.1, the exact matches everywhere.
(2) Vas just serendipitously developed a program that just happens to match fruit so exactly, and Crafty perfectly, without copying. Even though this has never been seen by anyone familiar with programming, it is possible. And with that "it is possible" I agree. It is also JUST as probable that a meteor is going to hit the earth's atmosphere, not burn up, and hit the ground as a meteorite in my back yard. And that I will have a diamond about 3 feet in diameter to use for my retirement. It is possible. Because you can't prove it is impossible since meteorites are displayed in museums around the world. But just how probable?
(1) is by FAR the more probable explanation. Out into the 99.99999% probable range. That is "good enough" for most people... The more probable something is, the more likely that is the actual explanation...
You continue to not understand the comparison we did. And you continue to use the WRONG concept in the first place.
RE is about taking a binary and turning it into a source program that one can read or modify. We did NOT do that. We took the Fruit source, and the Rybka asm (from the binary) and compared them looking for semantic equivalence. Has nothing to do with "reverse-engineering" as you are using the term. That's been a red herring from the get-go, because that was not done ANYWHERE in the investigation. There are no "mistakes to be made" when semantic equivalence techniques (which are well-known and frequently used by compiler people) are followed.
We never tried to prove that "our solution" was the ONLY valid one. We only wanted to prove that the Rybka binary matches the Fruit source perfectly in some cases, or semantically (due to bitboard vs mailbox differences) in others. At that point, one could argue one of the two following positions:
(1) Vas copied fruit, translated it to bitboards, and we base this on the exact semantic matches in so many of the evaluation terms, or in the case of crafty / rybka 1.6.1, the exact matches everywhere.
(2) Vas just serendipitously developed a program that just happens to match fruit so exactly, and Crafty perfectly, without copying. Even though this has never been seen by anyone familiar with programming, it is possible. And with that "it is possible" I agree. It is also JUST as probable that a meteor is going to hit the earth's atmosphere, not burn up, and hit the ground as a meteorite in my back yard. And that I will have a diamond about 3 feet in diameter to use for my retirement. It is possible. Because you can't prove it is impossible since meteorites are displayed in museums around the world. But just how probable?
(1) is by FAR the more probable explanation. Out into the 99.99999% probable range. That is "good enough" for most people... The more probable something is, the more likely that is the actual explanation...
![[fr]](/mwf/v12/flags/fr.png "France")
You forgot Case 3. The one that actually happened.
3. Vas studied Fruit's evaluation. He studied other evaluations. He thought about evaluation from his position as International Master strength chess player.
He wrote down his ideas about which evaluation concepts to use. There is overlap with some of Fruit's concepts. Overlap with some other program's concepts. And his own ideas.
He thinks about what weights he will use for each of the evaluation concepts. These weights are very different to Fruit's.
He then writes the evaluation, using a bitboard data structure (which means at the source code level his code will be very different to Fruit's which is a mailbox program).
So, we have different code, different weights, some different ideas and some parallel ideas.
(3) This is by far the most probable explanation. Out into the 99.99999% probable range. That is "good enough" for most people... The more probable something is, the more likely that is the actual explanation...
3. Vas studied Fruit's evaluation. He studied other evaluations. He thought about evaluation from his position as International Master strength chess player.
He wrote down his ideas about which evaluation concepts to use. There is overlap with some of Fruit's concepts. Overlap with some other program's concepts. And his own ideas.
He thinks about what weights he will use for each of the evaluation concepts. These weights are very different to Fruit's.
He then writes the evaluation, using a bitboard data structure (which means at the source code level his code will be very different to Fruit's which is a mailbox program).
So, we have different code, different weights, some different ideas and some parallel ideas.
(3) This is by far the most probable explanation. Out into the 99.99999% probable range. That is "good enough" for most people... The more probable something is, the more likely that is the actual explanation...
If you don't "copy" you will not match anywhere NEAR the level Rybka matches fruit.
When I have, on a few occasions, looked at other source codes for ideas, ideas is what I am after. Not implementations. Things like "hmm, he has a bonus for a bishop on the long diagonal" or "he has a bonus for urging a passed pawn to advance by supporting it." Those are ideas. Going to "he has a bonus if the square in front of the passed pawn is attacked more times than it is defended, we get a penalty, if it is defended more times than it is attacked, we get a bonus. If the next square is ... etc. That is not an idea. That is an implementation of an idea. That is what Vas did, otherwise there would not be so many exact matches...
When I have, on a few occasions, looked at other source codes for ideas, ideas is what I am after. Not implementations. Things like "hmm, he has a bonus for a bishop on the long diagonal" or "he has a bonus for urging a passed pawn to advance by supporting it." Those are ideas. Going to "he has a bonus if the square in front of the passed pawn is attacked more times than it is defended, we get a penalty, if it is defended more times than it is attacked, we get a bonus. If the next square is ... etc. That is not an idea. That is an implementation of an idea. That is what Vas did, otherwise there would not be so many exact matches...
> That is what Vas did, otherwise there would not be so many exact matches...
There are at most 10 out of 28 matches in Rybka 1.0 beta. Two of these matches are really just one (heavy piece on the 7th rank.)
There are at most 7 out of 28 matches in Rybka 2.3.2.
If you actually read the report, you would also see that most of the matches are fairly trivial concepts (and certainly not original).
> That is an implementation of an idea.
It's a slightly more specific idea, but it's still just an idea. You are working on the mathematical level for the comparison.
The concepts are certainly not all "trivial". And the implementations are much less "trivial". But you have to first write a chess program to understand why...
Very good, Hyatt. More progress. You now moved very far away from "identical code in same order bla bla" to the very grey area of "how far are we towards the concept of an idea?"
Let's stick to knight mobility as our example.
I would like you to show, on a level suitable for lays, the code, side by side, using Fruit and Fruitified Rybka C.
Then show what you need to abstract out, replacing that with English everybody can understand.
Then show the "so many exact matches" that are left.
Over to you ........
Let's stick to knight mobility as our example.
I would like you to show, on a level suitable for lays, the code, side by side, using Fruit and Fruitified Rybka C.
Then show what you need to abstract out, replacing that with English everybody can understand.
Then show the "so many exact matches" that are left.
Over to you ........
Let's take bishop mobility since it is spelled out in the report. For bishop mobility, it is simple...
Fruit first:
mob = -BishopUnit;
for (to = from-17; capture=board->square[to], THROUGH(capture); to -= 17) mob += MobMove;
mob += unit[capture];
That is repeated 4 times, for the 4 different directions a bishop can attack. It adds a bonus for each square that is either empty or contains an opponent piece. Final product is sum of squares attacked that are either empty or contain enemy pieces.
Rybka:
attacks = bishop_attacks(square);
// evaluate king safety here...
mob = popcnt(attacks & ~own_pieces);
First, generate a map of all squares attacked (bishop_attacks(square)).
second, remove squares that contain friendly pieces (attacks & not_my_own_pieces)
Finally sum the bits, which is the sum of the squares attacked that are either empty or contain enemy pieces.
Same exact idea (this is a simple idea, but there are still quite a few different ways things could be done). They match perfectly. By itself? Not so meaningful. Taken together with all the other matches? too many. WAY too many...
Fruit first:
mob = -BishopUnit;
for (to = from-17; capture=board->square[to], THROUGH(capture); to -= 17) mob += MobMove;
mob += unit[capture];
That is repeated 4 times, for the 4 different directions a bishop can attack. It adds a bonus for each square that is either empty or contains an opponent piece. Final product is sum of squares attacked that are either empty or contain enemy pieces.
Rybka:
attacks = bishop_attacks(square);
// evaluate king safety here...
mob = popcnt(attacks & ~own_pieces);
First, generate a map of all squares attacked (bishop_attacks(square)).
second, remove squares that contain friendly pieces (attacks & not_my_own_pieces)
Finally sum the bits, which is the sum of the squares attacked that are either empty or contain enemy pieces.
Same exact idea (this is a simple idea, but there are still quite a few different ways things could be done). They match perfectly. By itself? Not so meaningful. Taken together with all the other matches? too many. WAY too many...
> Same exact idea (this is a simple idea, but there are still quite a few different ways things could be done). They match perfectly.
This is a lie. Fruit starts the mobility count at -6, which you seem to have omitted from your code quote. This is why Watkins only gives this a 0.8 match in his extensive survey.
Furthermore, you routinely state that things are done in the same order etc. If this was true, if Vas just copied and translated, then how does the "// evaluate king safety here..." end up in the Rybka code? It seems that Rybka does things in a distinctly different order.
All you have left in terms of similarity is the idea of counting pseudolegal moves. The idea is even implemented in a different way in Rybka than in Fruit (the algorithms are clearly different). Also, this idea is older than time.
Aha, so we continue to be perfectly consistent? My PST values are offset by a constant, but that is a perfect match. Fruit starts the mobility count offsete by -6, and that is different. I guess I get this now.
There is no "order" in mobility. Just a test/sum for each square. The "order" better applies to passed pawns or backward pawns, if you prefer to see where "order" is "revealing".
Nobody has said "copying mobility shows outright copying. It is just one of a BUNCH of pieces of evidence...
There is no "order" in mobility. Just a test/sum for each square. The "order" better applies to passed pawns or backward pawns, if you prefer to see where "order" is "revealing".
Nobody has said "copying mobility shows outright copying. It is just one of a BUNCH of pieces of evidence...
> Fruit starts the mobility count offsete by -6, and that is different. I guess I get this now.
No, you don't get it. The point is that Watkins admitted that this made the features different.
> There is no "order" in mobility.
Of course there is an order that in how the bishop mobility is done.
For instance, Fruit does the count and addition 4 times, one for each bishop direction.
While Rybka does the whole count at once, and then the addition.
So this is a clear example of how Rybka DOES NOT do "exactly the same things, in exactly the same order." Rather, Rybka does a different thing (doesn't start at -6), and it does it in a different order, that is, the algorithmic implementation is different.
Apart from that, the concept is so primitive and unoriginal that it is nonsensical to use it as evidence against Rybka. There is no fingerprint of copying, and it can never be a "part of the whole picture of being a derivative" since it's as common a concept as, say, alpha-beta, null-move, or the idea of assigning 1, 3, 3, 5, 9 to pieces.
I would bet that practically all modern, strong engines do bishop mobility in practically the same way, having tested it to the most efficient way.
That is NOT the order that is important. What is IMPORTANT is the order of things that make a difference. Do you check for a pawn behind you before you check for one in front of you. Do you check for an enemy pawn in front (half-open file) before or after you check to see if the pawn is weak.
In lots of cases, order makes a critical difference because the tests won't work if the order is changed...
As I said previously, your incompetence is showing. I have already explained that we have to factor out the differences caused by bitboards vs mailbox. Since you don't seem to grasp that, that "difference" would be the loops vs the popcnt.
Bishop mobility then becomes
1. count number of squares bishop can reach, excluding squares with friendly pieces on them
2. add count * bonus to score
Next eval term. Mobility is a simple one. They match nearly perfectly. Only difference is that one produces scores between 0 and 13, the other produces scores between -6 and 7.
Seems perfectly easy to understand for me. Was perfectly easy to understand for people on the panel. You? apparently not. Again, bitboard operations do NOT count as a "difference".
In lots of cases, order makes a critical difference because the tests won't work if the order is changed...
As I said previously, your incompetence is showing. I have already explained that we have to factor out the differences caused by bitboards vs mailbox. Since you don't seem to grasp that, that "difference" would be the loops vs the popcnt.
Bishop mobility then becomes
1. count number of squares bishop can reach, excluding squares with friendly pieces on them
2. add count * bonus to score
Next eval term. Mobility is a simple one. They match nearly perfectly. Only difference is that one produces scores between 0 and 13, the other produces scores between -6 and 7.
Seems perfectly easy to understand for me. Was perfectly easy to understand for people on the panel. You? apparently not. Again, bitboard operations do NOT count as a "difference".
> That is NOT the order that is important. What is IMPORTANT is the order of things that make a difference.
NO! The order that is important is the order of the implementation/algorithm. Either Rybka used the same order as Fruit, or else Rybka didn't. You claimed tons of times that Rybka did things in the same order as Fruit on an implementation/algorithmic level. So this is what we are going to check.
Note: The reason for possible changes of order is immaterial. Either Rybka did things in the same order, or it didn't.
> As I said previously, your incompetence is showing.
You saying so doesn't make it true. Why do you think that you saying something makes said thing true? What is wrong with you?
> I have already explained that we have to factor out the differences caused by bitboards vs mailbox.
But that doesn't explain why Rybka put in king safety stuff in the middle of the mobility evaluation. It also doesn't explain why Fruit didn't finish its count for all 4 directions before adding up, rather than counting and then adding 4 times.
> Bishop mobility then becomes
> 1. count number of squares bishop can reach, excluding squares with friendly pieces on them
> 2. add count * bonus to score
Congrats. You have managed to filter out ALL implementation particulars, in order to prove that Fruit and Rybka does things in the same way.
> Was perfectly easy to understand for people on the panel.
To be honest, I doubt that more than 2 people on the panel though about the bishop mobility feature details before voting YES. That would be Zach and Watkins. Not a rank amateur like you who claimed that each eval feature was done in the same way, lying through your teeth, and not knowing the quantitative data from Watkins' extensive report when entering these discussions.
As I said, you don't get it, and I am NOT going to explain it again. The first step for each comparison we did was to eliminate the differences caused by bitboards vs mailbox. Since you can't get past that, please remain stuck there for a while. It will keep you busy...
OK, time to show you exactly why you are incompetent to join this discussion.
Let's take a simple example.
The initializing the mobility count at the top vs right before the loop.
question 1. Where do you declare variables in C? at the top of a block of code, or right where you need it? Answer: At the top.
question 2. If you want to initialize a variable to (say) -6, which of the following would you choose:
(a)
int a;
...
a = -6
for (etc)...
or
(b) int a=-6;
...
for (etc)
I always choose (b) because it is less typing.
However,
question 3. When you put int mob=-6 at the top of the code, does the compiler put it there in the binary?
answer: A good compiler will "think" OK, MOB is not used until way down HERE, and the scope is only 4-5 lines, so I really don't even NEED to create a memory variable, I can just put this in a register. But I don't want to assign -6 to a register up at the top of the procedure, as the register will be tied up and hurt code generation, so I will initialize the register to -6, right before the loop. So even though the C initializes it at the top of the procedure, the binary initializes at at the point where it is used.
You need to get out of discussions about comparing source to binary when you don't have ANY understanding about the topic at all. And believe me, based on these comments, you really don't have a clue.
Semantic equivalence does not fall into that "trap". The order of the "instructions" is not important, that is, whether the variable is initialized at the top, or at the point of first use is irrelevant to the semantics of the program, so long as both produce the same final result. The order of instructions within a specific "stream" is critical to produce the right answer. But it is quite common, in an optimized code, to find instructions interlaced in odd ways...
The initial "bias" is a "slight difference". No debate there. But your concept of what I mean when I say "same things in the same order" is simply 100% incorrect. Until you understand the topic, diving in just leaves you looking foolish or inexperienced.
In short, your argument is specious at best, most likely just absolutely wrong. It is not my intention to teach a compiler class here, so you are going to have to figure out some things for yourself. Or go take a course somewhere that covers all of this in detail. It is a common thing taught in CS programs...
Let's take a simple example.
The initializing the mobility count at the top vs right before the loop.
question 1. Where do you declare variables in C? at the top of a block of code, or right where you need it? Answer: At the top.
question 2. If you want to initialize a variable to (say) -6, which of the following would you choose:
(a)
int a;
...
a = -6
for (etc)...
or
(b) int a=-6;
...
for (etc)
I always choose (b) because it is less typing.
However,
question 3. When you put int mob=-6 at the top of the code, does the compiler put it there in the binary?
answer: A good compiler will "think" OK, MOB is not used until way down HERE, and the scope is only 4-5 lines, so I really don't even NEED to create a memory variable, I can just put this in a register. But I don't want to assign -6 to a register up at the top of the procedure, as the register will be tied up and hurt code generation, so I will initialize the register to -6, right before the loop. So even though the C initializes it at the top of the procedure, the binary initializes at at the point where it is used.
You need to get out of discussions about comparing source to binary when you don't have ANY understanding about the topic at all. And believe me, based on these comments, you really don't have a clue.
Semantic equivalence does not fall into that "trap". The order of the "instructions" is not important, that is, whether the variable is initialized at the top, or at the point of first use is irrelevant to the semantics of the program, so long as both produce the same final result. The order of instructions within a specific "stream" is critical to produce the right answer. But it is quite common, in an optimized code, to find instructions interlaced in odd ways...
The initial "bias" is a "slight difference". No debate there. But your concept of what I mean when I say "same things in the same order" is simply 100% incorrect. Until you understand the topic, diving in just leaves you looking foolish or inexperienced.
In short, your argument is specious at best, most likely just absolutely wrong. It is not my intention to teach a compiler class here, so you are going to have to figure out some things for yourself. Or go take a course somewhere that covers all of this in detail. It is a common thing taught in CS programs...
That's a lot of irrelevant nonsense to write in order to not addressing the point that Watkins determined the features as different since Fruit started the count at -6. Comparing source to binary is completely irrelevant for this discussion for now, since we are looking at matches at the semantical level first.
For the second part, you seem to have completely missed that the -6 thingy was not the thing that made the algorithm-orders different. Please re-read my post again, or read Trotsky's post where he made exactly the same point, only more eloquently than me.
For the second part, you seem to have completely missed that the -6 thingy was not the thing that made the algorithm-orders different. Please re-read my post again, or read Trotsky's post where he made exactly the same point, only more eloquently than me.
I said "same things in the same order". You challenged me on several fronts. I didn't miss anything. I didn't address any specific piece of eval code until Chris brought up that particular piece of code. Which is a good example of how one can rewrite mailbox to do the same thing...
The -6 has NOTHING to do with "order". You do not understand the concept. So you are going to continue to thrash around.
"same order" does not mean every operation is done in the same order, because bitboard and mailbox operations are different to start with. But the QUESTIONS one asks in an evaluation term is the key. What order are the questions asked in? Because that is important for efficiency, and for what the code actually does. You don't get that. Fine. Then don't jump in until you do.
The -6 has NOTHING to do with "order". You do not understand the concept. So you are going to continue to thrash around.
"same order" does not mean every operation is done in the same order, because bitboard and mailbox operations are different to start with. But the QUESTIONS one asks in an evaluation term is the key. What order are the questions asked in? Because that is important for efficiency, and for what the code actually does. You don't get that. Fine. Then don't jump in until you do.
> The -6 has NOTHING to do with "order".
Which just shows you don't understand the point. Nobody said it was about order, but Watkins used it as evidence that Rybka and Fruit didn't do the same thing in the first place.
> "same order" does not mean every operation is done in the same order, because bitboard and mailbox operations are different to start with. But the QUESTIONS one asks in an evaluation term is the key.
Umm, same order means exactly that, that the same things are done in the same order. Here is the order that Fruit did things in:
1) Count attacked squares in one out of 4 directions.
2) Loop for the 4 directions.
Here is what Rybka did:
1) Count squares attacked.
2) Do some king safety stuff.
2) Apply count from 1 to bishop mobility.
Two completely different orders.
> You don't get that. Fine. Then don't jump in until you do.
What is it about your obsession to tell me what to do and what not to do? If you don't want me to jump in, why didn't you ask the same thing of rank amateurs like David Levy and Harvey Williamson? Please note, you are here a pygmy between giants. Your arguing skills are second rate, your logical skills are nearly non-existant, your scientific integrity has been found wanting, and your obsessive behaviour towards defaming Vas has shown you to have zero self-knowledge nor wisdom.
David and Harvey are not "rank amateurs". They actually have backgrounds in computer chess. You obviously do not, you are in over your head, and you think that by reading for 30 minutes you are now an expert. Not happening...
![[nl]](/mwf/v12/flags/nl.png "Netherlands")
David and Harvey are not "rank amateurs".
They are. They have no clue about all the nonsense in the report and your abysmal lies to prove something that cannot be proven.
They actually have backgrounds in computer chess.
Has HW written chess software?
You obviously do not
Wrong again. Alkelele has been involved in computer chess and so this is just another one of your lies.
and you think that by reading for 30 minutes you are now an expert.
He has clearly shown that you are lying and that you are saying different things than Watkins does.
They are. They have no clue about all the nonsense in the report and your abysmal lies to prove something that cannot be proven.
They actually have backgrounds in computer chess.
Has HW written chess software?
You obviously do not
Wrong again. Alkelele has been involved in computer chess and so this is just another one of your lies.
and you think that by reading for 30 minutes you are now an expert.
He has clearly shown that you are lying and that you are saying different things than Watkins does.
If Alkelele has been involved in computer chess, he is absolutely the most incompetent computer chess programmer I have ever encountered... Or else, he has joined Ed and is simply being intentionally dishonest. Programmers won't make some of his arcane arguments about comparing C and ASM. Ergo, I simply "don't buy it."
> Programmers won't make some of his arcane arguments about comparing C and ASM.
I haven't made an argument anywhere whatsoever whensoever about comparing C and ASM, at all, ever.
Yet another one of your lies. Over to you again.
<sigh>
Then WHY are you in those discussions about comparing the two if you are not making any arguments about them?
You were JUST IN a discussion about C to asm. Bishop mobility sound familiar? Silly statements about order sound familiar?
Then WHY are you in those discussions about comparing the two if you are not making any arguments about them?
You were JUST IN a discussion about C to asm. Bishop mobility sound familiar? Silly statements about order sound familiar?
> You were JUST IN a discussion about C to asm.
No, you were the only one babbling about C to asm in order to excuse the fact that you omitted the -6 offset when detailing Fruit's algorithm. I have never discussed C to asm anywhere.
I didn't omit a thing about Fruit's mobility.
You omitted the -6 offset in Fruit's mobility. The -6 offset in Fruit was the sole reason for Watkins giving Rybka a 0.8 rather than a 1.0 match (in his second report, that is; in his first report, he did give a 1.0 match -- btw, why the discrepancy?).
No idea. I don't think the "values" count as much as the "process" here, because the values are all different anyway...
You seem very stuck on the idea that programmers are at the pinnacle of achievement. Products nowadays are produced by teams, amongst whom are some craft workers known as programmers. They are organised and tasked by superiors. They are usually only responsible for a small part of a project, and when they are done they get switched to something else. It is very useful for the people that organise them to have been programmers at one time, ifonly to deal with the reams of bullshit that programmers come up with. There are no bugs. I fixed that bug. It works. You can only do it this way. You can't do it that way. I need this piece of kit, cost thousands of dollars to do this. No I have not partitioned my PC and am not spending half my work time on outside projects of my own. If you fire me nobody else knows how to use the kit. All code must be written in my favourite language. My managers are idiots. Only I know everything. Everybody else is an idiot. No I am not playing COD4 whenever the manager is away.
Some programmer are great people, but it is also a very desirable occupation for lazy liars, especially when management is weak.
You appear to have programmer disease, really badly, Hyatt ;-)
Some programmer are great people, but it is also a very desirable occupation for lazy liars, especially when management is weak.
You appear to have programmer disease, really badly, Hyatt ;-)
We don't have large "teams" with management, designers, and programmers working on chess programs. Most are a one or two-man show. So what does that have to do with the Rybka/Fruit investigation? The only "disease" I have is "practical disease". How about sticking to computer chess? Or we can open a new debate on software engineering and talk about agile processes, or extreme programming, or any team concept you want to discuss. Has nothing to do with the current issue however.
Software games nowadays have huge teams of which programmers are a mere part. Even my old company, back on the 1990s, would have flexible teams on any one project of a producer (in general charge and liaising with the publishing client), an engine programmer, a support and interface programmer, an artist, a test team of up to two testers, and that was for relatively simple games with non-massive graphic content. I suggest you ask, say Garvin, who is a Ubisoft programmer, I used to supply them, how many people work on a modern style game of the type you like playing - many, many more. Your one or two man bands, in the current environment, will be able to produce software full of bugs and with limited and badly designed user interfaces only, where the bugs are left to the end users to find.
I am simply suggesting to you that the "programmer", that you elevate to lofty heights of superhero, knowing everything, is actually just a modern day craft worker who needs supervision and whose analytical mind is often lacking. Many programmers are also well adept at bullshit, especially those practising it all their working lives. Hence don't knock those who come at this problem from other angles, because they too often have valuable insights that you miss. Or sometimes they see through _your_ bullshit, although a little technical help from some of us is valuable to them in that regard too ;-)
I am simply suggesting to you that the "programmer", that you elevate to lofty heights of superhero, knowing everything, is actually just a modern day craft worker who needs supervision and whose analytical mind is often lacking. Many programmers are also well adept at bullshit, especially those practising it all their working lives. Hence don't knock those who come at this problem from other angles, because they too often have valuable insights that you miss. Or sometimes they see through _your_ bullshit, although a little technical help from some of us is valuable to them in that regard too ;-)
All well and good. Which commercial chess programs today are developed by a large team? Certainly not Rybka? A team would not lose all source? What does a large team have to do with the topic at hand, period.
I worked with a very large team on an operating system project in the early 80's. I understand how it works. And that is completely irrelevant in the context of chess development...
I worked with a very large team on an operating system project in the early 80's. I understand how it works. And that is completely irrelevant in the context of chess development...
If Alkelele has been involved in computer chess, he is absolutely the most incompetent computer chess programmer I have ever encountered...
You are losing the argument with Alkelele and thus you are going back to insults, as nothing else works anymore. What a sad person you are.....
You are losing the argument with Alkelele and thus you are going back to insults, as nothing else works anymore. What a sad person you are.....
I am "losing that discussion?" I hope my retirement investments "lose" at that same rate... I'll be even better off than expected.
I hope my retirement investments "lose" at that same rate...
They will be worthless in the future (see my signature), so that would be a fitting conclusion :-).
They will be worthless in the future (see my signature), so that would be a fitting conclusion :-).
Somehow, I don't think so...
That is because you don't know the history of fiat currencies and paper monies.
I know about 64 years of "history of currency and paper money in the US." Indirectly, I know about it a lot longer than that.
What is your point? Gloom and doom?
Enjoy it if that turns you on...
What is your point? Gloom and doom?
Enjoy it if that turns you on...
One instruction (popcount) versus 4 expensive loops.
What about common sense ?
===================================================
FRUIT :
case Bishop64:
// mobility
mob = -BishopUnit;
for (to = from-17; capture=board->square[to], THROUGH(capture); to -= 17) mob += MobMove;
mob += unit[capture];
for (to = from-15; capture=board->square[to], THROUGH(capture); to -= 15) mob += MobMove;
mob += unit[capture];
for (to = from+15; capture=board->square[to], THROUGH(capture); to += 15) mob += MobMove;
mob += unit[capture];
for (to = from+17; capture=board->square[to], THROUGH(capture); to += 17) mob += MobMove;
mob += unit[capture];
===================================
RYBKA:
mob = popcnt(attacks & ~own_pieces);
What about common sense ?
===================================================
FRUIT :
case Bishop64:
// mobility
mob = -BishopUnit;
for (to = from-17; capture=board->square[to], THROUGH(capture); to -= 17) mob += MobMove;
mob += unit[capture];
for (to = from-15; capture=board->square[to], THROUGH(capture); to -= 15) mob += MobMove;
mob += unit[capture];
for (to = from+15; capture=board->square[to], THROUGH(capture); to += 15) mob += MobMove;
mob += unit[capture];
for (to = from+17; capture=board->square[to], THROUGH(capture); to += 17) mob += MobMove;
mob += unit[capture];
===================================
RYBKA:
mob = popcnt(attacks & ~own_pieces);
Common sense is what shows those are semantically equivalent. Or do you want to now claim that copying code that uses mailbox and then translating it to use bitboards results in a completely original work? Copying a book about a hero in the army, but move him to the navy and you have a new and orignal book.
You REALLY need some common sense here. It makes the discussions so much easier. Get off of this "easy way out" and the "they look kinda similar" (when you say Crafty and Fruit have lots of SE code) but then "1 line vs a loop"? Can't be a copy in the case of Fruit and Rybka. That REALLY the kind of statement you want people to judge your abilities by???
You REALLY need some common sense here. It makes the discussions so much easier. Get off of this "easy way out" and the "they look kinda similar" (when you say Crafty and Fruit have lots of SE code) but then "1 line vs a loop"? Can't be a copy in the case of Fruit and Rybka. That REALLY the kind of statement you want people to judge your abilities by???
> Common sense is what shows those are semantically equivalent.
Common sense says that when you write code 10-20 times faster, pack 4 expensive loops into 1 instruction you are the better engineer. And there is no copyright on chess knowledge, no copyright on commonly used concepts such as mobility.
Now look at your latest Crafty, also a bit-boarder, on bishop mobility.
/*
************************************************************
* *
* Mobility counts the number of squares the piece *
* attacks, and weighs each square according to *
* centralization. *
* *
************************************************************
*/
mobility = MobilityBishop(square, OccupiedSquares);
if (mobility < 0 && (pawn_attacks[enemy][square] & Pawns(side)) &&
(File(square) == FILEA || File(square) == FILEH))
mobility -= 8;
score_mg += mobility;
score_eg += mobility;
/*
************************************************************
Rybka just needs ONE INSTRUCTION
He is just the better programmer than Fabien, than you.
Things are pretty simple.
But the hatred keeps you in a constant state of denial.
That's a difference between bitboards and mailbox. Never said otherwise. I was using bitboards 10 years before Rybka existed. I understand EXACTLY what the advantages are. Bitboards have been around since the early 70's (actually earlier as Samuels used them in his checkers program). Are you a lousy "engineer"? Why didn't you use them? There are valid arguments for each way. And once you choose the methodology, some things become simpler with one than with the other. Working with "sets" is a bitboard concept. Working with "lists" is a maiklbox concept. Either works. In some cases, one is faster than the other, in other cases, not...
Rybka doesn't need "just one instruction". It has to do the rotated bitboard lookups (two times, once for each diagonal). That is fairly expensive accesses into large arrays. Then it ORs them together to produce the set of attacked squares. Then it does the popcnt. NOT "one instruction". Dump the asm and you will see.
MY mobility doesn't do that two lookups, and the OR, and the popcnt. It just looks up the mobility directly, which has been pre-computed. A 16 bit memory load and I am totally done. You need to stop trying to lecture ME on how bitboards work. I've only been doing 'em 17 years longer than you. The popcnt() is the least of the issues with generating mobility. For anyone that understands the underlying idea... Creating the set of attacked squares is the hard work. Both in bitboards AND mailbox since that is where the loops come from in mailbox...
If you measure speed, you will find MY mobility is faster. Why? Because what he does is what I did so long ago, and still do today:
score+=BISHOP_MOBILITY*MobilityBishop(square);
What you see today is a prototype:
mobility = MobilityBishop(square, OccupiedSquares);
if (mobility < 0 && (pawn_attacks[enemy][square] & Pawns(side)) &&
(File(square) == FILEA || File(square) == FILEH))
mobility -= 8;
score_mg += mobility;
score_eg += mobility;
Something Tracy played with that does MORE than just mobility. The first line, BY ITSELF, is the equivalent of all that code Vas uses. The if() is checking for a very restricted mobility, and if so, AND the bishop is on one of the sides of the board, the mobility is reduced even further.
You don't even understand what the code is doing, so no wonder you can't make a valid comparison.
If you want an exact rybka or fruit equivalent from Crafty:
mobility = MobilityBishop(square, OccupiedSquares);
score_mg += mobility;
score_eg += mobility;
Is ALL I need, and it is significantly simpler than what Rybka does in terms of cycles required...
Sorry to crash your party again...
BTW if we decide to keep the above code, the extra mobility scoring will just get folded into the mobility lookup, and the code will again look just as above. Tracy changed / tweaked the scores in the obvious place for testing...
Rybka doesn't need "just one instruction". It has to do the rotated bitboard lookups (two times, once for each diagonal). That is fairly expensive accesses into large arrays. Then it ORs them together to produce the set of attacked squares. Then it does the popcnt. NOT "one instruction". Dump the asm and you will see.
MY mobility doesn't do that two lookups, and the OR, and the popcnt. It just looks up the mobility directly, which has been pre-computed. A 16 bit memory load and I am totally done. You need to stop trying to lecture ME on how bitboards work. I've only been doing 'em 17 years longer than you. The popcnt() is the least of the issues with generating mobility. For anyone that understands the underlying idea... Creating the set of attacked squares is the hard work. Both in bitboards AND mailbox since that is where the loops come from in mailbox...
If you measure speed, you will find MY mobility is faster. Why? Because what he does is what I did so long ago, and still do today:
score+=BISHOP_MOBILITY*MobilityBishop(square);
What you see today is a prototype:
mobility = MobilityBishop(square, OccupiedSquares);
if (mobility < 0 && (pawn_attacks[enemy][square] & Pawns(side)) &&
(File(square) == FILEA || File(square) == FILEH))
mobility -= 8;
score_mg += mobility;
score_eg += mobility;
Something Tracy played with that does MORE than just mobility. The first line, BY ITSELF, is the equivalent of all that code Vas uses. The if() is checking for a very restricted mobility, and if so, AND the bishop is on one of the sides of the board, the mobility is reduced even further.
You don't even understand what the code is doing, so no wonder you can't make a valid comparison.
If you want an exact rybka or fruit equivalent from Crafty:
mobility = MobilityBishop(square, OccupiedSquares);
score_mg += mobility;
score_eg += mobility;
Is ALL I need, and it is significantly simpler than what Rybka does in terms of cycles required...
Sorry to crash your party again...
BTW if we decide to keep the above code, the extra mobility scoring will just get folded into the mobility lookup, and the code will again look just as above. Tracy changed / tweaked the scores in the obvious place for testing...
what about some REAL common sense. How hard was it to produce that variable "attacks"? It is not a "ready value". It has to be produced by doing two rotated bitboard lookups, which means taking two different occupied_squares values (64 bits, rotated 45 degrees in either direction), shift them right to isolate the specific diagonal occupancy bits in the rightmost 6 bits (don't understand why 6 bits? read my paper on rotated bitboards), then ANDing off the remaining crapola. Now you have two indices. You use these to index into an array of 64 x 64 bitboards to get the set of attacks for each individual diagonal. Then you OR these together and you FINALLY have that "attacks variable". That stuff is not free. And yet you hand-waved it away ENTIRELY. Jeez what part of bitboards DO you understand???
You factor out the most difficult part of the task, and then compare what's left to fruit's code which has the loops to find the attacked squares still left in. That's not even apples and oranges. That is applies and turnips...
You factor out the most difficult part of the task, and then compare what's left to fruit's code which has the loops to find the attacked squares still left in. That's not even apples and oranges. That is applies and turnips...
> By itself? Not so meaningful. Taken together with all the other matches? too many. WAY too many...
Is 7 out of 28 features way too many?
Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill