PST of Fruit 2.1 and Rybka 1.0 Beta

[BB+]

I attach two programs that respectively compute the PST of Fruit 2.1 and Rybka 1.0 Beta. The purpose of this is to gauge the amount of code modification of Fruit necessary to reproduce the Rybka numbers. This is a fairly standard method for detecting "closeness", particularly when only one source code is available. Everything in the top half of the files is "filterable" (like computing the rank of a square), and so should not be included in a comparison. As usual, I will let others discuss the value of this evidence (for instance, introducing metrics) before arguing for my own opinion.

The Fruit 2.1 code has been re-formatted, but everything has been left in, including the possible scaling from a UCI option (e.g., some other engine might match the Fruit method, but only when scaling by 95%). I didn't bother with the white/black reflection. For Rybka 1.0 Beta I count: 2 added lines (for PawnFileEndgame), 4 removed statements (for D3/E3/D4/E4 pawns in the opening, others might count this as 2, due to D3/E3 and D4/E4 being in reflection), and 18 statements with modified numerology (the "tuning" numbers, one might call them, again only 17 if counting D5/E5 as one).

I also consider it a challenge to find a 2005-era engine (on any engine which is not specifically Fruit-influenced) whose PST can be replicated via a set of modifications that is comparable to the smallness of the Rybka/Fruit difference.

[Chris Whittington]

I attach two programs that respectively compute the PST of Fruit 2.1 and Rybka 1.0 Beta. The purpose of this is to gauge the amount of code modification of Fruit necessary to reproduce the Rybka numbers. This is a fairly standard method for detecting "closeness", particularly when only one source code is available. Everything in the top half of the files is "filterable" (like computing the rank of a square), and so should not be included in a comparison. As usual, I will let others discuss the value of this evidence (for instance, introducing metrics) before arguing for my own opinion.

The Fruit 2.1 code has been re-formatted, but everything has been left in, including the possible scaling from a UCI option (e.g., some other engine might match the Fruit method, but only when scaling by 95%). I didn't bother with the white/black reflection. For Rybka 1.0 Beta I count: 2 added lines (for PawnFileEndgame), 4 removed statements (for D3/E3/D4/E4 pawns in the opening, others might count this as 2, due to D3/E3 and D4/E4 being in reflection), and 18 statements with modified numerology (the "tuning" numbers, one might call them, again only 17 if counting D5/E5 as one).

I also consider it a challenge to find a 2005-era engine (on any engine which is not specifically Fruit-influenced) whose PST can be replicated via a set of modifications that is comparable to the smallness of the Rybka/Fruit difference.

I've not read your source code examples below as of yet, but ....

Exiting adversarial mode for a minute or two, I think the only difference between the two sides (discounting the now discredited extremist Hyatt position) is ....

We have some disagreement over exactly which PST tables can be dropped from consideration, we say all, you say N.

We argue that the PST's are the result of very trivial ramping arrays(1,2,3,4) which are non-copyrightable. That these arrays represent widely known and simple chess knowledge and can't be copyright for this reason in addition to their their triviality.

You argue that although the ramping arrays are indeed trivial the use of several together in a similar way is copyrightable.

We argue that the "several" is a very low number, and that the "several" can all be derived from each other anyway, so "several" could still actually be "one". We don't agree on the N, or on what N a copyright line is crossed.

We also argue that the way they are put together is also known and trivial.

You argue it is mostly a giant so-what since the PSTs are only 1% of the evidence.

We argue that the PST's were presented as a very important part of the evidence (I think someone listed the document references to them on Rybka forum).


So, you say, PST's not very important, agree with ramping triviality, but think a line was stepped over. We say, PST's presented as important, agree on ramping triviality, don't think any line was overstepped and complain that there is no reference then to such a line, ie how is a programmer supposed to know?

Not a huge difference really, mostly just one of interpretation.

[BB+]

Exiting adversarial mode for a minute or two, I think the only difference between the two sides[...]

(Emphasis added). It is nontrivial for me to parse such a construction. If there are "sides", they are adversarial, no? I would prefer you to call them "interpretations", perhaps -- this would be more akin to the atmosphere of the Panel process. [And would be more apt to avoid degenerating to persons, rather than their contentions].

