PST of Fruit 2.1 and Rybka 1.0 Beta

[hyatt]

1. Telling people at Rybka forum: just look at the Zach document folks and compare the PST code left (Fruit) with the code right (Rybka) and see how they match. WILLFUL misleading because Bob KNOWS that code is not in Rybka at all.

pretty much a waste of time responding, but you are right. I told them to look at Zach's document, which has this on page one, paragraph one of the PST part:

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.

I suppose I made a mistake when I actually expected someone to READ that?

Dishonest. Very dishonest. I mean, to expect one to actually READ the section I told them to read? How unrealistic is that?

2. Telling people at Rybka forum: folks listen, what's the chance that 10 tables with each 64 numbers are 100% EQUAL? Bob knows better huh? Nevertheless, here is one of his quotes:

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"

Dishonesty, manipulation of the innocent reader.

For what?

--------------------------------------------------

Imader,
orgfert,

Interesting thing is you both ignored the above but went different ways instead.

Anyway, you asked for an explanation why I ignore Bob here, now you know.

An additional advantage is I only have to argue with Bob on just one forum

Take care.

[orgfert]

Interesting thing is you both ignored the above but went different ways instead.

Your policy of ignoring rebuttals encourages me to not waste the effort of repeating them (though choosing a "different way" has so far elicited the same mute prolepsis).

[mballicora]

... the PST values can be produced by the fruit initialization code with just a few constant changes, no new code added at all.

Maybe Ed has lost the capacity to understand this simple fact.

A non-fact because it is not true.
It is not a "few", it is "all" the constants were changed. The vectors are kept, and their independent numbers are not that many.
Bob mentions it in this way, and the effect for the casual reader is that they are the same PSTs with few tweaks. No. that is a misrepresentation.

Now you join the Ed redefinition of terms league?

"few": Adj. 1. a few - more than one but indefinitely small in number;

I would think that in the domain of a chess program, that 2 (pawns) + 4 (knights) + 4 (bishops) + 1 (rooks) + 3 (queens) + 3 (kings) is pretty correctly termed "a few". 17 constants out of how many? 16 for each of the above for the rank/file multipliers plus the other constants used in evaluation. I stand by "a few"...

Then you say "ALL". I count 16 per PST that were NOT changed, the constant multiplier vectors... So ALL is wrong for sure, "few" is pretty descriptive and better than saying "a couple"... Certainly "a bunch" is way wrong... so "a few" it is...

Yes, there are "few" parameters, which has been what I was trying to tell you for a long time when you claimed there were "640" numbers. But you say "few changes", which has the connotation of "minimal" changes, which is not true. All the multipliers are changed (21, not 17 if I count correctly) and vectors are not, which I **mentioned** in my sentence. Most of them are repeated and simetrical, which means that what is kept, in terms of independent variables, is lower that what you imply.

Your insinuation that there were "minimal" changes is wrong. The overall mechanism is kept, but the whole thing has been worked out to deliver PSTs that may even work differently. The whole proportionality between squares is not maintained and the relationship between endgame and midgame is completely altered. Not to mention that 3 or 4 (according to how you see it) was TOTALLY changed.

Also, the full quote is
"The PSTS match exactly in a bunch of cases. Pawns match perfectly except for some additional bonuses on a couple of central squares. No one has produced another program that matches like that, where the PST values can be produced by the fruit initialization code with just a few constant changes, no new code added at all."

He keeps mentioning this to beat a strawman. But despite that, I "produced" what he asked.

Miguel

Actually, you didn't quite do that. There was the constant offset that is not in Fruit's code, so that was something that had to be added unless I overlooked something somewhere, not that it is particularly relevant.

I am absolutely shocked (but nothing surprises me now) that *YOU* come with this argument. You know perfectly well that adding the piece values in the PSTs, on top of the positional values is just an optimization trick.

I came to this forum to make sure I gave my perspective, so if the people disagree, they do it for the right reasons, not because I was not clear. I think I did the best I could and I going to wind this down.

Miguel

Could that explain all of his rambling about it? Maybe he isn't creating all of these ridiculous arguments with the intent to be mischievous, but really just doesn't get it. It may be that he can't understand it, and so it seems to him that it is fraught with all kinds uncertainty.

[mballicora]

It is not a "few", it is "all" the constants were changed. The vectors are kept, and their independent numbers are not that many.

Right, so constant offsets were added. And that's your case for these being more than non-trivially different? Really??

Lar

I was no trying to make a case in this post. I was using it to correct Bob in one of his many exaggerations and distortions.
Of course, I have been trying to make a point, which involves a bigger picture, but it is elaborated in detail in other forums and other posts in this forum. It was analyzed here so I came to comment on that.

Miguel

[hyatt]

... the PST values can be produced by the fruit initialization code with just a few constant changes, no new code added at all.

Maybe Ed has lost the capacity to understand this simple fact.

A non-fact because it is not true.
It is not a "few", it is "all" the constants were changed. The vectors are kept, and their independent numbers are not that many.
Bob mentions it in this way, and the effect for the casual reader is that they are the same PSTs with few tweaks. No. that is a misrepresentation.

