Crafty accused of copying Fruit PST

[FWCC]

Well now Bob knows how Vas feels,what goes around comes around,hmmm maybe that explains the 1000 post on the Rybka Forum it's called GUILT?


FWCC

[mhull]

Well now Bob knows how Vas feels,what goes around comes around,hmmm maybe that explains the 1000 post on the Rybka Forum it's called GUILT?


FWCC

It's called trying to reason with morons.

[bob]

I get the point. But what you are saying is occurring way too late. You are saying "OK, I have an idea, I have designed it, I have flow-charted the code, so now there is only one way to write it."

But if you stop above the level of what is commonly called the architectural design (or detailed design) then your statement makes no sense. Because at that level, you have decided on what you are going to do, and what you want to test to pull this off, but you have not gotten to the how. Which means there are many possible choices.

This would apply to most any evaluation term. Because even good chess books generally don't define an evaluation concept at a level low enough to let us convert it to code directly.

I agree, once you have an architectural design, your hands are pretty much tied. But just deciding to evaluate some concept like a weak pawn, or more specifically a backward/isolated pawn, most definitely does _not_ tie your hands as to how it will / can be implemented.

Simple idea: I want to implement "square of the king" where if a passed pawn is inside the square of the enemy king, it can't run in and promote, while if it is outside the square of the king, it can. Well known idea. Now how to implement it? Two different approaches, one for bitboard, one for mailbox. But you are not done, because there are another few wrinkles to deal with. What about the case where both sides have a passed pawn that can't be caught? But one queens with check? A wrinkle. How to implement this detail? Several choices. Another wrinkle, once you get to the detailed design stage. Are you certain that if the pawn is in the square of the king, the king can reach it? Worst case is king is on a diagonal that is the only way to catch the pawn. What if there is a friendly pawn on the diagonal? King is blocked and can't catch it even though it is technically in the square of the king. What if there is an enemy pawn on that diagonal? Ah, you can capture it and continue chasing and catching the pawn. But what if the pawn is defended? Shoot. Blocked again.

That single piece of code has a ton of different implementations. Your hand is not tied until the very end.

Yes, for a simple term, like "is this rook on an open file?" You might just have one way to answer that. With bitboards, an AND with the right mask will do the trick. With mailbox, you can scan the file to see if there are any pawns on it. Or you can do as we did in Cray Blitz and update a set of file flags to identify which files are open/closed, when we Make/Unmake moves, which saves time. So maybe rook on open file is not so "forced"?

And this goes on and on, somethings done in eval, some done in make/unmake, and some have even counted mobility in the move generator. So saying that once you decide on an idea, you are stuck as to how to implement it doesn't make a lot of sense to me... In fact, we often add new ideas in Crafty "quick and dirty" for testing. If the results look promising, I go back and rewrite "fast and clean" which should make the results even better. And it is not uncommon to later find a better way to implement that idea that is even faster. Or more accurate. Or both.

I don't buy this "one way to write something" argument for anything but the simplest of chess-specific ideas...

For knight mobility, since you asked, I have done it in the following ways in Crafty over the years:

(1) I started with slate's attacks-from and attacks-to bitboards. I just extracted the attacks-from for the square the knight was on, which already had all the attack bit set, and popcnt'ed that and multiplied by a constant C.

