What do you folks make of this ?

[BB+]

Needless to say, I do not accept your statistics about ordering of functions. Technically you may be correct, but in terms of interdependency and human behaviours, you are not.

I tend to agree with this. For instance, maybe some guide like "How Computers Play Chess" used one ordering, and many others simply imitate it. A similar case could be Zobrist keys: more than one person might have decided to use some algorithm from Knuth or Marsaglia to get a bunch of random numbers (there is still some question of how to order them, though).

OTOH, in some of these cases, it becomes the responsibility of the accused to point something like this out (for instance, maybe the nine File/Rank/Line arrays were mentioned by Programmer X in a 2003 email exchange with VR, while Fabien met the same X in Massy later that year, and they also discussed PST weights) -- we seem to have entered a strange world where an accuser is supposed to consider every possible affirmative defense the (silent) accused might make, and then build a case that still remains irrefragable. In some cases, this could be wise (for instance, if the person has left the chess world -- I'd almost argue that the fact that Rybka 1.0 Beta is essentially obsolete makes most of this moot, though repeated insistences of relative guilt/innocence seem to ensure that this issue never dies), but here it typically devolves into various advocates inventing tendentious excuses/explanations for the accused, which don't exactly do anyone much good.

[BB+]

the nine File/Rank/Line arrays

This is not quite correct -- the KingRankOpening is set to zero in Rybka, so the presumed entries for the KingRank array are undetermined.

[BB+]

When I search the Rybka 1.0 executable for the above patterns they are NOT FOUND.

This is correct they are only used in building the PST table, and while the Fruit code to do this is in Fruit, it does not appear in Rybka. The only thing in the Rybka 1.0 executable is the final PST tables, which, as I say, is derived from the Fruit mechanism, in a way that somewhat exceeds the standard of merely ideas.

To wit, here's the place where the PST table starts in the executable:

Code: Select all

00249330   E1 FD 23 01  4B FF 61 00  00 00 00 00  B5 00 9F FF  ..#.K.a.........
00249340   B5 00 9F FF  00 00 00 00  4B FF 61 00  E1 FD 23 01  ........K.a...#.
00249350   E1 FD 23 01  4B FF 61 00  00 00 00 00  B5 00 9F FF  ..#.K.a.........
00249360   B5 00 9F FF  00 00 00 00  4B FF 61 00  E1 FD 23 01  ........K.a...#.
00249370   E1 FD 23 01  4B FF 61 00  00 00 00 00  B5 00 9F FF  ..#.K.a.........
00249380   B5 00 9F FF  00 00 00 00  4B FF 61 00  E1 FD 23 01  ........K.a...#.
00249390   E1 FD 23 01  4B FF 61 00  00 00 00 00  B5 00 9F FF  ..#.K.a.........
002493A0   B5 00 9F FF  00 00 00 00  4B FF 61 00  E1 FD 23 01  ........K.a...#.
002493B0   E1 FD 23 01  4B FF 61 00  00 00 00 00  FF 00 9F FF  ..#.K.a.........
002493C0   FF 00 9F FF  00 00 00 00  4B FF 61 00  E1 FD 23 01  ........K.a...#.
002493D0   E1 FD 23 01  4B FF 61 00  00 00 00 00  B5 00 9F FF  ..#.K.a.........
002493E0   B5 00 9F FF  00 00 00 00  4B FF 61 00  E1 FD 23 01  ........K.a...#.
002493F0   E1 FD 23 01  4B FF 61 00  00 00 00 00  B5 00 9F FF  ..#.K.a.........
00249400   B5 00 9F FF  00 00 00 00  4B FF 61 00  E1 FD 23 01  ........K.a...#.
00249410   E1 FD 23 01  4B FF 61 00  00 00 00 00  B5 00 9F FF  ..#.K.a.........
00249420   B5 00 9F FF  00 00 00 00  4B FF 61 00  E1 FD 23 01  ........K.a...#.
00249430   1F 02 DD FE  B5 00 9F FF  00 00 00 00  4B FF 61 00  ............K.a.
00249440   4B FF 61 00  00 00 00 00  B5 00 9F FF  1F 02 DD FE  K.a.............
00249450   1F 02 DD FE  B5 00 9F FF  00 00 00 00  4B FF 61 00  ............K.a.
00249460   4B FF 61 00  00 00 00 00  B5 00 9F FF  1F 02 DD FE  K.a.............
00249470   1F 02 DD FE  B5 00 9F FF  00 00 00 00  4B FF 61 00  ............K.a.
00249480   4B FF 61 00  00 00 00 00  B5 00 9F FF  1F 02 DD FE  K.a.............
00249490   1F 02 DD FE  B5 00 9F FF  00 00 00 00  01 FF 61 00  ..............a.
002494A0   01 FF 61 00  00 00 00 00  B5 00 9F FF  1F 02 DD FE  ..a.............
002494B0   1F 02 DD FE  B5 00 9F FF  00 00 00 00  4B FF 61 00  ............K.a.
002494C0   4B FF 61 00  00 00 00 00  B5 00 9F FF  1F 02 DD FE  K.a.............
002494D0   1F 02 DD FE  B5 00 9F FF  00 00 00 00  4B FF 61 00  ............K.a.
002494E0   4B FF 61 00  00 00 00 00  B5 00 9F FF  1F 02 DD FE  K.a.............
002494F0   1F 02 DD FE  B5 00 9F FF  00 00 00 00  4B FF 61 00  ............K.a.

Or in gdb:

Code: Select all

0x649330:	-543	291	-181	97	0	0	181	-97
0x649340:	181	-97	0	0	-181	97	-543	291
0x649350:	-543	291	-181	97	0	0	181	-97
0x649360:	181	-97	0	0	-181	97	-543	291
0x649370:	-543	291	-181	97	0	0	181	-97
0x649380:	181	-97	0	0	-181	97	-543	291
0x649390:	-543	291	-181	97	0	0	181	-97
0x6493a0:	181	-97	0	0	-181	97	-543	291
0x6493b0:	-543	291	-181	97	0	0	255	-97
0x6493c0:	255	-97	0	0	-181	97	-543	291
0x6493d0:	-543	291	-181	97	0	0	181	-97
0x6493e0:	181	-97	0	0	-181	97	-543	291
0x6493f0:	-543	291	-181	97	0	0	181	-97
0x649400:	181	-97	0	0	-181	97	-543	291
0x649410:	-543	291	-181	97	0	0	181	-97
0x649420:	181	-97	0	0	-181	97	-543	291

So what do these mean? They are the white pawn values, the opening value, then the ending value.

Perhaps I can explain better with a different diagram. Let's switch to knights, as central pawns have a few variations.

Code: Select all

(gdb) x/128hd 0x649530
0x649530:	-3492	-448	-2798	-336	-2104	-224	-1757	-168
0x649540:	-1757	-168	-2104	-224	-2798	-336	-3492	-448
0x649550:	-2440	-336	-1746	-224	-1052	-112	-705	-56
0x649560:	-705	-56	-1052	-112	-1746	-224	-2440	-336
0x649570:	-1388	-224	-694	-112	0	0	347	56
0x649580:	347	56	0	0	-694	-112	-1388	-224
0x649590:	-683	-168	11	-56	705	56	1052	112
0x6495a0:	1052	112	705	56	11	-56	-683	-168
0x6495b0:	-325	-168	369	-56	1063	56	1410	112
0x6495c0:	1410	112	1063	56	369	-56	-325	-168
0x6495d0:	-314	-224	380	-112	1074	0	1421	56
0x6495e0:	1421	56	1074	0	380	-112	-314	-224
0x6495f0:	-1366	-336	-672	-224	22	-112	369	-56
0x649600:	369	-56	22	-112	-672	-224	-1366	-336
0x649610:	-5618	-448	-1724	-336	-1030	-224	-683	-168
0x649620:	-683	-168	-1030	-224	-1724	-336	-5618	-448

Here is a different picture of the same PST values for the openings, and I inverted it so that rank 8 is at the top:

Code: Select all

  -5618 -1724 -1030  -683  -683 -1030 -1724 -5618
  -1366  -672    22   369   369    22  -672 -1366
   -314   380  1074  1421  1421  1074   380  -314
   -325   369  1063  1410  1410  1063   369  -325
   -683    11   705  1052  1052   705    11  -683
  -1388  -694     0   347   347    0   -694 -1388
  -2440 -1746 -1052  -705  -705 -1052 -1746 -2440
  -3492 -2798 -2104 -1757 -1757 -2104 -2798 -3492

The interest for comparison with Rybka is when we make a formulaic representation (I omit the left/right symmetry):

Code: Select all

    -4x-4x+y-C   -4x-2x+y    -4x+0+y   -4x+x+y     ...
    -2x-4x+2y    -2x-2x+2y   -2x+0+3y  -2x+x+3y
      0-4x+3y      0-2x+3y     0+0+3y    0+x+3y
      x-4x+2y      x-2x+2y     x+0+2y    x+x+2y
      x-4x+y       x-2x+y      x+0+y     x+x+y
      0-4x+0       0-2x+0      0+0+0     0+x+0
    -2x-4x-y     -2x-2x-y    -2x+0-y   -2x+x-y
    -4x-4x-2y    -4x-2x-2y   -4x+0-2y  -4x+x-2y

Plug in x=5, y=5, C=100 for Fruit, and x=347, y=358, C=3200 for Rybka (with b8: -4x-2x+y = -1724 gives the above value).
The main evidence here is that all the numbers in the above array are exactly the same -- if you merely described the idea of File/Rank/Line centralisation for PST, there is no reason to choose the exact values

Code: Select all

static const int KnightLine[8] = { -4, -2, +0, +1, +1, +0, -2, -4 };
static const int KnightRank[8] = { -2, -1, +0, +1, +2, +3, +2, +1 };

as the specific values. This match of the underlying File/Line/Rank array occurs for every piece. As I say, this is not "code" per se, but it seems to pass beyond what would typically be considered "completely original" for the purposes of entries in chess competitions.

I realise that the forum software is not the best way to present this, so maybe I should make a brief PDF.

[hyatt]

Needless to say, I do not accept your statistics about ordering of functions. Technically you may be correct, but in terms of interdependency and human behaviours, you are not.

I tend to agree with this. For instance, maybe some guide like "How Computers Play Chess" used one ordering, and many others simply imitate it. A similar case could be Zobrist keys: more than one person might have decided to use some algorithm from Knuth or Marsaglia to get a bunch of random numbers (there is still some question of how to order them, though).

I don't agree with this based on one issue, I have looked at the source for several chess engines that are available, and they simply don't do the same things in the same order using the same approach, which is what Chris/I were discussing. Hard to compare code between a bitboard and mailbox board representation, but one can look at A and make a very good determination about whether B came from A or is original.

OTOH, in some of these cases, it becomes the responsibility of the accused to point something like this out (for instance, maybe the nine File/Rank/Line arrays were mentioned by Programmer X in a 2003 email exchange with VR, while Fabien met the same X in Massy later that year, and they also discussed PST weights) -- we seem to have entered a strange world where an accuser is supposed to consider every possible affirmative defense the (silent) accused might make, and then build a case that still remains irrefragable. In some cases, this could be wise (for instance, if the person has left the chess world -- I'd almost argue that the fact that Rybka 1.0 Beta is essentially obsolete makes most of this moot, though repeated insistences of relative guilt/innocence seem to ensure that this issue never dies), but here it typically devolves into various advocates inventing tendentious excuses/explanations for the accused, which don't exactly do anyone much good.

[BB+]

I had forgotten what had happened in Sega vs Accolade. There are many interesting twists (and those interested should read the decision), but perhaps the most relevant for any discussion here is:

Code: Select all

To oversimplify, the record establishes that Accolade, a commercial competitor of Sega, engaged in wholesale copying of Sega’s copyrighted code as a preliminary step in the development of a competing product. However, the key to this case is that we are dealing with computer software, a relatively unexplored area in the world of copyright law. ... Sega argues that the considerable time, effort, and money that went into development of the Genesis and Genesis-compatible video games militate against a finding of fair use. Borrowing from antitrust principles, Sega attempts to label Accolade a “free rider” on its product development efforts. In Feist Publications, however, the Court unequivocally rejected the “sweat of the brow” rationale for copyright protection. 111 S. Ct. at 1290-95 .Under the Copyright Act, if a work is largely functional, it receives only weak protection. “This result is neither unfair nor unfortunate. It is the means by which copyright advances the progress of science and art."

And perhaps (for the re-use of UCI code):

Code: Select all

The question whether a product feature is functional is a question of fact. Inwood Laboratories, Inc. v. Ives Laboratories, Inc., 456 U.S. 844, 855 [214 USPQ 1] (1982). Determination of the correct legal standard to apply in evaluating functionality, however, <977 F.2d 1531> is a question of law which we review de novo.Id. at 855 n.15 . The burden of proving nonfunctionality is on Sega. See Rachel v. Banana Republic, Inc.,831 F.2d 1503, 1506 [4 USPQ2d 1877] (9th Cir. 1987). In the case before us, we conclude that the district court’s finding of nonfunctionality was based on its use of an incorrect legal standard.

Cited (footnote 9) is the Galoob/Nintendo case which found (essentially) that computer games are published works for purposes of copyright:

Code: Select all

Sega argues that its programs are unpublished works and that therefore, under Harper & Row, the second statutory factor weighs in its favor. 471 U.S. at 553-55 .Recently, however, this court affirmed a district court holding that computer game cartridges that are held out to the public for sale are published works for purposes of copyright.

[Rebel]

I realise that the forum software is not the best way to present this, so maybe I should make a brief PDF.

No need for me, it's clear enough. There is another aspect on the issue, namely Strelka. Vas claimed Strelka of his own while the PST issue we currently are discussing is exactly the same in Fruit and Strelka. That's a lot of contingency.

Reading Zach (and you) it gives the impression VR storing the entire pre-calculated PST in the executable with the intention to obfuscate. I am not aware if a compiler can do such a thing (by a macro or so), can it? If not one needs a special utility. And why would anyone do such a thing. For the moment I can't imagine any other reason than to obfuscate. And if it's done by an utility there must be some code in Rybka 1.0 to find the location of the pre-calculated PST. Perhaps it is loaded from the executable?

One more thing that interests me, bishop-underpromotion, a dissimilarity for a change

1n4b1/PP6/6p1/4p1p1/p5P1/3p2PK/3P4/7k w - -

Fruit immediately sees the draw with 1.a8B, Rybka 1.0 fails miserably. This bug relieves Vas somewhat. What I don't understand having read the bishop-underpromotion at the Rybka forum why Vas is so stubborn not fixing this. If I have understand correct Rybka 4 (which I don't have) still fails here.

Ed

[Rebel]

I had forgotten what had happened in Sega vs Accolade. There are many interesting twists (and those interested should read the decision), but perhaps the most relevant for any discussion here is:

While the court ruled in favor for Accolade they did the opposite in the Microsoft vs Stacker case. Microsoft had to pay Stacker 120 million dollars, or so.

I had the following in the REBEL manuals:

Code: Select all

 COPYRIGHT
The REBEL 6.0 software is the exclusive property of Schröder BV and is protected by Dutch and International law. You are prohibited from transferring this product in any way or form whatsoever. It is forbidden to change, split, disassemble or produce any changed form of this product.

I added this because I knew there were hackers around. I am not sure if this would hold up in court. A producer can put anything in their stipulations, it doesn't mean a thing. If stipulations are against the law or even sound unreasonable to a judge he/she will erase the stipulation.

Ed

[zwegner]

I realise that the forum software is not the best way to present this, so maybe I should make a brief PDF.

No need for me, it's clear enough. There is another aspect on the issue, namely Strelka. Vas claimed Strelka of his own while the PST issue we currently are discussing is exactly the same in Fruit and Strelka. That's a lot of contingency.

Reading Zach (and you) it gives the impression VR storing the entire pre-calculated PST in the executable with the intention to obfuscate. I am not aware if a compiler can do such a thing (by a macro or so), can it? If not one needs a special utility. And why would anyone do such a thing. For the moment I can't imagine any other reason than to obfuscate. And if it's done by an utility there must be some code in Rybka 1.0 to find the location of the pre-calculated PST. Perhaps it is loaded from the executable?

Vas said that it's just some offline code, that spits out a C file: static const int PST[12][64][2] = {...}; I don't really consider it obfuscation, but it is somewhat "convenient"--and it also makes the legal aspect a bit more blurry.

From various statements Vas has made it seems that the entire Rybka engine is now produced in this way (autogenerated).

One more thing that interests me, bishop-underpromotion, a dissimilarity for a change

1n4b1/PP6/6p1/4p1p1/p5P1/3p2PK/3P4/7k w - -

Fruit immediately sees the draw with 1.a8B, Rybka 1.0 fails miserably. This bug relieves Vas somewhat. What I don't understand having read the bishop-underpromotion at the Rybka forum why Vas is so stubborn not fixing this. If I have understand correct Rybka 4 (which I don't have) still fails here.