Now you join the Ed redefinition of terms league?

"few": Adj. 1. a few - more than one but indefinitely small in number;

I would think that in the domain of a chess program, that 2 (pawns) + 4 (knights) + 4 (bishops) + 1 (rooks) + 3 (queens) + 3 (kings) is pretty correctly termed "a few". 17 constants out of how many? 16 for each of the above for the rank/file multipliers plus the other constants used in evaluation. I stand by "a few"...

Then you say "ALL". I count 16 per PST that were NOT changed, the constant multiplier vectors... So ALL is wrong for sure, "few" is pretty descriptive and better than saying "a couple"... Certainly "a bunch" is way wrong... so "a few" it is...

Yes, there are "few" parameters, which has been what I was trying to tell you for a long time when you claimed there were "640" numbers. But you say "few changes", which has the connotation of "minimal" changes, which is not true. All the multipliers are changed (21, not 17 if I count correctly) and vectors are not, which I **mentioned** in my sentence. Most of them are repeated and simetrical, which means that what is kept, in terms of independent variables, is lower that what you imply.

Your insinuation that there were "minimal" changes is wrong. The overall mechanism is kept, but the whole thing has been worked out to deliver PSTs that may even work differently. The whole proportionality between squares is not maintained and the relationship between endgame and midgame is completely altered. Not to mention that 3 or 4 (according to how you see it) was TOTALLY changed.

Also, the full quote is
"The PSTS match exactly in a bunch of cases. Pawns match perfectly except for some additional bonuses on a couple of central squares. No one has produced another program that matches like that, where the PST values can be produced by the fruit initialization code with just a few constant changes, no new code added at all."

He keeps mentioning this to beat a strawman. But despite that, I "produced" what he asked.

Miguel

Actually, you didn't quite do that. There was the constant offset that is not in Fruit's code, so that was something that had to be added unless I overlooked something somewhere, not that it is particularly relevant.

I am absolutely shocked (but nothing surprises me now) that *YOU* come with this argument. You know perfectly well that adding the piece values in the PSTs, on top of the positional values is just an optimization trick.

I came to this forum to make sure I gave my perspective, so if the people disagree, they do it for the right reasons, not because I was not clear. I think I did the best I could and I going to wind this down.

Why do you overlook the obvious:

Actually, you didn't quite do that. There was the constant offset that is not in Fruit's code, so that was something that had to be added unless I overlooked something somewhere, not that it is particularly relevant.

So you are "shocked" that "I don't think it is particularly relevant?" I simply pointed out that for fruit/rybka, the numbers all start at zero. Mine do not. Again, "I don't consider that particularly relevant, just a detail."

Miguel

Could that explain all of his rambling about it? Maybe he isn't creating all of these ridiculous arguments with the intent to be mischievous, but really just doesn't get it. It may be that he can't understand it, and so it seems to him that it is fraught with all kinds uncertainty.

You've made your opinion quite clear. I just don't agree with it. You propose that Vas developed those PST values independently of Fruit. I do not believe that is a rational explanation. Why? All the other copied code. But suddenly, after copying fruit's eval, he generates his own PST values (which would be pretty dangerous when copying someone else's code. And they just, serendipitously, end up "right close" to fruit's and can be produced by Fruits initialization code by just changing those multipliers? I'm a believer of Occam's Razor thinking here, and Occam's Razor doesn't point to your explanation at all. It is simply much more likely that when he copied other code, he copied the PST initialization at the same time.

[mballicora]

... the PST values can be produced by the fruit initialization code with just a few constant changes, no new code added at all.

Maybe Ed has lost the capacity to understand this simple fact.

A non-fact because it is not true.
It is not a "few", it is "all" the constants were changed. The vectors are kept, and their independent numbers are not that many.
Bob mentions it in this way, and the effect for the casual reader is that they are the same PSTs with few tweaks. No. that is a misrepresentation.

Now you join the Ed redefinition of terms league?

"few": Adj. 1. a few - more than one but indefinitely small in number;

I would think that in the domain of a chess program, that 2 (pawns) + 4 (knights) + 4 (bishops) + 1 (rooks) + 3 (queens) + 3 (kings) is pretty correctly termed "a few". 17 constants out of how many? 16 for each of the above for the rank/file multipliers plus the other constants used in evaluation. I stand by "a few"...

Then you say "ALL". I count 16 per PST that were NOT changed, the constant multiplier vectors... So ALL is wrong for sure, "few" is pretty descriptive and better than saying "a couple"... Certainly "a bunch" is way wrong... so "a few" it is...

Yes, there are "few" parameters, which has been what I was trying to tell you for a long time when you claimed there were "640" numbers. But you say "few changes", which has the connotation of "minimal" changes, which is not true. All the multipliers are changed (21, not 17 if I count correctly) and vectors are not, which I **mentioned** in my sentence. Most of them are repeated and simetrical, which means that what is kept, in terms of independent variables, is lower that what you imply.

