Questions for BB about Rybka PST = Fruit PST

[hyatt]

I've done a ton of tuning on Crafty's eval numbers as everyone knows. And not once have I scaled by FP numbers. Most of mine are via a pair of * and / operators which can certainly produce a FP-like result. But Rybka's EXACT 69.4 leaves me going hmmmm... Yes he could have multiplied by 347 and divided by 5. Or multiplied by 694 and divided by 10. But the numbers seem odd. If we take 3399, which is really 34x fruit with a tiny bit of rounding, then 68.0 seems perfectily natural (not that 3200 or 3399 for pawns seems natural but that is a different issue). So we need another 1.4x. There's gotta be a rational/reasonable explanation for where that came from. It could be just as WG said. Obfuscation. But since these numbers are internal and not shown externally at all, that doesn't make much sense.

I'm still mulling it over. One day it will come to me (or to someone) assuming there is an actual explanation and it is not just some random factor that was added.

[zwegner]

I've done a ton of tuning on Crafty's eval numbers as everyone knows. And not once have I scaled by FP numbers. Most of mine are via a pair of * and / operators which can certainly produce a FP-like result. But Rybka's EXACT 69.4 leaves me going hmmmm... Yes he could have multiplied by 347 and divided by 5. Or multiplied by 694 and divided by 10. But the numbers seem odd. If we take 3399, which is really 34x fruit with a tiny bit of rounding, then 68.0 seems perfectily natural (not that 3200 or 3399 for pawns seems natural but that is a different issue). So we need another 1.4x. There's gotta be a rational/reasonable explanation for where that came from. It could be just as WG said. Obfuscation. But since these numbers are internal and not shown externally at all, that doesn't make much sense.

I'm still mulling it over. One day it will come to me (or to someone) assuming there is an actual explanation and it is not just some random factor that was added.

Why do you think Rybka uses FP anywhere (besides the time control code )? The PSTs can be calculated entirely in integer math, just as my code shows. All of Rybka's values are just from tuning.

[hyatt]

I understand that. My point is, "why are the initial values seeded into (say) the knight PST a 69.4x multiple of fruit numbers? Why not exactly 64? or 67.98 (if you use 3399 rather than 3200 for pawn value)? So why 69.8. Why is the next pass using a multiple of 71.6? The numbers are close, but why not exactly the same? Perhaps in scaling the fruit multipliers there is some reason that makes the overall product 69.4x that of Fruit? I'm looking for a connection between the code you posted for Rybka, and the code in the Fruit pst.cpp source that makes that 69.4 multiplier suddenly seem perfectly natural and explainable.

BTW, no, I don't think he used FP multiplies to scale each pass of the code filling in the PST values. But he did use something (int multiply/divide most likely). I'd like to find some rhyme/reason to explain it.


Got to be something there to explain it. It just hasn't jumped out at me. Yet.

[zwegner]

Hint: take the Rybka values for KnightCentreOpening and KnightRankOpening and divide them by the Fruit values

I'm saying 347 and 358 etc. are just constants from tuning. 69.4 and 71.6 are irrelevant.

[hyatt]

The problem is, I do not believe that the values are from tuning at all. I suspect it is simpler than that. Why? Because I've not worked on tuning PST values since Anthony's stuff fell flat and didn't help any.

Do you really think they would do a night's worth of testing (at that time, according to Kaufman, Vas was running either 4 or 8 hyper-bullet games at a time, to get in 30-40K overnight. How many nights would you have to invest to try enough values for those 4 constants (just for knights)? Something tells me that's not what happened. Possible? Of course. Likely? I don't think so...

[BB+]

Miguel Ballicora gave an alternative way of producing the "ramping" arrays.

static const int BishopGeneralOpening = 147;
static const int BishopGeneralEndgame = 49;
static const int BishopBackRankOpening = 251;
static const int BishopDiagonalOpening = 378;
static const int BishopSidePenaltyOpening = 147;
static const int BishopSidePenaltyEndgame = 49;
static const int BishopNormalizeOpening = -588;
static const int BishopNormalizeEndgame = -196;

One thing that can be noted is that this only works because various "added variables" (beyond the ones in Fruit) need to be multiples of the "original variables". For instance, General and Penalty are the same, and Normalize is -4 times this. Upon tuning the above parameters it then becomes rather unlikely that the divisibility conditions will persist, and the direct link to Fruit/Rybka "ramping" arrays would vanish. Phrased another way, there is extra "information compression" coming from these divisibilities, and so there is a "simpler" way of obtaining the Fruit/Rybka numbers than the parametrisation given above. This said, the general mathematical question here [of determining a "minimal" or "simplest" way of parametrising observed data] can be tricky, and need not be as clear as with Fruit/Rybka.

