BB+ wrote:Miguel Ballicora wrote:BB+ wrote: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".
Tough challenge, but it is not relevant to my point. Why pre-2005 anyway?
The reason why I said this is that after 2005, many more engines became Fruit-influenced, and the exercise is easy. I would still argue that the PST ramping arrays are exactly the point in the Fruit/Rybka comparison. Once one specifies the process that is apparent in Fruit 2.1, from the Rybka data one derives ramping arrays that are overly common with Fruit's choices for the same. This is not true if you change the process (for instance, you might use the
Fruit 1.0 method), but then I've argued that the assumption of this process is a reasonable one.
Yes, after 2005 many engines became Fruit influenced, which speaks about how spread many of these concepts became.
BTW, This may be unrelated, but when I look at Fruit 1.0, it looked to me that Fabien was using a similar mental approach, with a higher edge and corner penalty. Just using the whole 2D-table unrolled, and the bonuses looked more disorganized, but they were there (diagonals were present, bonus for 6th rank for knight were explicit, but he later expressed them neatly with a vector etc.). I think that Fruit 2.1 and 1.0 were conceptually very related.
First of all, once you adopt a system, 0,1,2,3, it is likely that you will adopt the same for other tables. In fact, that is why Fabien re used them.
On the contrary, I would note he has three different "centralisation" tables,
-4 -2 0 1 (for knights),
-3 -1 0 1 (for kings/queens/bishops, and pawn files), and
-2 -1 0 1 for rooks. If he had used the same
-3 -1 0 1 throughout, I might conclude differently. Rybka happens to diverge from the "mainstream" case at the same junctures (R/N) that Fabien did, and in the same way. My understanding of copyright law is that is exactly the sort of nuance that is distinctive of a work, particularly when considering an overall pattern/picture.
To place all those in the same terms,
[-4 -2 0 1] is the same if we used a 2x multiplier to [-2 -1 0 0.5] lets dissect what all they mean
Vector = [ramp] + [normalization] + [edge penalty]
[-2 -1 0 0.5] = [0,1,2,3] + [-2,-2,-2,-2] +
[ 0,0,0,-0.5]
[-2 -1 0 1] = [0,1,2,3] + [-2,-2,-2,-2] +
[0,0,0,0]
[-3 -1 0 1] = [0,1,2,3] + [-2,-2,-2,-2] +
[-1,0,0,0]
The only real difference between them is a minor tweaking on the edge penalties. The knight one flattens the center. That would be needed if you increase the multiplier and the slope is too big (as it is).
My point, which is the core of our disagreement, is that I do not consider these set of four numbers, in which the one you can really vary are the edges, an issue for rule #2. I do not see this is distinctive.
In addition, I do not agree there are so many "distinct" possibilities. For instance, -3,-1,0,1 is the same as -6,-2,0,1 (you change later a multiplier) and basically the same as 0,2,3,4 (add a constant a the end) etc
My guess is the first should be
-6,-2,0,2. I would say the list of "obvious" transforms ends there (scaling and adding), so what is in your "etc" besides their combination? If you note, I carefully ensured that none of mine were equivalent under such affine linear transformations, though all were (unlike CW's example) giving some criterion for centralisation.
[-4,-1,0,1] [-3,-1,0,1] [-2,1,0,1] [0,0,2,3] [-4,-2,0,3]
Yes, that was a mistake. it is -6,-2,0,2
etc did not mean more than "something else it does not occur to me now."
Fruit uses [-1,0,0,0], you propose one option that is [0,0,0,0] and another that is [-2,0,0,0], and third one that changes both ends [+2,0,0,-1] (multiplying the ramp previously by 2) but it looks a bit less reasonable. We really do not have millions of options. Most CC programmers will chose numbers really close to each other.
The point is: computer chess programmers
do have
some options (~3 here, for just this one choice), and that the numbers for F/R are not "really close", but precisely the same in too many cases, and in distinctive ways. As above, I don't think this is untypical for the sort of commonalities in copyright/originality/plagiarism when there is a general store of knowledge. A relevant case law
quotation:
[...] the transgression in its unauthorized appropriation is not to be neutralized on the plea that 'it is such a little one'.
It is not the point that it little or big. My point is that it is not unique (extremely low information content). There are many things that could fall under fair use, too, particularly if it is acknowledged (we know VR studied the code and admitted it). If you learn something and apply it in your own way, it is difficult to rebut fair use. Anyway, I am not interested in the least in the legal matters. If the law says that copying a small set of numbers is illegal, then so be it, and hang VR. But let's make sure that the law takes into account the real magnitude of the alledge copying. Which was not hundreds of numbers like Bob wanted everybody to believe.
Miguel
[I personally don't think the ICGA should aim to become a generic "sanctioning body" for rules/guidelines in computer chess, but rather each tourney and/or testing group should follow what they feel best -- no matter what is decided, it does (of course) fall on the authors to be upfront about their engine origins].