Your insinuation that there were "minimal" changes is wrong. The overall mechanism is kept, but the whole thing has been worked out to deliver PSTs that may even work differently. The whole proportionality between squares is not maintained and the relationship between endgame and midgame is completely altered. Not to mention that 3 or 4 (according to how you see it) was TOTALLY changed.

Also, the full quote is
"The PSTS match exactly in a bunch of cases. Pawns match perfectly except for some additional bonuses on a couple of central squares. No one has produced another program that matches like that, where the PST values can be produced by the fruit initialization code with just a few constant changes, no new code added at all."

He keeps mentioning this to beat a strawman. But despite that, I "produced" what he asked.

Miguel

Actually, you didn't quite do that. There was the constant offset that is not in Fruit's code, so that was something that had to be added unless I overlooked something somewhere, not that it is particularly relevant.

I am absolutely shocked (but nothing surprises me now) that *YOU* come with this argument. You know perfectly well that adding the piece values in the PSTs, on top of the positional values is just an optimization trick.

I came to this forum to make sure I gave my perspective, so if the people disagree, they do it for the right reasons, not because I was not clear. I think I did the best I could and I going to wind this down.

Why do you overlook the obvious:

Actually, you didn't quite do that. There was the constant offset that is not in Fruit's code, so that was something that had to be added unless I overlooked something somewhere, not that it is particularly relevant.

So you are "shocked" that "I don't think it is particularly relevant?" I simply pointed out that for fruit/rybka, the numbers all start at zero. Mine do not. Again, "I don't consider that particularly relevant, just a detail."

Yours? who's talking about yours?

Miguel

Could that explain all of his rambling about it? Maybe he isn't creating all of these ridiculous arguments with the intent to be mischievous, but really just doesn't get it. It may be that he can't understand it, and so it seems to him that it is fraught with all kinds uncertainty.

You've made your opinion quite clear. I just don't agree with it. You propose that Vas developed those PST values independently of Fruit.

No... this is really frustrating.

Miguel

I do not believe that is a rational explanation. Why? All the other copied code. But suddenly, after copying fruit's eval, he generates his own PST values (which would be pretty dangerous when copying someone else's code. And they just, serendipitously, end up "right close" to fruit's and can be produced by Fruits initialization code by just changing those multipliers? I'm a believer of Occam's Razor thinking here, and Occam's Razor doesn't point to your explanation at all. It is simply much more likely that when he copied other code, he copied the PST initialization at the same time.

[hyatt]

At least we finally agree on something. I believe Vas copied the PST values directly from fruit via the pst initialization code, after changing the constants to scale what he considered to be appropriately due to material value differences. You have been arguing against that from the get-go, which puts you in the "he discovered these independently" camp in this argument. If that is not where you are, then why are you arguing from that perspective?

I believe that in light of all the other copying that was done, this is simply following the principle of Occam's Razor, as it is the simplest and most obvious explanation...

[mballicora]

At least we finally agree on something.

No, we don't.

I believe Vas copied the PST values directly from fruit via the pst initialization code, after changing the constants to scale what he considered to be appropriately due to material value differences.

Clearly, that is not what happened.

You have been arguing against that from the get-go, which puts you in the "he discovered these independently" camp in this argument.

No, I am not in any of your made-up strawman camps.

Miguel

If that is not where you are, then why are you arguing from that perspective?

I believe that in light of all the other copying that was done, this is simply following the principle of Occam's Razor, as it is the simplest and most obvious explanation...

[lmader]

No... this is really frustrating.

At least we finally agree on something.

I think Bob was agreeing with the frustration.

I believe Vas copied the PST values directly from fruit via the pst initialization code, after changing the constants to scale what he considered to be appropriately due to material value differences.

This is a provably possible scenario - Rybka's PST values can be recreated exactly as this describes.

Clearly, that is not what happened.

Good answer. Just tell him he's wrong, no need to back that up. Because CLEARLY this is not what happened. What makes this so clear?

So what did happen? What is the scenario that you envision that is more plausible than the above? Can you explain this concisely without a bunch of obfuscation?

Lar

[mballicora]

No... this is really frustrating.

At least we finally agree on something.

I think Bob was agreeing with the frustration.

I believe Vas copied the PST values directly from fruit via the pst initialization code, after changing the constants to scale what he considered to be appropriately due to material value differences.

This is a provably possible scenario - Rybka's PST values can be recreated exactly as this describes.

For the record, because you are coming late to the discussion, they can be recreated in other ways too.

Clearly, that is not what happened.

Good answer. Just tell him he's wrong, no need to back that up. Because CLEARLY this is not what happened. What makes this so clear?

All the ratios intra and inter PSTs (endgame and midgame) have been changed. Numbers were tuned, not adjusted to material values. Zach thinks that too. 3 Tables are plain different, so CLEARLY, they were not following the sentence "...changing the constants to scale what he considered to be appropriately due to material value differences".
You have to look at the numbers yourself and it is obvious.

So what did happen? What is the scenario that you envision that is more plausible than the above? Can you explain this concisely without a bunch of obfuscation?

Lar

http://www.open-chess.org/viewtopic.php ... 565#p13565

Miguel