Here again you fall prey to the recurring problem with your work. Mathematical-itis, where all numbers are randomly distributed and equally likely. This was the problem that led to your ridiculous statistics of copying probability where a little chess knowledge would have told you that your "independent" values were highly dependent, of limited range and often forced.BB+ wrote:OK, I didn't catch this. But this is no longer the Fruit ramping arrays. You've made them parameters (see below), while I insist they are not for the Rybka/Fruit comparison, where they can be taken to be the same. [The Fruit method must have, e.g., 0 at d2, when using the ramping array in question (and Crafty does not)]. If you argue that there are 8 parameters, I will say: "OK, but 4 of these 8 are the same (by whichever method, either ramping arrays or redundancies via linear relations) in F/R -- is there a similar commonality amongst your 8 parameters for other engines?"Miguel Ballicora wrote:I corrected Bob already about this. The normalizing constant is embedded in the vector. So, use -1,1,2,3 rather than -3,-1,0,1 and you get Crafty numbers exactly, without even touching the multipliers and using the exact same code. Saying the you can get them with +8 is an easy way to see it.
Well, I guess we are going to argue about the mathematics then (and this forum is not the easiest to typeset, if it comes to that)... Fruit uses specific arrays, like -3 -1 0 1. If you view these specific arrays as "parameters" also, you add four more. But the Rybka data can be determined from the use of the same ramping arrays as Fruit (sorry for so many bolds, but this is the point). Counting these notable commonalities of Fruit/Rybka as "parameters" of a more general layout seems just plain wrong to me.Miguel Ballicora wrote:No, I said this already, they were not overparametrized,
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".There is very little of specificity in these tables..Fruit made a specific choice for the ramping-array of the Bishops. Then another specific choice of ramping-array for Queens, then Kings, etc. You can indeed argue than none of these are particularly earth-shattering, but their summatory effect is exactly the point. A relevant legal quotation is: Lest we fall prey to defendants' invitation to dissect the works, however, we should remember that it is the combination of many different elements which may command copyright protection because of its particular subjective quality.In fact, with the criteria used, Fruit Q tables and K endgame tables were cloned... from Fruit B table. They can be generated from that one, just changing the multipliers (not even the ramping array!)
I think this is misguided, as the multiplicity and specificity of use matters too. If there are 5 "reasonable" lists (ABCDE) that specify some chess knowledge for any PST [say it's left-to-right increasing, such as -2,-1,0,1 and -3,-1,0,-1 and -4,-1,0,1 and 0,0,2,3 and -4,-2,0,3] , and my engine uses them for the (say) 8 PSTs as: AEDBBBEA, this is a particular choice. For your engine to choose (first the same process and then) the same AEDBBBEA usage independently would be quite rare. This is (in essence, perhaps not to degree) the gravamen of the Fruit/Rybka PST issue.That is the point, there no lists of 10 ramping arrays, they are four or five, which the imply obvious chess knowledge. They look many because -3,-1,0+1 is repeated several times.
Now you would have us believe in the random distribution of the use of potential ramping arrays ABCDE or DECBA being mere mathematical probabilities of equal happenstance. Yet you should know perfectly well that most combinations of ABCDE are rejectable on chess knowledge grounds, or would you actually be proposing making, say a knight table up from 1,2,3,4,5,6,7,8 ramped across both the x and y axis, and thus weighting your knights to go as far and as fast as possible to the corner square a8?
