Not logged inRybka Chess Community Forum
Up Topic Rybka Support & Discussion / Rybka Support / Minority Report 3, PST + other lookup tables are they legal?
1 2 Previous Next  
- - By Ugh (*****) Date 2011-07-25 10:42
Vas: Re. Fruit and Rybka: The Rybka source code is original. I did take a lot of things from Fruit, but legally.

How would or could Vas do that? Take things legally?

Let's consider Hyatt-Crafty ....

you can do what you want with open source in your own lab subject to non distribution/no tournaments/no other people bla bla

you can take Crafty and ask it for a chess move. It says e4. Who "owns" the e4, certainly not Hyatt-Crafty, he has copyright on the code but not on the output

you can take crafty, rip out some black box component of its source that has, say N inputs and a few outputs - wrap some code round it and give it an input, the code segment says 42. Hyatt-Crafty doesn't own that output either. Ask again, different input - another output, you get the idea.

Crafty doesn't own the output order either, because you control that with your question order.

You take all the outputs, giant lookup table, or memory as the end users will understand better. Who owns the memory? Not Crafty-Hyatt.

Not one unlawful or unacceptable step so far. You have just taken advantage of the dumb open source licence.

Finally the memory goes into your program, for use at will. There's no code, there's no copyright material, arguably you own the memory because who else does?

Add to that, in the case of the PST's, Vas used different weights, different kludges and either his own code or his own code with some Fruit ideas, unprovable either way. Everything is even more different.

In practice, Vas has done it perfectly legally, he extracted the IDEA, or more accurately a Vas-modified version of the idea without any "copying" at all. The idea is now wrapped up in a completely different form without recourse to the cut and paste alleged by Hyatt.

And, as we know, IDEAS are not protected and the Vas sentence "The Rybka source code is original. I did take a lot of things from Fruit, but legally." is validated.
Parent - - By h.g.muller (****) Date 2011-07-26 08:41
So what is you point? That reverse engineering is not a copyrights infringement? Isn't that "battering down an open door"?

But no matter how you do it, if you build something that has exactly the same input-output characteristics as Crafty, it still would violate the originality requirement of ICGA.
Parent - By Uly (Gold) Date 2011-07-26 10:03

> if you build something that has exactly the same input-output characteristics as Crafty, it still would violate the originality requirement of ICGA.


But Rybka 1.6.1 was not entered into an ICGA tournament.
Parent - - By Ugh (*****) Date 2011-07-26 10:31
The source code is open and already there in the example above. There is no "reverse engineering", so I am not sure what is your point?!

My "point" is that it is possible to acquire the idea/knowledge expressed in a program or a sub function of an open source program by interrogation, obtaining outputs (which are not copyrightable) and

a) saving those outputs in a lookup table
b) training a neuralnet on the input/outputs

in these cases we have grabbed the "idea" without use of "copy". Hyatt is continually claiming "copy", so I am pointing out it is possible for Vas to legally (his word) get ideas without recourse to "copy". And I think this could be a part basis of the Vas claim that he went through Fruit taking many things, but legally.

Then, on your originality concept, and here you begin to engage on an interesting conundrum, lets suppose Crafty is not a chess program, but an algorithmic program of a simpler game, one in which the number of input positions is manageable enough for neural net or lookup table. Then suppose someone makes a product, based on neural net or lookup table which has extracted the (copyright free) outputs of simple-game-Crafty.

Is this product legal? Original? Violating anything?

I ask because I am not that sure enough to make dogmatic assertions on the subject. If the lookup version plays the "same moves" then icga have a clause in the rules to cover that, so, let's suppose, simple-game-Crafty open source is modified by changing weights, adding/changing algorithmic features etc etc, with result of not-same-moves in the lookup table version .....

.... same questions of legality etc again .... we have captured(without copy) a modified version of the idea and expressed it differently

Is this product legal? Original? Violating anything?

What is the essential difference between this product and, say, an opening book?
Parent - - By h.g.muller (****) Date 2011-07-26 15:11
This is simply a well-known form of reverse engineering. Whether it is legal or not, depends on the license agreement. If the agreement forbids reverse engineering, it would be illegal, except when you do it for learning the interface to connect your own stuff to it. For this application (and this application alone) law pevails over any license agreement, and it would be legal to do it even if the license agreement forbids it. (A so called unlawful condition, which is void.)

But I release a Chess engine under a license that forbids reverse engineering, and you would apply your method to extract my piece-square table, piece values, extensions and  reductions, and then write your own program using those same tables, reductions and extensions, and release it as a competing Chess engine, this would be illegal, and punishable by law.

Of course neither the Fruit nor the Crafty license forbid this kind of RE. Because you would be stupid to do it, when the source code is available, and it is so much easier to read through that than to extract the PST values through probing the I/O characteristics.
Parent - By Ugh (*****) Date 2011-07-26 20:58
I agree much easier, but I was looking for a way to validate the Vas statement: "I took many things from Rybka, but legally", and interrogation of output appears to be a way to do that. That's all.
Parent - - By bob (Gold) Date 2011-07-26 15:17
Ideas are not protected under copyright.  Numbers are not protected under copyright.  However, tables of numbers are, when the effort to create them is significant.  US copyright law has already weighed in on that.  A common chess example is that you can not copyright a game, but you can copyright a group of games, when it requires effort to collect the games (such as the 100 greatest games of Bobby Fischer, etc.)  To produce a table of values used to produce the basic positional estimation for any piece on any square certainly requires a _lot_ of effort to get it right.  My values, for example, are the results of tens of thousands of hours of computer time running tests with different values, and then many hours of _my_ time analyzing the results to zero in on close to optimal values.  So no, you can't just rip those out and say "you can't copyright numbers" because you definitely can.

