OpenChess

Posted: **Mon May 14, 2012 1:10 pm**

syzygy wrote:You can't write a program identical to Fruit without writing an evaluation function that gives identical results, i.e. that has all the same evaluation features.

As you've indicated, this then turns on what "all the same" evaluation features means, but I will attempt to elucidate my comment a bit more.

Suppose we took the Fruit evaluator as a black box, and by input/output testing, replicate its functionality. Noting that 50 appears thrice (at least) as a value, would there be any reason for these not to be combined into some conjunctive feature like BlockedBishopOrRook_OrTrappedBishopOn6th?

Similarly, why should these 4 parameters

Code: Select all

static const int KnightMobOpening = 4;
static const int KnightMobEndgame = 4;
static const int RookMobOpening = 2;
static const int RookMobEndgame = 4;

not combine into 3 (or even 2), when viewed from a black box, such as

Code: Select all

static const int KnightMobOpening = 4;
static const int RookMobOpening = 2;
static const int KnightOrRookMobEndgame = 4;

Code: Select all

static const int KnightMobAllPhases = 4;
static const int RookMobOpening = 2;
static const int RookMobEndgame = 4;

It is true that splitting as BlockedBishop, BlockedRook and TrappedBishop makes more sense from a chess view, and similarly with the mobility, but that's precisely something beyond functionality, no? The same could be said for (say) placing KnightTrapped in PST rather than in eval_pattern(), or the fact that for majors the Endgame mobility is twice that of the Opening, etc. There is a reasonable amount of mucking around one can do with features and still retain the Fruit inputs->outputs.

One could presumably choose a different basis (replace X and Y by X-Y and X+Y, etc.) -- however, I would say that there is fairly naturally a preferred basis [falling under efficiency considerations though, which should be distinguished from functionality]. And I would also concur that (reasonably) replicating the Fruit functionality requires a highly similar feature set, just not one that is "all the same".

Posted: **Mon May 14, 2012 7:56 pm**

hyatt wrote:You can continue to spout all the nonsense you want.

Why don't just go wash your mouth and let the adults continue this discussion you know nothing about?

Posted: **Tue May 15, 2012 12:02 am**

syzygy wrote:
hyatt wrote:You can continue to spout all the nonsense you want.
Why don't just go wash your mouth and let the adults continue this discussion you know nothing about?

The only "adult" I see posting is Mark, at present. I'm perfectly happy to let him explain his views, obviously... You, on the other hand, seem to have great difficulty understanding the difference between "ideas" and "implementations" and continually treat them as the same thing, using some sort of abstract view. That is NOT the case, however. Ideas are distinct from implementations. We have been talking about implementations from the get-go, NOT just "ideas". Yet you keep recasting the discussion to be about ideas, incorrectly. As does Chris and Ed.

Ideas were NEVER a part of the ICGA discussions or investigation...

Perhaps you should go wash something and get a fresh (and more relevant) perspective???

Posted: **Tue May 15, 2012 1:42 pm**

hyatt wrote:
syzygy wrote:
hyatt wrote:You can continue to spout all the nonsense you want.
Why don't just go wash your mouth and let the adults continue this discussion you know nothing about?

The only "adult" I see posting is Mark, at present. I'm perfectly happy to let him explain his views, obviously... You, on the other hand, seem to have great difficulty understanding the difference between "ideas" and "implementations" and continually treat them as the same thing, using some sort of abstract view. That is NOT the case, however. Ideas are distinct from implementations. We have been talking about implementations from the get-go, NOT just "ideas". Yet you keep recasting the discussion to be about ideas, incorrectly. As does Chris and Ed.

Ideas were NEVER a part of the ICGA discussions or investigation...

Perhaps you should go wash something and get a fresh (and more relevant) perspective???

Wrong again. Do you ever actually read in details the material the icga puts out? Importantly that Watkins document COMPEVAL in which ideas and implementations of ideas are both ascribed numerical values and then mixed, hopelessly, together to give ONE number.

Watkins takes each evaluation feature (idea) that matches between each program pair and scores it at 1.0. For every "implementation difference" he then removes approximately 0.2. Thus, for example, he claims one implementation difference in Rybka Fruit mobility, and scores each of the four mobility terms at 0.8. Thus his scoring system appears to tune to evaluation feature implementations.

However, he also scores each evaluation feature (idea) which has no counterpart in the other matching program of the pair as zero, 0.0.

Then he adds everything up and divides by the average number of ideas in each program pair. This averaging process or inclusion of the zeros, effectively lowers the score of a program pair with a low number of evaluation pair matches and increases it for those with a high number of evaluation matches.