(2) Later, I added a second table that contained the popcnt() values for all knight attacks on all squares. Now a table lookup and I get the answer without the popcnt() cost (back prior to the hardware popcnt instruction of course.

(3) Later I decided that mobility is not just about how many moves you have, but about which squares you are attacking (we do this today). We have a set of 4 weights. I AND away all bits but the center 4 squares, and multiply by the center square weight. I then AND away all bits but the next 'ring" and multiply the popcnt of that with that ring's weight. Repeated 4 times.

(4) early on, I removed squares from the mobility for pieces if the square was attacked by a piece. That was easy with the "attacks-to" bitboard from Slate's book chapter, where for any square, I can obtain a bitmap that shows all other squares that are attacking that square, both friend and foe. From that I can determine how many attacks by each side, and by which pieces. Lots of choices to play games here. Mobility to a square you attack less than the opponent is not very useful. Mobility to a square attacked by an enemy pawn is certainly not very useful.

Do I need to continue?

This is like saying that once you know you need to sort something, there is only one way to sort it. Not so fast. Bubble sort. Heap sort. Even an insertion/selection sort will work depending on the other details of how it is used...

I simply don't buy this "once you specify the idea, the implementation details become fixed." My experience is completely the opposite. I rarely see just one way to do anything. The trick is to see the "best way". Hopefully the first time you implement it, otherwise the second, or the third.

I am sure that you don't get the point yet, unless you prove that you have understood the meaning of the term "formula" in my post above.

I am tired to repeat these simple things over and over again. I did not ask for different ways to implement the same eval criterion but to implement a specific formula that has been chosen for that criterion.

Criterion = "knight mobility"
Formula = "count all pseudo-legal moves of the knight and multiply by a bonus"

Your approaches (3) and (4) do not implement that formula but a different one. And your approach (2) is nothing but an optimization attempt from past times which most people will no longer use today.

Your obvious misunderstanding of the concept "formula" as I use it makes most of your post void.

The point is also that many evaluation formulas are that simple. Few are more complex than that, like formulas in the domains "king safety" or "passed pawns". But complex eval features like "passed pawns" are divided into simpler and smaller parts, and for each part you define a formula on the logical level which is simple enough to implement it.

Here is a complete and realistic example:

Eval criterion = "passed pawn"
Precondition: pawn has been found to be a passer

The following sub terms and the following calculation formulas are selected by the programmer:


Sub term 1 = "initial bonus"
Formula = "assign rank-based bonus, where lower distance to promotion square leads to higher bonus and vice versa"


Sub term 2 = "king support of passer"
Formula = "multiply distance of king to square in front of the pawn by a constant bonus; use different constants for friendly and enemy king"

NOTE: The above formula is from Fruit 2.1. I just found that Mark Watkins missed that Fruit does _not_ use a rank-based bonus constant in this case, despite Rybka, when he wrote in EVAL_COMP.pdf on page 33:

Fruit 2.1, Rybka 1.0 Beta, and Rybka 2.3.2a give a rank-based bonus/penalty (with 10-30-60-100 scaling) times the distance of the square in front of the pawn to the respective kings.

Fruit 2.1, eval.cpp:

Code: Select all

// king-distance bonus

delta -= pawn_att_dist(sq,KING_POS(board,att),att) * AttackerDistance;
delta += pawn_def_dist(sq,KING_POS(board,def),att) * DefenderDistance;

where "pawn_att_dist(pawn, king, colour)" and pawn_def_dist(...) both simply return "DISTANCE(king, pawn + PAWN_MOVE_INC(colour))".


Sub term 3 = "freedom of passer to advance"

Sub term 3.1 = "lack of any friendly piece on promotion path"
Formula = "assign rank-based bonus if condition is true"

Sub term 3.2 = "lack of any enemy piece on promotion path"
Formula = "assign rank-based bonus if condition is true"

Sub term 3.3 = "every square on promotion path is defended at least as much as it is attacked"
Formula = "assign rank-based bonus if condition is true"


Sub term 4 = "unstoppable passer"
Precondition: enemy has only the king left

Sub term 4.1 = "enemy king is outside the 'pawn square'"
Formula = "assign constant high bonus if the condition is true"

Sub term 4.2 = "friendly king suffficiently guards the passer"
Formula = "assign constant high bonus if this condition is true and condition 4.1 is false"

NOTE: the choice of the formulas 4.1 and 4.2 includes the logical decision to ignore the level of advancement of unstoppable passers in case both sides have one. Taking this into account would mean to use a different formula, as in Rybka2.3.2a.

I agree that the implementation of terms 4.1 and 4.2 is relatively more complex and "non-intuitive" than all others mentioned here. But nevertheless you will not find copied code for these two in Rybka, it is only the formula that you may find.


Are these formulas protected by copyright? I say "no".

Sven

I do not believe that many evaluation terms become a "simple formula." I suspect you are using the term "formula" to mean "defined implementation." I have given several examples of a pretty precise evaluation term one might want to use, yet there are MANY different ways that can be implemented.

Even with a mathematical formula, there is often more than one way of implementing it. For example, direct computation; a monte-carlo simulation; an approximation that is much faster to compute...

And each of those would be implemented differently although they ought to all produce near-identical answers.

In your analysis above, your definition of "formula" is way off base, IMHO. For example:

Formula = "assign constant high bonus if the condition is true"

That's not a formula. It has the "if the condition is true" part which can be implemented in many different ways. that's why I don't accept your definition and explanation here. And a program might not assign "constant high bonus". It could be a dynamic but high bonus where the "dynamic part" requires additional computation to produce. Etc.

If you abstract far enough, you can say a chess program is a function F, with an input position P, such that best_move = F(P). And since that is a formula, the entire thing can't be copyrighted. The copyright standard and later opinions refer to this as "chicanery" because the implementation details have been torn away leaving only the idea "find the best chess move in a given position P". that doesn't meet any legal standard anywhere...

[bob]

Well now Bob knows how Vas feels,what goes around comes around,hmmm maybe that explains the 1000 post on the Rybka Forum it's called GUILT?


FWCC

No, because I know I didn't copy any code. Vas knows he did. Unless you want to join the "I have no grasp of statistical probability" fraternity and continue to believe that he didn't copy Crafty in early versions, and fruit in later versions. Having one similar PST with the rest being wildly different doesn't mean much. I even produced the code I had saved with the version where we added B PSTs after having removed them a few versions previously. The rest of the PSTs in Crafty are wildly different from fruit, from having 6 for kings with grossly different values than either of the two fruit tables, to not having a rook pst at all, to again grossly different pawn PST square values. Not a thing was copied. Something that can't be said for Rybka unless you don't believe in probability theory at all.. and believe you can flip a penny 100 times on a flat surface and have it land on its edge every time... never a head or tail. I mean it _could_ happen, as the probability of that is not zero. So want to bet on it happening?

[bob]

Maybe the ICGA will now investigate other closed sources if even FRUIT or CRAFTY contain copied code or PST numbers.

Isnt it better for computerchess as a whole if the campaign against Rybka led by no other than Bob himself would be stopped and revised in its consequences? Revolution is nice but then we must live with a whole lot of hypocrits if we execute someone who did nothing else than what looks now like a common habit which is exactly what Vas has stated over all the years.

There is no common habit of copying the work of others and claiming it to be your own. You may as well give up preaching that fantasy, only a few on the Rybka forum will believe you...

[bob]

And sources in china reported that a sack of rice has fallen over.

So 32 numbers (because the table is symmetric) are the same with 32 numbers from another program. For such easy stuff like psq tables this is not unusual, because the table represents a rough estimation of good and bad squares of a piece (e.g. a bishop).

I count 10: 1 back rank penalty, -1 global offset, and 10 squares once you use horizontal/vertical/rotational symmetry:

Code: Select all

XXXX
 XXX
  XX
   X

Does anyone know the heritage of the back rank penalty idea? I wouldn't be surprised if it predates both programs, but I haven't followed CC long enough.

Been around forever to encourage development. We used them at one point n Cray Blitz, then decided to evaluate development separately and turn it off at some point... kind of like what happens with interpolated scoring as material is traded.

[Michel]

Has it been sorted out now which commit introduced the tainted PST in Crafty?

[michiguel]

Well now Bob knows how Vas feels,what goes around comes around,hmmm maybe that explains the 1000 post on the Rybka Forum it's called GUILT?


FWCC

No, because I know I didn't copy any code. Vas knows he did. Unless you want to join the "I have no grasp of statistical probability" fraternity and continue to believe that he didn't copy Crafty in early versions, and fruit in later versions. Having one similar PST with the rest being wildly different doesn't mean much.

It is unbelievable how you are dealing with this. I was telling you that the probabilities you were using to say "it is impossible to match 64 numbers blah blah" were bogus. You challenged me to find a match in Crafty (you would be the worst attorney in the history of the universe) and... I did! and now, you completely change your speech to say that one is ok, but more is not. You are completely dismissing the fact that none of these things are independent while you call me (indirectly) part of the fraternity who have no grasp of statistical probability. At the same time, as I told you in the rybka forum, you are misrepresenting how similar the R1 tables to Fruit. Not all of them are a "match".

Miguel

I even produced the code I had saved with the version where we added B PSTs after having removed them a few versions previously. The rest of the PSTs in Crafty are wildly different from fruit, from having 6 for kings with grossly different values than either of the two fruit tables, to not having a rook pst at all, to again grossly different pawn PST square values. Not a thing was copied. Something that can't be said for Rybka unless you don't believe in probability theory at all.. and believe you can flip a penny 100 times on a flat surface and have it land on its edge every time... never a head or tail. I mean it _could_ happen, as the probability of that is not zero. So want to bet on it happening?

[michiguel]

Has it been sorted out now which commit introduced the tainted PST in Crafty?

There is no "tainted" PST in Crafty. But the one you refer was around 22.2 to 22.6 I do not remeber this someone looked at it. I just found it in the last version. I say it is not "tainted" because it is not unlikely to match this if you start using simple linear formulas and bonuses. Note that "match" means multipliers and constants could be change to force the match.

Miguel

[Sven]

I do not believe that many evaluation terms become a "simple formula." I suspect you are using the term "formula" to mean "defined implementation."

No, this is completely wrong. My term "formula" describes a conceptual definition of the way how an evaluation term (criterion, feature) shall be calculated, independent from data structures and concrete values. Again you are proving that you do not understand what I write.

I have given several examples of a pretty precise evaluation term one might want to use, yet there are MANY different ways that can be implemented.

You haven't. Please don't try changing things that were written. I gave an example "knight mobility" and a formula to calculate it, and you provided a verbal description of four possible implementations (referring to concrete data structures leaves the "formula" level) from which two were unrelated to the formula that I had defined. That was not anywhere near being precise And it was also not "giving examples of an evaluation term" but "giving examples of implementations for the evaluation term I had defined, two of which were wrong".

Even with a mathematical formula, there is often more than one way of implementing it. For example, direct computation; a monte-carlo simulation; an approximation that is much faster to compute...

We are not in the general space of mathematical formulas, I am talking about formulas to calculate evaluation terms. "Monte carlo" is off-topic there. Don't try to obfuscate the topic. If you have a bitboard engine and decide to evaluate knight mobility by assigning a bonus linear in the number of pseudo-legal knight moves then the efficient implementation of that IS straightforward. Same for many other eval criteria.

But even if it were not, the key point is that it shall be considered legal to use a formula like "assign a bonus linear in the number of pseudo-legal knight moves" without being accused of code copying if the implementation of that formula looks similar to the implementation of the same formula in another program.

In your analysis above, your definition of "formula" is way off base, IMHO. For example:

Formula = "assign constant high bonus if the condition is true"

That's not a formula. It has the "if the condition is true" part which can be implemented in many different ways.

It is a formula, even though it does not include the description how to detect the condition "enemy king is outside the 'pawn square'", or "friendly king sufficiently guards the passer". But you can be really, really sure that that missing part is so heavily dependent on the board representation that we do not need to consider it for a "code copying" discussion. When talking about "formulas" I am focussing on the calculation of the evaluation itself, not so much on detection of precisely defined conditions on the board. That could even be code in a totally different part of the program, like a Board class (in C++) where things like "king is outside pawn square" are handled independent from their application in the evaluation function. Such a low-level function is in the same league as a piece of code that tells you whether a given square is empty, just with some more lines of code.

that's why I don't accept your definition and explanation here. And a program might not assign "constant high bonus". It could be a dynamic but high bonus where the "dynamic part" requires additional computation to produce. Etc.

Irrelevant here. I defined the formula as "assign a constant high bonus", not a dynamic one. Again, don't obfuscate.

If you abstract far enough, you can say a chess program is a function F, with an input position P, such that best_move = F(P). And since that is a formula, the entire thing can't be copyrighted. The copyright standard and later opinions refer to this as "chicanery" because the implementation details have been torn away leaving only the idea "find the best chess move in a given position P". that doesn't meet any legal standard anywhere...

Obfuscating again. I am talking precisely about positional evaluation, not about fantasy formulas like F(P). Keep on topic, please.


As a result, you have provided zero convincing arguments but almost 100% attempts of changing the topic, or not wanting to understand. That is annoying and disappointing.

Sven