In the case of Crafty, he did _not_ copy ideas.  He copied actual code.  Code he could _never_ have written by himself, because there was code that he could not possibly need, nor would he have had any possible reason to write it since the issue that code addressed was resolved 10 years before he "wrote" his code.  So, with respect to Crafty, none of that flies.  He copied Crafty 19.x plain and simple.

For the Rybka 1.0 beta / Fruit comparison, I think Zach's and Mark's writeups are quite clear.  Zach's gives side-by-side analysis of blocks of code showing how they are either (a) identical or (b) do the same things in the same order with the same numbers.  That can't be hand-waved away as "he studied the ideas and then wrote his own code."  That is an impossibly weak argument with near-impossibly unlikely probability of it being what happened.  You'd be _far_ better off spending your life savings on lottery tickets.
Parent - - By Mec (*) Date 2011-07-26 17:56 Edited 2011-07-26 18:52

>> Numbers are not protected under copyright.
>> (*) However, tables of numbers are, when the effort to create them is significant.


Yeah I've got a great idea, from now on I'll work on a major file of useless C-source code, which will contain nothing else but several thousands of array[64] definitions.

I'll make sure that I'll fill these tables with every possible permutation of several different sequences of numbers.

The effort to create them (the tables) will certainly be significant (several thousands!)

At the end of the day my C-source code will contain nothing else but several thousands of array[64] / table- definitions, and hence I'll be the copyright owner of almost every possible combination of arbitrary numbers (according to your statements).

And then I'll publish my ingenious (but totally useless) piece of C source code under whatever copyright conditions I want (I'm the author, after all, right? So this should grant me the right to demand whatever I want from programmers, who wanna use a certain table of numbers which - unluckily for them -  I have authored before them due to my useless C-Source Code of 100.000 array[64] definitions, right?

... Certainly I could demand that they must perform a handstand and post a video on youtube (as a proof), before they have my permission to use a specific combination of 64 numbers in their closed source programs.

Well, they simply were unlucky enough to come up with the same numbers (even if they did so -independently, and most likely didn't even know about my useless C-Source Code, it's only because chances were really high that I 'invented' them before they did,

no matter how useless my program of 100.000 array[64] definitions might be ...)

So this should certainly grant me at least partial copyrights for utmost every chess program that might be written in the future and which wants to use PST in some way.

Chess programmers of the future! Be warned to train handstands before you plan to use a PST in your closed source program!

Chances are very high, that my totally useless C-program with its several thousands of arbitrary array[64] definitions already contains that very specific combination of numbers you wanna use.

Woe if I come to learn about your closed source program due to (illegal) decompilation, and I detect MY table[64] somewhere in the disassembly (now what a surprise, if you consider just HOW MANY useless array[64] definition my ORIGINAL source code contained , isn't it?)!

I'll drag you to a court and won't stop whining about your infamous copyright infridgement before you're sentenced to do that damn handstand I wanted every re-user of MY IDEA (remember: 100.000 useless array[64] definitions) to perform!

If only they had complied to my foolish conditions in the first place ...

Well, Dear Prof. Hyatt,

if tables of numbers really were protectable under copyright, my ingenious (foolish!) idea should certainly grant me a partial copyright for most chess programs of the future which wanna make use of that plain old (imo outdated) idea of PSTs in Eval.

Certainly the effort of 'creating' my 'originial' source code (which has the only purpose of preempting the use of almost every possible & reasonable combination of PST values) is significant.

So my foolish idea should definitely work (according to your peculiar perceptions about Copyright Law.)

I hope you're humorous so now you can laugh at your own statements:

>> Numbers are not protected under copyright.
>> (*) However, :lol: tables of numbers are :lol:, when the effort to create them is significant.


Regards
Mec
Parent - - By Ugh (*****) Date 2011-07-26 18:12
Mec,

funny!

another one for you, this is apparently, according to Zach, the important table that all the Fruit PSTs are based on, and, it is alleged to have been used by Vas to create the pre-loaded Rybka PSTs ...

Mark Lefler, in a reply to Trotsky wrote: Your scaling comment is not correct.  For example, both programs use the same scaling for piece square tables for all of the pieces:

static const int PawnFile[8] = { -3, -1, +0, +1, +1, +0, -1, -3 };
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 };
static const int BishopLine[8] = { -3, -1, +0, +1, +1, +0, -1, -3 };
static const int RookFile[8] = { -2, -1, +0, +1, +1, +0, -1, -2 };
static const int QueenLine[8] = { -3, -1, +0, +1, +1, +0, -1, -3 };
static const int KingLine[8] = { -3, -1, +0, +1, +1, +0, -1, -3 };
static const int KingFile[8] = { +3, +4, +2, +0, +0, +2, +4, +3 };
static const int KingRank[8] = { +1, +0, -2, -3, -4, -5, -6, -7 };


your're a programmer, much better one than me, but how do we both know this table is completely untuned, was knocked out by hand and represents practically no work at all, it's just the same old PST base guidance used by all programmers for the last 40 years?

And, therefore the PST tables in Fruit (and Rybka) are basically untuned, for program guidance only, contrary to Hyatt assertion that his PSTs are tuned by 100s of 1000s of games and countless hours of machine time and countless hours of his time analysing the results?
Parent - - By bob (Gold) Date 2011-07-26 18:39
You might try less speculation, might have beens, and is remotely possibles, and instead try factual arguments that are based on reality not fantasy and imagination.  That will get you much further in the world of credibility.

