Questions for BB about Rybka PST = Fruit PST

[BB+]

Except for the fact the Fruit / Rybka piece-numbering is exactly the same as in REBEL, origin early 80's. It's a common thing to do so for speed-up reasons and keeping your tables small. It's explained on my pages, see: http://www.top-5000.nl/authors/rebel/chess840.htm#EVAL

Managed to find this now. It appears that your statement is erroneous. I agree that PNBRQK makes some sense for some reasons, but Fruit/Rybka intertwine these with white/black.

Piece-Type, REBEL has a most simple data structure for the 12 piece types as used on its internal chess board:

Code: Select all

+----+----+----+----+----+----+----+----+----+----+----+----+----+ 
| 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 
+----+----+----+----+----+----+----+----+----+----+----+----+----| 
| .. | Wp | WN | WB | WR | WQ | WK | Bp | BN | BB | BR | BQ | BK | 
+----+----+----+----+----+----+----+----+----+----+----+----+----+

In contrast, the Fruit/Rybka ordering is not the same, being

Code: Select all

const int WhitePawn12   =  0;
const int BlackPawn12   =  1;
const int WhiteKnight12 =  2;
const int BlackKnight12 =  3;
const int WhiteBishop12 =  4;
const int BlackBishop12 =  5;
const int WhiteRook12   =  6;
const int BlackRook12   =  7;
const int WhiteQueen12  =  8;
const int BlackQueen12  =  9;
const int WhiteKing12   = 10;
const int BlackKing12   = 11;

[zwegner]

Wow. Just to be clear, I was only speculating about the material table, not making accusations. My idea has already been refuted, so there's no need for Ed to get all indignant about it. (When I feel like accusing someone of something, I will be very clear about it, I assure you).

But Wylie, nice to meet you BTW, it is in the final document too. And that's the problem.

The material tables in Rybka were one of the more interesting features introduced. Their implementation was a new way to evaluate material imbalances. The indexing and evaluations in the table seem to be unique, but there are some very interesting similarities in the information stored in the table with Fruit.

Is that quote from my document untrue? I think you are overreacting to Wylie's statement. I believe the material table did previously exist (I'm pretty sure something like it is in the pre-beta Rybkas, though I didn't spend much time reverse engineering it). But it is quite curious that the flags/phase stored in the material table match almost exactly with Fruit. What do you make of it?

[BB+]

The fact that there is a morass of "general chess knowledge" has never been much of an issue.

Here is a relevant case law in copyright, phrased by Brinson as "Originality requires neither novelty or uniqueness."
The case is Alfred Bell & Co. v. Catalda Fine Arts, Inc. (1951).

Bell was making 'mezzotint' copies of public domain paintings by old masters.
* Basically, to make a mezzotint, an artist traces a photograph of a famous work of art
  and engraved the tracing onto a printing plate to make reproductions that could be easily reprinted in books.
* Catalda began reprinting some of Bell's mezzotints. Bell sued for copyright infringement.
* Catalda argued that Bell couldn't copyright the mezzotints because they were merely
  faithful reproductions of other work. Therefore they were not an original work of authorship.
          o 17 U.S.C. §102(a) requires that a work be original.
          o For example, if the Mona Lisa is in the public domain, how could you get a copyright on a copy of the Mona Lisa?
* The Trial Court found for Bell. Catalda appealed.
  The Trial Court found that every engraver would engrave the mezzotint slightly differently,
  and those subtle differences were enough to meet the originality requirement.
* The Appellate Court affirmed.
  The Appellate Court found that the term original should be read to mean "owes its origin" to a particular author,
  and not that the work was "startling, novel or unusual, or a marked departure from the past."
          o The Court noted that maps are copyrightable, and ideally all maps should be exactly the same (to be accurate).

I think the quotation in the penultimate line is a good summation of the argument against the existence of "general chess knowledge" being an impediment to originality.

I took this from Brinson's work on separating protectable expression from unprotectable ideas in computer software (see the fourth page, and footnote 16 in particular).

[mballicora]

I won't dispute the mathematics of the issue, as I think Miguel and I largely agree there (though maybe don't state it the same way). However, I think the following is an incorrect opinion about copyright/originality.

The point is that the fact that there are real alternative ways to do this alerts us about something else. There is an underlying common knowledge that can be hardly "copyrightable".
[...]
There are many ways to end up with the allegedly magic [-3,-1,0,+1], which can ultimately be decomposed in rudimentary, non-unique, non-copyrightable chess knowledge. It is not a surprise that we find this in Crafty and Stockfish!
[...]
I cannot see how this could be an issue of copying and that is the point I am trying to make, not only that there are some alternatives.