Ed

Yes, Rybka 1 only had queen promotions, no underpromotions.

[hyatt]

I had forgotten what had happened in Sega vs Accolade. There are many interesting twists (and those interested should read the decision), but perhaps the most relevant for any discussion here is:

While the court ruled in favor for Accolade they did the opposite in the Microsoft vs Stacker case. Microsoft had to pay Stacker 120 million dollars, or so.

I had the following in the REBEL manuals:

Code: Select all

 COPYRIGHT
The REBEL 6.0 software is the exclusive property of Schröder BV and is protected by Dutch and International law. You are prohibited from transferring this product in any way or form whatsoever. It is forbidden to change, split, disassemble or produce any changed form of this product.

I added this because I knew there were hackers around. I am not sure if this would hold up in court. A producer can put anything in their stipulations, it doesn't mean a thing. If stipulations are against the law or even sound unreasonable to a judge he/she will erase the stipulation.

Ed

Just for the record, you can't prevent anyone from disassembling the code. You might make a case if they distributed the disassembled product, but no way you can stop them from looking. Since there is no possible way to detect this, it would be considered "unenforcable".

[Rebel]

Vas said that it's just some offline code, that spits out a C file: static const int PST[12][64][2] = {...}; I don't really consider it obfuscation, but it is somewhat "convenient"--and it also makes the legal aspect a bit more blurry.

Well, I once did myself this kind of circuitous programming. There was only one intention, hide the tournament book in the executable so that competitors could not focus on it so easily any longer. There are no programming advantages, in fact the technique is a royal pain.

Ed