Thus, his final score is a undeconstructable mishmash of two components

a) implementation similarity which increases the score

b) number of ideas matching which also increases the score.

So, perhaps you'ld like to quit with your occasional, is it suits you assertion, that the icga process is not about ideas. Because every time you claim 70% or whatever similarity you are talking about ideas match. And ideas and lists of ideas are free to use and have no copyright.

I might add a criticism of the COMPEVAL here. Take the case of FAILE and CRAFTY. FAILE has, iirc, 14 eval features. Crafty has, iirc, 38 features, according to Watkins. Practically all of FAILE 14 features are in Crafty. However FAILE scores around 0.2 in its match with CRAFTY. Why is this when the match is actually rather greater? Well, it's because the additive score of evaluation matches is divided by the average of total CRAFTY and FAILE evaluation features. The average of 14 and 38 is 26. In the circumstances of 14 features total, 26 is a relatively massive divisor and has effect of making FAILE look less similar to CRAFTY than it actually is.

Posted: **Thu May 17, 2012 11:35 pm**

Chris Whittington wrote:
hyatt wrote:
syzygy wrote:
hyatt wrote:You can continue to spout all the nonsense you want.
Why don't just go wash your mouth and let the adults continue this discussion you know nothing about?

The only "adult" I see posting is Mark, at present. I'm perfectly happy to let him explain his views, obviously... You, on the other hand, seem to have great difficulty understanding the difference between "ideas" and "implementations" and continually treat them as the same thing, using some sort of abstract view. That is NOT the case, however. Ideas are distinct from implementations. We have been talking about implementations from the get-go, NOT just "ideas". Yet you keep recasting the discussion to be about ideas, incorrectly. As does Chris and Ed.

Ideas were NEVER a part of the ICGA discussions or investigation...

Perhaps you should go wash something and get a fresh (and more relevant) perspective???
Wrong again. Do you ever actually read in details the material the icga puts out? Importantly that Watkins document COMPEVAL in which ideas and implementations of ideas are both ascribed numerical values and then mixed, hopelessly, together to give ONE number.

Watkins takes each evaluation feature (idea) that matches between each program pair and scores it at 1.0. For every "implementation difference" he then removes approximately 0.2. Thus, for example, he claims one implementation difference in Rybka Fruit mobility, and scores each of the four mobility terms at 0.8. Thus his scoring system appears to tune to evaluation feature implementations.

However, he also scores each evaluation feature (idea) which has no counterpart in the other matching program of the pair as zero, 0.0.

Then he adds everything up and divides by the average number of ideas in each program pair. This averaging process or inclusion of the zeros, effectively lowers the score of a program pair with a low number of evaluation pair matches and increases it for those with a high number of evaluation matches.

Thus, his final score is a undeconstructable mishmash of two components

a) implementation similarity which increases the score

b) number of ideas matching which also increases the score.

So, perhaps you'ld like to quit with your occasional, is it suits you assertion, that the icga process is not about ideas. Because every time you claim 70% or whatever similarity you are talking about ideas match. And ideas and lists of ideas are free to use and have no copyright.

I might add a criticism of the COMPEVAL here. Take the case of FAILE and CRAFTY. FAILE has, iirc, 14 eval features. Crafty has, iirc, 38 features, according to Watkins. Practically all of FAILE 14 features are in Crafty. However FAILE scores around 0.2 in its match with CRAFTY. Why is this when the match is actually rather greater? Well, it's because the additive score of evaluation matches is divided by the average of total CRAFTY and FAILE evaluation features. The average of 14 and 38 is 26. In the circumstances of 14 features total, 26 is a relatively massive divisor and has effect of making FAILE look less similar to CRAFTY than it actually is.

If you want to continue to confuse idea and implementation, feel free to do so. Mark is focusing on the specific implementation details in his analysis, as opposed to abstract ideas. That was the key. What conditions are required to trigger a bonus or penalty. In what order. In what combination(s). Etc. I think what he did is pretty easy to understand unless you simply don't like the conclusion and want to look for any possible criticism, including using the wrong terminology at will...

As far as faile/crafty, this is a two-way comparison. How much of Crafty eval is in Faile? Not just how much of Faile eval is in Crafty. A small intersection between two programs does NOT suggest copying. A large intersection does...

OpenChess

Functionality of programs not protected by copyright

Re: Functionality of programs not protected by copyright

Re: Functionality of programs not protected by copyright

Re: Functionality of programs not protected by copyright

Re: Functionality of programs not protected by copyright

Re: Functionality of programs not protected by copyright