I wonder why there is no such agreement with the PSTs of _other_ programs???  If it is so easy to come up with them.  All have a "trend" that center is good, edge is bad, but the values, after adjusting to pawn=100 are not the same for others.  So why do you think it happened in this case.  Your favorite explanation, "serendipity"???
Parent - - By Ugh (*****) Date 2011-07-26 18:52
It is getting increasingly difficult to see where any of your presumed input transducers actually connect to your processing code. Unlike the output transducers which are all on auto-repeat at full volume. Recompile? I can make the adjustments if you like. I could write you an empathy subroutine, useful for your evaluation function.

All has been already explained, you just need to READ and THINK and UNDERSTAND. Now, go away and do your homework and come back and we can perhaps COMMUNICATE, you know, that two-way process that requires a bit of give and take and thinking about what the other person might mean. Difficult, but you might learn something.
Parent - - By bob (Gold) Date 2011-07-26 19:23
I would give you _exactly_ the same advice.  Go away.  read Zach's stuff.  Read Mark's stuff.  Think about it.  Then _stop_ saying there is no identical code.  You just have to look at the reports.  Side-by-side comparisons.  It doesn't get any simpler than that, if you just open your eyes and stop spouting all this nonsense and personal stuff...

If you can do that, of course...
Parent - - By Ugh (*****) Date 2011-07-26 19:33
OK, I'll go away and reread the first few pages of Zach's report, the one with all the side by side "identical" code. You remember you advised that earlier today or might have been yesterday, just to look at the first page and see the side by side identical code?

.......
.......
.......
.......
.......
Parent - - By bob (Gold) Date 2011-07-26 19:58
This is a PDF link:  http://icga.wikispaces.com/file/view/ZW_Rybka_Fruit.pdf.  Page one is introduction.  Page 2 has piece square tables _and_ some side-by-side code.  The next several pages _all_ have "side-by-side code analysis."  Did you just read the "introduction" and quit?  that would explain a lot...

I didn't know it was _that_ hard to find it...
Parent - - By Ugh (*****) Date 2011-07-26 20:09
actually you mean this one ....

each page logged as: https://webspace.utexas.edu/zzw57/rtc/eval/eval.html[2/5/2010 1:22:36 AM

and available from this site http://www.chessvibes.com/plaatjes/rybkaevidence/ZW_Rybka_Fruit.pdf

I can't read the link you provide, of course, don't forget you banned me from the wiki process, and your shown page is a hidden file, only accessable to passworded people who got past the Hyatt gatekeeper process.

Page Not Found
We can't find the page you are looking for. Usually this means you have clicked on a link that no longer goes anywhere; try searching for the information you're looking for in the search box.
If you need help, please contact help@wikispaces.com. Or you can visit our help area for more information.


Anyhows, I read it in detail via another site, many days ago already .....
Parent - - By bob (Gold) Date 2011-07-26 20:21
Then why did you have problems finding the side-by-side that you have continually said was not done?  I can attach the pdf here or put it on my ftp box if needed...  It is not a private document...
Parent - - By Ugh (*****) Date 2011-07-26 20:26
Can you read and understand. Here it is caps lock, just to emphasise ...

I CANT READ STUFF ON THE WIKI BECAUSE YOU BANNED ME FROM THE PROCESS

I CAN READ STUFF THAT HAS BEEN POSTED ELSEWHERE

IN THE CASE OF THE DOCUMENT YOU FLAGGED UP AS This is a PDF link:  http://icga.wikispaces.com/file/view/ZW_Rybka_Fruit.pdf I CAN'T SEE IT

BUT WHAT I ASSUME IS AN IDENTICAL COPY IS AVAILABLE AT http://www.chessvibes.com/plaatjes/rybkaevidence/ZW_Rybka_Fruit.pdf WHERE I CAN READ IT AND DID DO SEVERAL DAYS AGO

Understand now? All you have to do is read and think and work out what the writer is saying/meaning, it is not too difficult is it?
Parent - - By Watchman (***) Date 2011-07-26 20:32

>IN THE CASE OF THE DOCUMENT YOU FLAGGED UP AS This is a PDF link:  http://icga.wikispaces.com/file/view/ZW_Rybka_Fruit.pdf I CAN'T SEE IT


Well figure out how to use your browser Chris as I just clicked on that link and got the .pdf.

:confused:

Edit:

"Chris cannot be Jedi Panel Investigator... he is too impatient."
Parent - - By Harvey Williamson (*****) Date 2011-07-26 20:33 Edited 2011-07-26 20:36
Wow Rob afaik you are not a member of the panel?

Seems this is available to all :)
Parent - By Watchman (***) Date 2011-07-26 20:35
not unless my dive into the Rybka "pit of despair" (a mild term) has given me honorary access.

:eek:
Parent - By Watchman (***) Date 2011-07-26 20:42

>BUT WHAT I ASSUME IS AN IDENTICAL COPY IS AVAILABLE AT http://www.chessvibes.com/plaatjes/rybkaevidence/ZW_Rybka_Fruit.pdf WHERE I CAN READ IT AND DID DO SEVERAL DAYS AGO


"That's not the report you're looking for..."

>That's not the report I'm looking for...


"You want to go home and rethink your life..."

>I want to go home and rethink my life...

