PST of Fruit 2.1 and Rybka 1.0 Beta

[orgfert]

Unlike you, I fight for the truth, you fight to win whatever the truth. I hate that.

Unfair, IMO. Like most probably believe about you, reasonable people suspect Bob is wholly convinced of the truth of his position. You could at least extend to him what you grant to yourself, that you fight for what you have convinced yourself of is the truth. Naturally, it is not automatically unfair to question whether the things someone has convinced himself of are actually and objectively true and I suspsect this is your actual view of Bob. So to suggest openly that Bob knows he is wrong and is only interested in some kind of polemical autointoxication is lacking in charity -- an emotional response from frustration rather than reason.

The impression is very strong that you are lately (these past few years) "fallen" into the orbit of partisans and grenade throwers -- principally that person known for his talent for recruiting "innocents" into his jesuitical machinations. His influence on you appears tangible, dragging you into contentious imbroglios born of sedulous back-channel whispering campaigns (FUD being the main ingredient). This influence seems to have found its voice for example in the dismissive and condescending treatment of BB+, who by my estimate outclasses you by at least two brains and who exhibits more "Christian Spirit" than just about anyone on any forum on the internet. Ironically that's what used to be said about you.

[Rebel]

Rebel wrote:
Unlike you, I fight for the truth, you fight to win whatever the truth. I hate that.

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

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.

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?

[hyatt]

Ed, that argument is bogus. Why? The FIRST paragraph of the Zach document (concerning the PSTs) states unequivocally that the code is not in Rybka. Yet you want to keep making that argument. I have explained a dozen times that Zach had two choices. Either run the fruit PST code and dump the output (as I have done many times now) and show that side-by-side with the rybka numbers, which is VERY difficult to discern the pattern between them, or else, take the fruit PST initialization code, modify the constants, and show that it produces the Rybka numbers exactly (except for a square or two here and there that were hand-tuned after the fact. He had no other choice.

However, further on in the document, there IS code from both. Yes, you want to argue that you can't compare asm to C. You can argue that POV all you want. It is wrong. It has been wrong from the beginning. SO there IS side-by-side comparison of code. Just read a little further. My favorite is the 0.0 bug, but there are plenty of other examples sitting there. And, of course, Rybka 1.6.1 can't be refuted at all, so you want to just ignore that example as some nonsensical test case, even though it was sent to be tested in ChessWars. You have an excuse for every situation, whether the excuse makes any sense to a rational person or not really doesn't matter it seems...

Which is probably closer to the truth? "The PSTs match exactly" or "1.6.1 was never distributed, never competed in a tournament, has nothing to do with the ICGA, and should be ignored?"

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.

You talk about my statements, when you REALLY should be looking at your own. Because YOURs are made KNOWING they are completely false. Mine was wrong for a very few squares that were explicitly hand-tuned after the fact. Key question is, which statements are MORE accurate, mine or yours? No contest...

[orgfert]

Rebel wrote:
Unlike you, I fight for the truth, you fight to win whatever the truth. I hate that.

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

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.

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?

You accused Bob of taking ideas from Vas to add 400 Elo points to crafty. Was this because you studied crafty and found the ideas inside? Or was it because someone whispered it in your ear? Your character having sufferred from that transpicuous attack, you have continued to cast about for others. There is a theological name for a mingy accuser. Take care you aren't becoming one.

[lmader]

... 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. 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.

[hyatt]

No idea. I will be the first to admit that I am not as "mentally sharp" as I was 20-30 years ago. So we all lose "something" with age. Some more than others. However, THIS case is not that complicated...

[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.

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

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.

[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...

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.

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.

[lmader]

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

[Rebel]

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.

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.