It is unsurprising that one can find one PST in Crafty [when changed by an additive constant, which was not a Fruit parameter],

I corrected Bob already about this. The normalizing constant is embedded in the vector. So, use -1,1,2,3 rather than -3,-1,0,1 and you get Crafty numbers exactly, without even touching the multipliers and using the exact same code. Saying the you can get them with +8 is an easy way to see it.

another (when approximated, and perhaps overparametrised) in Stockfish, a third PST in another engine, etc. -- but I'm sure you realise that from the statistical point of view.

No, I said this already, they were not overparametrized, and the case of the Knight tables they were underparametrized. In addition, it was not one table in Stockfish, I showed in R forum three = Knight, Queen and King.

However, what I which to stress is that any creative collection is indeed copyrightable (how many times have I said this by now?), which is exactly what the claim is in the first place -- that Rybka has many more "Fruit matches" than any other engine, or that could be derived by chance. In the case here, I can certainly admire Richard Vida's sentiment, that PST is too minute to matter from the standpoint of computer chess [a similar argument was made (and accepted) when the R4/Buzz magic multiplication code was evidenced in the Panel], but I would insist that there is at least some creative content in choosing a specific list of 10 or so "ramping arrays" and/or PST methodologies.

That is the point, there no lists of 10 ramping arrays, they are four or five, which the imply obvious chess knowledge. They look many because -3,-1,0+1 is repeated several times.

So I'll say it again (as it's a general principle) until I'm blue in the face: the fact that there is a "general source of knowledge" out there from which almost all engines borrow has little (if any) relevance to the usage of specific examples or encodings therein. This is the accusation against Rybka -- not that Fruit had a bunch of general chess knowledge and so does Rybka, but that they share way too much of the specific aspects of rendering this.

There is very little of specificity in these tables. In fact, with the criteria used, Fruit Q tables and K endgame tables were cloned... from Fruit B table. They can be generated from that one, just changing the multipliers (not even the ramping array!).

Miguel

The principal "creativity" (and/or originality) is thus in making choices concerning what aspects of the general knowledge to implement, how to do so, whether or not these choices jive well with each other, etc.

Some additional arguments in this genre are developed in the introduction to EVAL_COMP [for instance, the first footnote about an essay on Argentina -- forming a composite work out of a general store of knowledge is legitimate, but when one follows a single source the issue becomes more hairy]. My impression is that most claims of "nonliteral copying" tend to end up in this sort of a debate.

[hyatt]

You say "they look many but several are repeated.... therefore... "

Doesn't that assume that those are the only values possible, as opposed to "those are just the sets Fabien chose, although he _could_ have chosen many others that would produce tables close to but not identical with his current ones? Just because HIS B PST and Q PST are similar does not mean that everyone is going to have that same thought. Mine are somewhat similar in that bigger in the center, smaller on the edges, but there a _lot_ of room in that description for making PSTs. In fact, the detail that Fabien uses the same approach in more than one table, and Rybka does also, suggests a problem immediately, to me.

This is not about how simple it is to make one table, it is about how likely it is that all tables between two different programs are beyond highly correlated and can actually be produced by the same code with just a few constant changes. I've used several different B PST tables since Crafty has been around. At the time, each seemed to be "just right" after tuning. And most likely, any of the old tables would work about as well as what I use today, as we are only talking about a few Elo for the entire table being used or not...

Even if you try to be very generous in doing probabilities, by saying "OK, there are only maybe 100 possible values for any PST square. We divide those into 10 groups of 10. The biggest group will only be used in the middle squares, the smallest group will only be used on the outer squares, and each square closer to the center will be an exact multiple of the adjoining square that is one rank/file further away... and so forth."