Parent - - By Ugh (*****) Date 2011-07-26 21:01
the problem appears to be that your punctuation was excellent, except that putting a full stop (USA period) at the end of the sentence also put it at the end of the link and broke it.

I am restricted from reading the wiki though, some things are visible in general and some things not. Is there any reason, for example, that we humble outsiders and banned people can't now read the wiki forum deliberations and comments now that the process in the wiki is presumably complete?
Parent - - By Harvey Williamson (*****) Date 2011-07-26 21:12
We made about 90% of the Wiki public after the ICGA ruling was published.
Parent - - By Ugh (*****) Date 2011-07-26 21:22
the other 10% would appear to be the wiki discussion forum, we know there were many discussions about Rybka, Vas, the attack verdict and so on. Why can't we humble banned ones and general masses of non-panel people read them?
Parent - - By bob (Gold) Date 2011-07-26 22:31
Because some wanted to make their deliberations private, just as is done in all jury trials in a regular court.  Public comments often lead to public attacks.  Just read the nonsense addressed toward me here...  as but one example.
Parent - - By George Speight (***) Date 2011-07-28 09:37
You are wrong Bob, and I don't understand why you lie about him attacking you. He was attacking the panel procedure. You have just honored yourself to speak for them all. You are the only one who seems scared to death about his credibility. Ask some of the panel to come help you now. Dont hold your breath. You are the ONLY ONE WHO HAS TAKEN THIS TO MEAN LIFE AND DEATH. So stick to the truth. I hope the panel did not operate as you do here.
Parent - By bob (Gold) Date 2011-07-28 20:09
Take a breath and read replies to my posts.  I have been called everything from "pompous" to "jack-ass" to "liar" to "lynch-mob leader".