You argue it is mostly a giant so-what since the PSTs are only 1% of the evidence.

I said that PST was (not more than) 1% of the "issue", which in the context therein was copyright infringement. For the purpose of "copying"/originality, I don't think the number is that low, and as Adam Hair said, overall it's a cumulative conclusion, with each component playing its part.

As per Richard Vida (and the Buzz/Rybka issue that came up in the Panel), one could argue that PST (by itself) is de minimis for ICGA Rule #2 [is this still a relevant issue to you?], but that's a different argument, and I contend it is better to stick with one issue at a time. Some subset (perhaps all) of you, Ed, and Miguel have claimed that the PST issue is "busted", while others are not so convinced, and so I want to recapitulate the evidence, perhaps from a different vantage point.

[hyatt]

So, you say, PST's not very important, agree with ramping triviality, but think a line was stepped over. We say, PST's presented as important, agree on ramping triviality, don't think any line was overstepped and complain that there is no reference then to such a line, ie how is a programmer supposed to know?

Here's a pretty simple challenge. Why not look at any of the many open-source programs that are available. Even take multiple versions since I did show that Crafty's PST values have changed more than once over the years. And then find another open source program (there are hundreds of them) that match as closely to fruit as does Rybka. If it is _that_ common, you ought to be able to find one quickly. And of course, only one limitation... if the author claims the program was derived from fruit, it obviously doesn't count since it should match. Toga for example. But if it is _that_ common, and the numbers are _that_ restricted with regard to choices one can make, you ought to be able to find an example to back that up. Not a lot of point in checking Crafty versions since it doesn't even use the same basic idea as fruit for all its PSTs. But you ought to be able to find a concrete example if this is such a simple set of numbers that can be produced by anyone.

Program name???

[Chris Whittington]

So, you say, PST's not very important, agree with ramping triviality, but think a line was stepped over. We say, PST's presented as important, agree on ramping triviality, don't think any line was overstepped and complain that there is no reference then to such a line, ie how is a programmer supposed to know?

Here's a pretty simple challenge. Why not look at any of the many open-source programs that are available. Even take multiple versions since I did show that Crafty's PST values have changed more than once over the years. And then find another open source program (there are hundreds of them) that match as closely to fruit as does Rybka. If it is _that_ common, you ought to be able to find one quickly. And of course, only one limitation... if the author claims the program was derived from fruit, it obviously doesn't count since it should match. Toga for example. But if it is _that_ common, and the numbers are _that_ restricted with regard to choices one can make, you ought to be able to find an example to back that up. Not a lot of point in checking Crafty versions since it doesn't even use the same basic idea as fruit for all its PSTs. But you ought to be able to find a concrete example if this is such a simple set of numbers that can be produced by anyone.

Program name???

Why should anyone bother arguing with your discredited extremist positions when both you and your extremist positions have already been abandoned by your erstwhile collaborators? The argument centre has moved on, but you just stay where you are, out in extremist-bonkers-land, alternating the fuming madness with the pitiful lying.

[Chris Whittington]

Exiting adversarial mode for a minute or two, I think the only difference between the two sides[...]

(Emphasis added). It is nontrivial for me to parse such a construction. If there are "sides", they are adversarial, no? I would prefer you to call them "interpretations", perhaps -- this would be more akin to the atmosphere of the Panel process. [And would be more apt to avoid degenerating to persons, rather than their contentions].

You argue it is mostly a giant so-what since the PSTs are only 1% of the evidence.

I said that PST was (not more than) 1% of the "issue", which in the context therein was copyright infringement. For the purpose of "copying"/originality, I don't think the number is that low, and as Adam Hair said, overall it's a cumulative conclusion, with each component playing its part.

As per Richard Vida (and the Buzz/Rybka issue that came up in the Panel), one could argue that PST (by itself) is de minimis for ICGA Rule #2 [is this still a relevant issue to you?], but that's a different argument, and I contend it is better to stick with one issue at a time. Some subset (perhaps all) of you, Ed, and Miguel have claimed that the PST issue is "busted", while others are not so convinced, and so I want to recapitulate the evidence, perhaps from a different vantage point.