You still get a fairly small probability that two different people would come up with the same rank/file multipliers, the same constant multiplied to get the final value, then the same constant offset to raise/lower/center all the values, and then the same extra penalties or bonuses applied to a sub-group (like back rank, or the forward rank corner squares, etc. Even if you ultra-generously say that there is only 100 possible configurations of PST values that fits that description, meaning any two programmers have a one in 100 chance of matching, that still has a problem that if you have at least 6 piece types if all are symmetric, or 12 piece types if they are not. x2 for opening/endgame if you use the interpolation scoring idea. (1/100)^12 is still quite small. You could try to be more generous and suggest "OK, maybe the _really_ different piece types are pawn, knight, and then bishop-rook-queen are similar, and then kings. SO we have 4 piece types rather than 6. That still leaves a low probability that all match up, even though with 1/100 for a single table match, there are way more than 100 programs around so we know there will be a match here and there. But just here and there. Not everywhere.

BTW your last statement makes my case for me. In Fruit, the B PST values are quite similar to the king PST values. Not at all so in Crafty. Or compare the fruit/crafty pawn PSTs which show WILD differences as I gave in another post. The pawn tables are far more likely to be different after comparing Fruit to Crafty, yet for Fruit/Rybka...

[BB+]

I corrected Bob already about this. The normalizing constant is embedded in the vector. So, use -1,1,2,3 rather than -3,-1,0,1 and you get Crafty numbers exactly, without even touching the multipliers and using the exact same code. Saying the you can get them with +8 is an easy way to see it.

OK, I didn't catch this. But this is no longer the Fruit ramping arrays. You've made them parameters (see below), while I insist they are not for the Rybka/Fruit comparison, where they can be taken to be the same. [The Fruit method must have, e.g., 0 at d2, when using the ramping array in question (and Crafty does not)]. If you argue that there are 8 parameters, I will say: "OK, but 4 of these 8 are the same (by whichever method, either ramping arrays or redundancies via linear relations) in F/R -- is there a similar commonality amongst your 8 parameters for other engines?"

No, I said this already, they were not overparametrized,

Well, I guess we are going to argue about the mathematics then (and this forum is not the easiest to typeset, if it comes to that)... Fruit uses specific arrays, like -3 -1 0 1. If you view these specific arrays as "parameters" also, you add four more. But the Rybka data can be determined from the use of the same ramping arrays as Fruit (sorry for so many bolds, but this is the point). Counting these notable commonalities of Fruit/Rybka as "parameters" of a more general layout seems just plain wrong to me.

There is very little of specificity in these tables..

Here is the challenge: find another pre-2005 engine that reproduces so many PSTs via the Fruit process that recurs "overly often" in Rybka, that is without changing the "ramping arrays".

In fact, with the criteria used, Fruit Q tables and K endgame tables were cloned... from Fruit B table. They can be generated from that one, just changing the multipliers (not even the ramping array!)

Fruit made a specific choice for the ramping-array of the Bishops. Then another specific choice of ramping-array for Queens, then Kings, etc. You can indeed argue than none of these are particularly earth-shattering, but their summatory effect is exactly the point. A relevant legal quotation is: Lest we fall prey to defendants' invitation to dissect the works, however, we should remember that it is the combination of many different elements which may command copyright protection because of its particular subjective quality.

That is the point, there no lists of 10 ramping arrays, they are four or five, which the imply obvious chess knowledge. They look many because -3,-1,0+1 is repeated several times.

I think this is misguided, as the multiplicity and specificity of use matters too. If there are 5 "reasonable" lists (ABCDE) that specify some chess knowledge for any PST [say it's left-to-right increasing, such as -2,-1,0,1 and -3,-1,0,-1 and -4,-1,0,1 and 0,0,2,3 and -4,-2,0,3] , and my engine uses them for the (say) 8 PSTs as: AEDBBBEA, this is a particular choice. For your engine to choose (first the same process and then) the same AEDBBBEA usage independently would be quite rare. This is (in essence, perhaps not to degree) the gravamen of the Fruit/Rybka PST issue.

[Rebel]

Wow. Just to be clear, I was only speculating about the material table, not making accusations. My idea has already been refuted, so there's no need for Ed to get all indignant about it. (When I feel like accusing someone of something, I will be very clear about it, I assure you).

But Wylie, nice to meet you BTW, it is in the final document too. And that's the problem.

The material tables in Rybka were one of the more interesting features introduced. Their implementation was a new way to evaluate material imbalances. The indexing and evaluations in the table seem to be unique, but there are some very interesting similarities in the information stored in the table with Fruit.

Is that quote from my document untrue? I think you are overreacting to Wylie's statement. I believe the material table did previously exist (I'm pretty sure something like it is in the pre-beta Rybkas, though I didn't spend much time reverse engineering it). But it is quite curious that the flags/phase stored in the material table match almost exactly with Fruit. What do you make of it?

I don't know and I don't care any longer. Today I made up my mind. See, http://www.open-chess.org/viewtopic.php?f=3&t=1559

What I did not like is the suggestive part, the sentiment of the document already is GUILTY and them on a total new feature, that is unique and clean the temptation could not be resisted to link it with Fruit after all, guys pay attention, although we have something new here, it's still Fruit. That's how it reads in the end. I hate that kind of presentation as it is suggestive.

At the time this whole Rybka=Fruit circus started I did not pay much attention because they were mainly statements with little supported evidence. I got interested when the "0.0" abnormality came-up and I thought, now that is an atomic bomb, one more and I a concur. So bring me that second bomb. Today I found a candidate bomb myself. The order in EVAL.

[BB+]

Here is a demonstration for why the ramping arrays should not be considered "parameters" in a Rybka/Fruit comparison vis-a-vis other PSTs. Essentially, I note that the Rybka values and the assumption of the Fruit process determine the necessitated Rybka ramping arrays (up to a multiplicative scaling constant intertwined with the "tunable" parameter), which turn out to be the Fruit ramping arrays in more cases than should occur by chance. My understanding of Miguel's work is that he is working under a counter-assumption regarding the process -- however, as noted above, the "Occam's Razor" of the situation tends to contra-indicate this as being rather unlikely [ready availability of the Fruit process, and comments like "took many things"]. So my argument is both numeric (nothing but solving linear equations), and contextual (it assumes the Fruit process was used, which I claim is a reasonable assumption, and even one that is falsifiable [and indeed is false for some of the Rybka PST], this latter fact having import when comparing to other engines).

To wit, taking bishop endgames as a first example, suppose the data give the scores -66,-44,-33,-22 for a1-d1 (this is all that is needed -- the data from other squares just confirm that the Fruit process can indeed generate the numbers), and assume the Fruit process. Then the ramping array is -3,-1,0,1 and the multiplier is 11 [or the multiplier is 1 and the arrays are elevened, but that's a bit outre]. This follows immediately from solving the linear equations given by a1+a1=-66,a1+a2=-44,a1+a3=-33,a1+a4=-22 and noticing the common factor of 11 in the (unique) solution. Similarly, -20,-10,-10,5 immediately gives (upon assuming the Fruit process, and that the end result is integral) a ramping array of -2,0,0,3 and 5 as the multiplier.

The other pieces just need a few more data points to shove into linear equations. The most complicated one is knights in the openings, where the Rybka data under the assumption of the Fruit process confer:

Code: Select all

f1+f1+r1=-3492
f1+f2+r1=-2798
f1+f3+r1=-2104
f1+f4+r1=-1757
f2+f1+r2=-2440
f2+f2+r2=-1746
f2+f3+r2=-1052
f2+f4+r2=-705
f1+f3+r3=-1388
f1+f4+r4=-683
f1+f4+r5=-325
f1+f3+r6=-314
f1+f2+r7=-1366
f2+f1+r8=-1724
f1+f1+r8+s=-5618

The only solution to this set of linear equations (with there being data from other squares that I didn't include, but they do indeed work out) is (f1,f2,f3,f4)=(-1388,-694,0,347), (r1,r2,r3,r4,r5,r6,r7,r8)=(-716,-358,0,358,716,1074,716,358) and s=-3200. Notably, all the f-values are multiples of 347, whilst the r-values are multiples of 358, and the Fruit ramping arrays then appear.

So my point is, assuming Rybka used the Fruit process (for the PST where this is feasible), the resultant ramping arrays are (usually) determined by the Rybka data, and they overall have a striking similarity to the Fruit ramping arrays [independent of whether these ramping arrays are of much "information value" or "chess knowledge content"]. I don't think there is any other engine (circa ~2005) about which this can be said.

[zwegner]

I don't know and I don't care any longer. Today I made up my mind.

Why didn't you just say this earlier, and save me the time of even trying to argue with you?

What I did not like is the suggestive part, the sentiment of the document already is GUILTY and them on a total new feature, that is unique and clean the temptation could not be resisted to link it with Fruit after all...

So basically, you didn't even read what I said.

[Rebel]

I don't know and I don't care any longer. Today I made up my mind.

Why didn't you just say this earlier, and save me the time of even trying to argue with you?

You must have missed the word today

What I did not like is the suggestive part, the sentiment of the document already is GUILTY and them on a total new feature, that is unique and clean the temptation could not be resisted to link it with Fruit after all...

So basically, you didn't even read what I said.

I did, just don't want to comment it, I could, but it is irrelevant. And I am pretty sure you understood it that way.

To speak with the famous words of Vas, I went through the documents forwards and backwards and rejected many things.