As for this violating a rule (assuming each of the 8 "feature values" is then tuned), I would say this would not, at least at this level. OTOH, if the "feature sets" (the variables of above) "just happened" to be same for all the pieces [with the usage again being the same], one might start to wonder.

The question of "triviality" of such re-appearances of arrays is a different question. Those who champion the "functional output" of a computer program might dismiss it, but typically copyright law proceeds by considering computer programs as literary works. Particularly if there is no source code for Rybka evinced, the "Occam's Razor" conclusion from a data/code equivalence here seems likely to infringe copyright -- though if so, this then leads to yet another question, that of the overall "percentage" of this element in whole Rybka/Fruit framework (again for copyright aspects, not for chess-strength ones).

[mballicora]

Miguel Ballicora gave an alternative way of producing the "ramping" arrays.

static const int BishopGeneralOpening = 147;
static const int BishopGeneralEndgame = 49;
static const int BishopBackRankOpening = 251;
static const int BishopDiagonalOpening = 378;
static const int BishopSidePenaltyOpening = 147;
static const int BishopSidePenaltyEndgame = 49;
static const int BishopNormalizeOpening = -588;
static const int BishopNormalizeEndgame = -196;

One thing that can be noted is that this only works because various "added variables" (beyond the ones in Fruit) need to be multiples of the "original variables". For instance, General and Penalty are the same, and Normalize is -4 times this. Upon tuning the above parameters it then becomes rather unlikely that the divisibility conditions will persist, and the direct link to Fruit/Rybka "ramping" arrays would vanish. Phrased another way, there is extra "information compression" coming from these divisibilities, and so there is a "simpler" way of obtaining the Fruit/Rybka numbers than the parametrisation given above. This said, the general mathematical question here [of determining a "minimal" or "simplest" way of parametrising observed data] can be tricky, and need not be as clear as with Fruit/Rybka.

Of course, the number of parameters is an important criteria. As you say, I used 8 parameters to derive R1 numbers. But I did no add any. In fact, I could say that I removed some because Zach used 12 in his code. That is, four multipliers + a vector with 8 numbers (-3, -1, 0, +1, +1, 0, -1, -3). You cannot ignore the parameters included in the vector. I removed the vector at once. So technically, my code uses less parameters and should be preferred. However, I am ready to concede that the vector with 8 numbers are actually 4 because of the symmetry. But if we take that into account, Zach code should be modified and it will be an implicit acknowledgment that Fruit's numbers carry even less information content (which I mentioned in other threads). In that case, if we follow Zach hypothesis, VR copied four numbers (-3, -1, 0, +1) and came with four of his own. This breaks the exaggerations floating around that VR copy hundreds of numbers in the PSTs.

Anyway, in a worst case scenario, my code uses 8 parameters and Zach 8, so I do not believe you can prefer one or the other based on that criteria.

Miguel
PS: I registered just to answer this because I saw a link in the R forum. It is already a burden to keep reading several fora, so I apologize if I cannot keep up with other posts or threads in this forum. I most likely won't follow them.

As for this violating a rule (assuming each of the 8 "feature values" is then tuned), I would say this would not, at least at this level. OTOH, if the "feature sets" (the variables of above) "just happened" to be same for all the pieces [with the usage again being the same], one might start to wonder.

The question of "triviality" of such re-appearances of arrays is a different question. Those who champion the "functional output" of a computer program might dismiss it, but typically copyright law proceeds by considering computer programs as literary works. Particularly if there is no source code for Rybka evinced, the "Occam's Razor" conclusion from a data/code equivalence here seems likely to infringe copyright -- though if so, this then leads to yet another question, that of the overall "percentage" of this element in whole Rybka/Fruit framework (again for copyright aspects, not for chess-strength ones).

[Uly]

I apologize if I cannot keep up with other posts or threads in this forum.

It's BB+'s fault for replying to people on the wrong forum.

[hyatt]

Why would _anybody_ reply to someone on the Rybka forum? I think BB's judgement there is impeccable...

As for me? I'm obviously deranged...

BTW, as far as the two pieces of code to produce the same PST values? so what? First, who knows what kinds of iterations Fabien went through before arriving at the set of 8x8 multipliers for ranks? I can think of several different ways I have experimented with these values, so that his code might have made perfect sense. And who in their right mind, once they settle on something that produces good results, would go back and optimize / rewrite a piece of code that takes zero time, and is executed only once at start-up? Who'd want to debug something that is completely wasted???

[Uly]

I think BB's judgement there is impeccable...

Really? What would you think if I, instead of replying to you here like I'm doing, posted my reply at the Hiarcs Forum, and then blamed you for missing it/taking too long to answer?

It doesn't work. If you have something to say about some post, you post the comment in the forum it was posted.