If the "sides" remain "adversarial" the entire time, then they will be unable to reach any conclusion other than one imposed from outside. The trick is to be adversarial some of the time (which usually involves a full on dismissal of the opposition case and a full-on assertion of one's own), but "negotiatory" some of the time, to see if any points of commonality can be found, or if the other side wants to compromise.

By being non-adversarial for a couple of minutes, I was investigating with you to determine if the actual PST positions were actually as far apart as they perhaps seemed. Your reply is a bit too woffly to determine though. My guess is you would probably like to compromise but are worried about the loss of face that might ensue.

[Rebel]

Some subset (perhaps all) of you, Ed, and Miguel have claimed that the PST issue is "busted", while others are not so convinced, and so I want to recapitulate the evidence, perhaps from a different vantage point.

There are now 6 chess programmers that say so.

[hyatt]

So, you say, PST's not very important, agree with ramping triviality, but think a line was stepped over. We say, PST's presented as important, agree on ramping triviality, don't think any line was overstepped and complain that there is no reference then to such a line, ie how is a programmer supposed to know?

Here's a pretty simple challenge. Why not look at any of the many open-source programs that are available. Even take multiple versions since I did show that Crafty's PST values have changed more than once over the years. And then find another open source program (there are hundreds of them) that match as closely to fruit as does Rybka. If it is _that_ common, you ought to be able to find one quickly. And of course, only one limitation... if the author claims the program was derived from fruit, it obviously doesn't count since it should match. Toga for example. But if it is _that_ common, and the numbers are _that_ restricted with regard to choices one can make, you ought to be able to find an example to back that up. Not a lot of point in checking Crafty versions since it doesn't even use the same basic idea as fruit for all its PSTs. But you ought to be able to find a concrete example if this is such a simple set of numbers that can be produced by anyone.

Program name???

Why should anyone bother arguing with your discredited extremist positions when both you and your extremist positions have already been abandoned by your erstwhile collaborators? The argument centre has moved on, but you just stay where you are, out in extremist-bonkers-land, alternating the fuming madness with the pitiful lying.

Of course you don't want to do ANYTHING that might shoot down your current "explanation"...

No surprise at all. But that is a way to show that the probability that Vas came up with those numbers by himself is higher than many of us think, just find an example. If it is as simple as you/Ed want everyone to believe, shoot, MOST programs ought to have very similar PST numbers that can be derived from Fruit's initialization... All you have to do is show some and it will change my mind, at least...

[hyatt]

Some that claim to not even have read the evidence carefully. That would, of course, be you for starters...

We had 14 that publicly voted "we agree". I've seen just one "fall by the wayside". So it is still a 2:1+ ratio...

Meanwhile, let's keep arguing while the fuse burns and the FSF moves along. Or get Vas to straighten this mess out and we can all move on to greener pastures...

[BB+]

The trick is to be adversarial some of the time (which usually involves a full on dismissal of the opposition case and a full-on assertion of one's own) [...]

This was not the working methodology of the Panel, nor particularly one that I find all that valuable. Maybe, as you say, I think too "academically/scientifically", but I think it has many advantages. For instance, the above confrontational model has frequently led to personal innuendo (in some cases quite shameless), which (to me at least) has been a major case of "irritation" that was absent in the Panel.

By being non-adversarial for a couple of minutes, I was investigating with you to determine if the actual PST positions were actually as far apart as they perhaps seemed. Your reply is a bit too woffly to determine though. My guess is you would probably like to compromise but are worried about the loss of face that might ensue.

I could propose the opposite -- once I posted this direct challenge from the data, you "almost immediately" tried to bump the discussion to a meta-level... As I say, I don't think such debating techniques are efficacious. Nor is guessing about my possible fear of humiliation if/when I am shown to be wrong.

The above challenge stands. As an example, I will investigate the (current) Stockfish numbers, which have been noted elsewhere to have at least some Fruit congruence, and see how easy it is to reproduce said numbers (and do so exactly, not just approximately) with the Fruit 2.1 code. Again I don't want to pre-bias the discussion by naming a metric of "code changes" (e.g., if one can match 5 pieces with one change each, but kings are radically different and take 30 changes, is that worse than 15 changes evenly distributed? -- is changing a "ramping array element" the same as changing a "tuning parameter"?), but will report want I find, at least if this topic hasn't diverged to nonsense by the time I complete said task.