Not that those particularly matter, considering some of the sources, but it has happened frequently.
Parent - - By bob (Gold) Date 2011-07-26 22:28
Sorry.  I despise this self-correcting, self-punctuating crap.  The thing nags me to spell color as "colour".  behavior as "behaviour".  I often go along with it just to get past the nag stage,  It often screws up as a result.  :(
Parent - By Ugh (*****) Date 2011-07-26 22:37
Gosh! Your sorry is well taken Bob
Parent - - By Ugh (*****) Date 2011-07-26 20:35
Right, reread it, just to make sure. Link http://www.chessvibes.com/plaatjes/rybkaevidence/ZW_Rybka_Fruit.pdf

There are four pages of side by side source code concerning the PST tables, from page 2 onwards. The sources are very similar but not identical. One side is headed Fruit. The other side is headed Rybka.

Unfortunately for you though, the source code side marked Rybka contains fantasy code that is not in Rybka.

Zach sort of explains, although the casual reader, or those who don't think too much might be misled ...

Piece square tables are a very simple technique used for basic evaluation. For every piece type and square, PSTs
have a value for that piece being on that square. Fruit uses a clear and simple but effective way of calculating the
tables. Looking at Rybka's PSTs, we will see that they are calculated using these exact same constants except with
different weights. Also, note that here too that the PST values are hardcoded into the Rybka executable file, they are
not calculated at startup like Fruit's. The code shown here is simply the functional equivalent; it calculates the Rybka
PSTs.


The section "The code shown here is simply the functional equivalent" actually means "I, Zach, made up / invented / fantasised this source code 'labelled Rybka' with no object code to go by, because the code does not exist in Rybka".

The two sections of "identical code" shown are a fantasy because although the code does exist in Fruit, it does not exist in Rybka in any way, shape or form.  Four pages worth of "identical code".
Parent - - By bob (Gold) Date 2011-07-26 22:29
Keep reading beyond the PST stuff then.  Look at individual piece evaluation code...
Parent - - By Nelson Hernandez (Gold) Date 2011-07-26 23:19
WHOA!!  You just dismissed a critical piece of your case!!  Don't tell me the whole basis of your argument isn't being undermined day by day!!
Parent - - By bob (Gold) Date 2011-07-27 03:28
Not at all.  He wants _code_ to compare, not PSTs.  I suppose this _is_ a bit over your head to follow?  The PST data is certainly convincing enough, but Chris specifically wanted to look at actual eval code, not the PST stuff.  It is there...

Nothing is being undermined nor effectively challenged at all, so far.

Just a lot of wild speculation trying to come up with some explanation that will exonerate Vas, no matter how improbable the explanations might be.
Parent - By Nelson Hernandez (Gold) Date 2011-07-27 12:01
I am fully able to read Chris's post and understand its importance.  Why aren't you able to see it?  Try re-reading a few times.
Parent - - By Ugh (*****) Date 2011-07-27 14:24
What exactly is so convincing about the PST table data? I don't see it. Looks deeply unconvincing to me.

You claim in Crafty to have spent 1000's of hours of machine time optimising your PST data and 1000's of hours of Hyatt time interpreting the results bla bla, so these are obviously pretty damn important tables loaded with creative data invested with copious quantities of Hyattian sweat and blood, right?

So what exactly is so convincing?
Parent - - By bob (Gold) Date 2011-07-27 16:16
What is so convincing?  384 numbers that are the same.  384 numbers, chosen one at a time out of a potential sample pool of 2^64 possible 64 bit integers.  The probability of one person choosing one number is 1/2^64.  The probability of two people choosing the same number is 1/2^128.  The probability of those two people choosing the same number foe each of the 384 slots is something like 1/2^(128 * 384) which is "right close to 0.00000000000000000.....000"

Yes, I do claim to have vetted every last number we have via cluster testing.  What does this have to do with copying, however, other than to show that in addition to the probability of copying issue, there is effort in putting together that collection of numbers which would seem to meet copyright standards...
Parent - - By Ugh (*****) Date 2011-07-27 17:52
"384 numbers that are the same"

One would assume here your 364 is derived from 6 x 64, six piece types and sixty-four squares on the board.

The 364 numbers cannot possibly be the same because the raw ramping pattern data was multiplied by wildly different weights for each program (according to Zach). Plus the ratio of the weights for each program was different too. Plus both programs overwrote and/or added to table values with different kludge weights. Plus Rybka has an extra table.

Several reason why the numbers are not the same

Stop with the dissembling or outright untruths as in this case.

btw, I found a cheat error in Zach's fantasy code of how he alleges the Rybka tables were generated.

Under the heading Fruit, Zach has this code: (Fruit is building two PST tables for the king, one for use in the opening and one for use in the ending)

static const int KingCentreEndgame = 12;
static const int KingFileOpening = 10;
static const int KingRankOpening = 10;
...
for (sq = 0; sq < 64; sq++) {
P(piece,sq,Endgame) +=
KingLine[square_file(sq)] *
KingCentreEndgame;
P(piece,sq,Endgame) +=
KingLine[square_rank(sq)] *
KingCentreEndgame;
}
for (sq = 0; sq < 64; sq++) {
P(piece,sq,Opening) +=
KingFile[square_file(sq)] *
KingFileOpening;
}
for (sq = 0; sq < 64; sq++) {
P(piece,sq,Opening) +=
KingRank[square_rank(sq)] *
KingRankOpening;
}


For Rybka he has created the following fantasy code:
static const int KingCentreEndgame = 401;
static const int KingFileOpening = 469;
static const int KingRankOpening = 0;
...
for (sq = 0; sq < 64; sq++) {
P(piece,sq,Endgame) +=
KingLine[square_file(sq)] *
KingCentreEndgame;
P(piece,sq,Endgame) +=
KingLine[square_rank(sq)] *
KingCentreEndgame;
}
for (sq = 0; sq < 64; sq++) {
P(piece,sq,Opening) +=
KingFile[square_file(sq)] *
KingFileOpening;
}
for (sq = 0; sq < 64; sq++) {
P(piece,sq,Opening) +=
KingRank[square_rank(sq)] *
KingRankOpening;

}


Which, apart from the weights, appears to be identical and therefore, for Zach, as damning as possible.
However, note the third weight declared in the Rybka fantasy code, I bolded it in the example.
static const int KingRankOpening = 0;

and note the Zach fantasy code segment, also bolded
for (sq = 0; sq < 64; sq++) {
P(piece,sq,Opening) +=
KingRank[square_rank(sq)] *
KingRankOpening;


for non-programmers, this piece of code is basically adding 0 (zero) 64 times into the PST for the king, opening game phase. Very funny. And totally purposeless.

I do not believe Vas would write code to add zero 64 times in Rybka.

I therefore charge you and Zach of deliberate manipulation of the fantasy source code (by addition of useless code that does nothing) to deliberately give a misleading impression that the Fruit source matches the fantasy Rybka source.
Parent - - By bob (Gold) Date 2011-07-27 17:57
No one expected you to get it.

However, if I choose 384 numbers, and you choose 384, and the _only_ difference is that either mine or yours are multiplied by a constant...

well, most would get that.

Shoot, many programs use fractional plies.  So even the depth is multiplied by a constant.  But I would hope _everyone_ realizes that when you look at old crafties and find a number like 16 (where crafty used ply = 4) and another program where you see a number like 256 (where that program uses ply=64) that the two depths, and therefore the two tests (if (depth >= 16) {do something}) are _identical_.  I get it...

Just as I understand that comparing numbers between two programs where one uses pawn = 100, and another uses pawn =3395 (or any number you choose) that the numbers can be the same after the scaling is removed.  I get it.
Parent - - By Nick (*****) Date 2011-07-27 18:23
static const int KingRankOpening = 0;

Good spot by Trotsky, any comment on this and the subsequent multiplication of it in the fantasy Rybka code?  Typo?
Parent - - By Ugh (*****) Date 2011-07-27 18:39
Nick, if you are a programmer, or if any other programmer would like to try, and you can do this on a piece of paper, it's quite quick ...

using Zach's code for generation of the PST, king, opening and using Zach's weights for each program

calculate the PST entry for the zeroth square (a1) and the next square (b1) for each program. Then tell us the "constant" multiplier that can be used to turn one table into the other .....
Parent - - By Nick (*****) Date 2011-07-27 19:22

>  if you are a programmer


Fortunately? I was promoted out of harms way and my job title has not had the word "programmer" in it since 1989 :grin:  However, I can program in a variety of different languages (even COBOL), but I know next to nothing about chess algorithms. 

> using Zach's code for generation of the PST, king, opening and using Zach's weights for each program


I'm willing to have a go, but may need some more guidance, is it correct to say the King PST, the opening PST?  Perhaps if you told me .. go to page X of the report and do Y that might help.  It might be easier for another programmer to pick it up?  But I'll have a go, it may take me some time.

> Then tell us the "constant" multiplier


My assessment of your use of inverted commas leads me to believe that there is no constant.
Parent - - By Ugh (*****) Date 2011-07-27 19:58
"My assessment of your use of inverted commas leads me to believe that there is no constant."

that would be believing without testing what you are being asked to believe ;-)

ok, here's the calculation .....

program segment is, and assuming table has been initialised to zero
for (sq = 0; sq < 64; sq++) {
P(piece,sq,Opening) +=
KingFile[square_file(sq)] *
KingFileOpening;
}
for (sq = 0; sq < 64; sq++) {
P(piece,sq,Opening) +=
KingRank[square_rank(sq)] *
KingRankOpening;


data arrays are
static const int KingFile[8] = { +3, +4, +2, +0, +0, +2, +4, +3 };
static const int KingRank[8] = { +1, +0, -2, -3, -4, -5, -6, -7 };


file and rank indeces
a1 = file 0, rank 0
b1 = file 1, rank 0

Fruit weights are
static const int KingFileOpening = 10;
static const int KingRankOpening = 10;


Rybka weights are
static const int KingFileOpening = 469;
static const int KingRankOpening = 0;


Fruit_PST_King_Opening[a1] = 3x10 + 1x10 = 40
Fruit_PST_King_Opening[b1] = 4x10 + 1x10 = 50

Rybka_PST_King_Opening[a1] = 3x469 + 1x0 = 1407
Rybka_PST_King_Opening[b1] = 4x469 + 1x0 = 1876

ratio rybka_fruit[a1] = 1407 / 40 = 35.175
ratio rybka_fruit[b1] = 1876 / 50 = 37.52

the multiplier ratio is NOT constant and will vary over all 64 board square entries
Parent - - By Nick (*****) Date 2011-07-28 12:01
I had a few minutes over lunch to knock something up in C#, I'm encouraged that my first two match yours, I guess it's possible there might be an error as "NaN" is C# for "Not a number".  But I do agree with you there is no "constant" multiplier between the king PSTs in Rybka and Fruit given the available data, was there ever claimed to be?

C:\Users\nick\chess\PST\bin\Debug>ConsoleApplication.exe
Rybka/Fruit King PST ratio for square 1 = 35.175
Rybka/Fruit King PST ratio for square 2 = 37.52
Rybka/Fruit King PST ratio for square 3 = 31.2666666666667
Rybka/Fruit King PST ratio for square 4 = 0
Rybka/Fruit King PST ratio for square 5 = 0
Rybka/Fruit King PST ratio for square 6 = 31.2666666666667
Rybka/Fruit King PST ratio for square 7 = 37.52
Rybka/Fruit King PST ratio for square 8 = 35.175
Rybka/Fruit King PST ratio for square 9 = 46.9
Rybka/Fruit King PST ratio for square 10 = 46.9
Rybka/Fruit King PST ratio for square 11 = 46.9
Rybka/Fruit King PST ratio for square 12 = NaN
Rybka/Fruit King PST ratio for square 13 = NaN
Rybka/Fruit King PST ratio for square 14 = 46.9
Rybka/Fruit King PST ratio for square 15 = 46.9
Rybka/Fruit King PST ratio for square 16 = 46.9
Rybka/Fruit King PST ratio for square 17 = 140.7
Rybka/Fruit King PST ratio for square 18 = 93.8
Rybka/Fruit King PST ratio for square 19 = Infinity
Rybka/Fruit King PST ratio for square 20 = 0
Rybka/Fruit King PST ratio for square 21 = 0
Rybka/Fruit King PST ratio for square 22 = Infinity
Rybka/Fruit King PST ratio for square 23 = 93.8
Rybka/Fruit King PST ratio for square 24 = 140.7
Rybka/Fruit King PST ratio for square 25 = Infinity
Rybka/Fruit King PST ratio for square 26 = 187.6
Rybka/Fruit King PST ratio for square 27 = -93.8
Rybka/Fruit King PST ratio for square 28 = 0
Rybka/Fruit King PST ratio for square 29 = 0
Rybka/Fruit King PST ratio for square 30 = -93.8
Rybka/Fruit King PST ratio for square 31 = 187.6
Rybka/Fruit King PST ratio for square 32 = Infinity
Rybka/Fruit King PST ratio for square 33 = -140.7
Rybka/Fruit King PST ratio for square 34 = Infinity
Rybka/Fruit King PST ratio for square 35 = -46.9
Rybka/Fruit King PST ratio for square 36 = 0
Rybka/Fruit King PST ratio for square 37 = 0
Rybka/Fruit King PST ratio for square 38 = -46.9
Rybka/Fruit King PST ratio for square 39 = Infinity
Rybka/Fruit King PST ratio for square 40 = -140.7
Rybka/Fruit King PST ratio for square 41 = -70.35
Rybka/Fruit King PST ratio for square 42 = -187.6
Rybka/Fruit King PST ratio for square 43 = -31.2666666666667
Rybka/Fruit King PST ratio for square 44 = 0
Rybka/Fruit King PST ratio for square 45 = 0
Rybka/Fruit King PST ratio for square 46 = -31.2666666666667
Rybka/Fruit King PST ratio for square 47 = -187.6
Rybka/Fruit King PST ratio for square 48 = -70.35
Rybka/Fruit King PST ratio for square 49 = -46.9
Rybka/Fruit King PST ratio for square 50 = -93.8
Rybka/Fruit King PST ratio for square 51 = -23.45
Rybka/Fruit King PST ratio for square 52 = 0
Rybka/Fruit King PST ratio for square 53 = 0
Rybka/Fruit King PST ratio for square 54 = -23.45
Rybka/Fruit King PST ratio for square 55 = -93.8
Rybka/Fruit King PST ratio for square 56 = -46.9
Rybka/Fruit King PST ratio for square 57 = -35.175
Rybka/Fruit King PST ratio for square 58 = -62.5333333333333
Rybka/Fruit King PST ratio for square 59 = -18.76
Rybka/Fruit King PST ratio for square 60 = 0
Rybka/Fruit King PST ratio for square 61 = 0
Rybka/Fruit King PST ratio for square 62 = -18.76
Rybka/Fruit King PST ratio for square 63 = -62.5333333333333
Rybka/Fruit King PST ratio for square 64 = -35.175
Parent - - By Ugh (*****) Date 2011-07-28 13:09
Well done and thanks for that. There have been numerous claims, ranging from the PSTs are identical, to identical except for a multiplier, to identical except for kludges, but I don't think anyone has specifically tried to say which tables, other than the sometimes use or implication of the word "all".

If I switch out of adversarial and into balanced mode for a while ....

Basically the PSTs are based on the ramping patterns contained below. The ramping patterns contain chess knowledge, the knowledge is blunt, primitive and entirely untuned, but that is not a problem since it is basically only meant to be blunt guidance for the program. I put some chess knowledge commenting against each of the 9 ramping patterns ....

static const int PawnFile[8] = { -3, -1, +0, +1, +1, +0, -1, -3 }; // encourages pawn captures towards the centre
static const int KnightLine[8] = { -4, -2, +0, +1, +1, +0, -2, -4 }; // encourages knight centralisation
static const int KnightRank[8] = { -2, -1, +0, +1, +2, +3, +2, +1 }; // encourages our knight to occupy squares in the enemy half of the board
static const int BishopLine[8] = { -3, -1, +0, +1, +1, +0, -1, -3 }; // encourages bishop centralisation
static const int RookFile[8] = { -2, -1, +0, +1, +1, +0, -1, -2 }; // encourages rooks to occupy centre files
static const int QueenLine[8] = { -3, -1, +0, +1, +1, +0, -1, -3 }; // encourages queen centralisation
static const int KingLine[8] = { -3, -1, +0, +1, +1, +0, -1, -3 }; // encourages king centralisation
static const int KingFile[8] = { +3, +4, +2, +0, +0, +2, +4, +3 }; // encourages king to castle or generally get out of the centre
static const int KingRank[8] = { +1, +0, -2, -3, -4, -5, -6, -7 }; // discourages king from advancing up the board

Now, the multiplicative relationship between Fruit and Rybka tables which Hyatt claims, depends on what happens next, how the PST tables are built from the ramping patterns. I am assuming Zach's assumptions here btw.

If the two programs use ONE ramping pattern to build the respective PSTs, they will be multiplicative.
If they use TWO DIFFERENT ramping patterns, the PSTs will NOT be multiplicative.

Additionally, if the tables are modified with kludges, the PSTs will not be multiplicative.

Now, Hyatt wants to me to skip over the pawns and look at the knights, possibly because the pawn PSTs are hit by kludges . But I'll look at the pawns first because they tell us something about Vas ...

Pawns
Fruit has one table. Rybka has two. The purpose of the Fruit table is to encourage pawn captures towards the centre. If there had not been subsequent kludges applied, this table would be multiplicative with the first Rybka table. But in the second table you can see that Vas has not just blindly copied without thought, he realised, if Zach allegation of "use of Fruit" is true, that he can add another important piece of chess knowledge by adding another table. This table, for use in the endgame, encourages pawn captures AWAY from the centre, objective: creation of wing pawns and hopeful passers. He did it by changing the weight size, but more importantly by the simple act of inverting the sign of the weight from positive to negative. These little things are the genius of Vas. All programmers who do NOT do this, and have just read this will now scurry off and implement it as a feature ;-)  Such is computer chess development.

Knights
Both programs have two knight PST tables, one for ending and one for the opening. The endgame tables are multiplicatively matching - they are based on one ramping pattern only. The opening tables are NOT multiplicative because they are basically the same as the endgame tables but with another (actually two more) ramping pattern(s) overlaid, destroying the multiplicative relationship.

There is another example, in passing, in the knight code which demonstrates how Zach's fantasy source code has been manipulated to give the best possible visual match.

In Fruit for the knights, is the code

static const int KnightBackRankOpening = 0;
for (sq = A1; sq <= H1; sq++) {
P(piece,sq,Opening) -= KnightBackRankOpening;


which adds 0, zero, all along the back rank, 8 times and is of course pointless.

The fantasy Rybka code, generated by Zach, contains the same useless structures ...
static const int KnightBackRankOpening = 0;
for (sq = A1; sq <= H1; sq++) {
P(piece,sq,Opening) -= KnightBackRankOpening;


and it can be there, placed there by Zach, only to provide better visual matching. Source code manipulation from a decompile is of course very easy to do, and has to be watched for in the case of "bias" because "biased" decompiling programmers will try to choose the most incriminating possible source. In this case Zach hasn't even got anything to decompile from, so the usual relationship:

Object code + decompiler + decompiling programmer creativity -> decompiled source

is shortened in these PST cases where there is no object code to:

Nothing at all + decompiling programmer creativity -> decompiled source

where bias is obviously going to be a terrible problem.
Parent - - By Nick (*****) Date 2011-07-28 13:21
Thanks for the chess programming tuition, I may end up writing my own chess program at this rate.

It's clear to me now that the fantasy code produced by Zach is horribly bogus.  However, by producing it and convincing others that it appears in Rybka (which it clearly does not), he has managed to get himself into the position of being the current ICGA World Champion Chess Programmer.  It's really humorous that Vas doesn't give a crap ;)

Roll on Rybka 5 !
Parent - - By Mark (****) Date 2011-07-28 16:21
You have to remember, though, who's looking at the "fantasy code." It's a bunch of experienced chess programmers. They know exactly what this is, and aren't going to be fooled by it.
Parent - By Nick (*****) Date 2011-07-28 16:28
I agree that it would be interesting to ask them if they did their own disassembly or trusted the bogus code that was presented to them.
Parent - By Ugh (*****) Date 2011-07-27 18:32
I respectfully suggest you go away and do your homework better before writing such nonsense.

I think you'll find your "constant" is actually a variable and depends on which matrix cell you want to multiply.

Have you really gone through this entire process with the wiki gang on this ridiculously erroneous assumption? No wonder Vas was found guilty, your condemnation data is false and you misled the entire wiki group and the icga
Parent - - By RFK (Gold) Date 2011-07-27 18:50
I assume that this is an example of poorly practiced science?

Bob,

Prejudicial attitudes and biases can easily work their way into the most controlled research project. Most projects weight in to take proper measures to filter out researchers with known biases. Or set up  controls to assure that the data collected is not in some way unconsciously manipulated. The ICGA totally looked the other way in this regard.
Parent - - By bob (Gold) Date 2011-07-27 20:15
No, it didn't "look the other way".  In fact, a number of people looked at the data after it was put together, and critiqued it.  And some had the requisite skills to look at it, and then add additional information because they understood assembly language programming.

Since this is broken up into 4 distinct parts, of which the ICGA only investigated 3, let me list 'em and see which ones are subject to disagreement.

1.  Rybka 1.6.1 was a total copy of Crafty version 19.x, with possibly a few "mythical changes".  "Mythical" because none were found, but there was so much copied code that it was deemed unnecessary to show that every line was copied.  Vas claimed all versions (all has a clear meaning and he responded pretty clearly) were original.  That is clearly false.  This program was entered in a non-ICGA tournament that used ICGA rules, thus violating the rules for participation as well as the license agreement for Crafty.  It was also given to a rating list for testing, again violating the license agreement, and most likely the rating list guidelines as well as they typically don't accept copies.

2.  Rybka 1.0 beta.  Zach's paper is extremely damaging to any claim of "originality" one might postulate.  And remember, even though Vas has stated that if you copy a program's eval completely, but write your own search and everything else, that should be OK for competition, that is not what the ICGA rules say.  The ICGA rules say you can not copy parts of another author's code and participate without that author's permission.  It is clear that he disdains rules that are clearly written and which have been used for many years.  And it is clear that 1.0 beta has a lot of fruit in it.  And any fruit is too much fruit, pardons to the pineapple/apple/peach/etc lovers of the world...

3.  Rybka 2.3.2, which was the subject of Mark's comparison.  It too shares too much with fruit to be allowable according to the ICGA rules. 

4.  Rybka 3/4/etc were not tested.  Whether they are clean is unknown, but it is unlikely since nobody throws away everything and starts over for each new version.  So it is highly likely that pieces remain.  But that is unknown and unclaimed.  He can address that if he chooses.

There are two arguments about the above.

1.  ICGA rules are clear.  He violated those and was penalized for doing so.  I'm not going to argue about the harshness, when he chose to completely ignore the ICGA's request, he put himself at risk.  His fault.

2.  copyright laws are also clear, as is the GPL addition.  Did he violate those?  We did not directly address that.  Apparently the FSF is pondering that issue now.  If they choose to pursue it, we will know their view.  If the court agrees with them, then we will have a binding legal opinion.  None of that has any bearing on me, nor on the ICGA and its tournaments.  We want the tournaments to represent what we, the programmers, wanted when we formed the ICCA (now ICGA) in 1977 in Toronto, Canada.  An event for programs.  We write the rules.  We don't always agree.  We do accept "majority rules" when there is a disagreement.  And the ICGA has survived for 34 years adhering to those standards.

Discussion.

I do not believe any rational person can dispute item 1 above.  All that can be done is to wave the white flag and surrender, adding the caveat "but it didn't compete in an ICGA event so it should not count."  I also competed in every CCT that has been held, as have many other programmers.  WE also organize those events and we chose to use the same rules (we are the same group, obviously).  And 1.6.1 clearly broke _those_ rules.  And that is somehow "OK"?  And then there are the statements claiming that Rybka has _always_ been 100% original except for copied public-domain snippets.  False, and the ICGA was correct to verify that statement since it came from the ICGA investigation when Vas made his regular denial of copying.  Rybka 1.0 beta is also way too much like Fruit.  It was derived directly from code in fruit.  And Zach's report is crystal clear in that regard.

So now we have two examples of definite copying, and we move to 2.3.2a.  Mark's eval comparison shows far more overlap between fruit and rybka than between any other programs.  Given 1.6.1 and 1.0 beta, that absolutely throws doubt into the discussion about 2.3.2a.  Fool me once, shame on you.  Fool me twice, shame on me.  Fool me three times and I am an idiot for getting fooled so many times...

That's where we are, IMHO.

So, let's do this orderly.

Take point 1 above, by itself.  Do you dispute that 1.6.1 is a copy of crafty, that it broke CCT rules, that it violated the crafty license agreement, and that statements made about it by Vas were completely false?  Then we can go on to point 2 and beyond...
Up Topic Rybka Support & Discussion / Rybka Support / Minority Report 3, PST + other lookup tables are they legal?
1 2 Previous Next  

Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill