Topic Rybka Support & Discussion / Rybka Support / Really About Fruit &Crafty code? Or vehicle for a Ban!
![[zm]](/mwf/v12/flags/zm.png "Zambia")
[quote]Going through the PST's there are a total of ten PST tables that Zach argues are parallel in Fruit/Rybka ....
E and EO ...
as explained elsewhere, the build of the tables depends on the patterns in the ramping arrays, and the evaluation weights applied. The evaluation weights are all different. The ramping arrays, if we accept Zach at face value, are the same.
Whather or not a particular PST pair show multiplicative similarity (ie you can multiply one by a constant to get the other) depends on the build method and whether the PST table is generated by using ONE or TWO DIFFERENT ramping arrays. The first produces the multiplicative similarity. The second does not.
pawns
there is one parallel pair of PSTs. It would show multiplicative matching if the values had not also been hit by a kludge factor. But they were. score 0-1
knights
two parallel pairs of PSTs. One shows multiplicative matching, the other does not. score 1-2
bishops
same situation as knights. score 2-3
rooks
matches. score 3-3
queen
Two parallel tables. One matches, one not. Score 4-4
king
two parallel tables
Neither match. Score 4-6
So a better formulation of the expression "all the PST tables match" would be "four out of the ten PST tables match".
It might have been advisable for you to have said that in the first place rather than use your exaggerated, dissembling untruthful factoids to try and influence people. And the Lord only knows how you tried in other ways to influence people on the hidden form wiki, because you have managed to REDACT the entire record of the wiki forum, so that we can't read it.
It would be even more advisable, and a much fairer methodology, to have concentrated on the ramping arrays which are the true cause of the similarity patterns. The PST tables are reflections of the ramping arrays plus noise from the different weights plus huge amounts of redundancy. The ramping arrays just represent simple formulas and the question then becomes: "are they worthy of copyright status"? A much simpler question. And one in which the complexity can't be used by you to dissemble, quite so easily. [/quote]
Did I miss Bob's reply to this one or is it one of those none technical posts which dont merit a reply?
E and EO ...
as explained elsewhere, the build of the tables depends on the patterns in the ramping arrays, and the evaluation weights applied. The evaluation weights are all different. The ramping arrays, if we accept Zach at face value, are the same.
Whather or not a particular PST pair show multiplicative similarity (ie you can multiply one by a constant to get the other) depends on the build method and whether the PST table is generated by using ONE or TWO DIFFERENT ramping arrays. The first produces the multiplicative similarity. The second does not.
pawns
there is one parallel pair of PSTs. It would show multiplicative matching if the values had not also been hit by a kludge factor. But they were. score 0-1
knights
two parallel pairs of PSTs. One shows multiplicative matching, the other does not. score 1-2
bishops
same situation as knights. score 2-3
rooks
matches. score 3-3
queen
Two parallel tables. One matches, one not. Score 4-4
king
two parallel tables
Neither match. Score 4-6
So a better formulation of the expression "all the PST tables match" would be "four out of the ten PST tables match".
It might have been advisable for you to have said that in the first place rather than use your exaggerated, dissembling untruthful factoids to try and influence people. And the Lord only knows how you tried in other ways to influence people on the hidden form wiki, because you have managed to REDACT the entire record of the wiki forum, so that we can't read it.
It would be even more advisable, and a much fairer methodology, to have concentrated on the ramping arrays which are the true cause of the similarity patterns. The PST tables are reflections of the ramping arrays plus noise from the different weights plus huge amounts of redundancy. The ramping arrays just represent simple formulas and the question then becomes: "are they worthy of copyright status"? A much simpler question. And one in which the complexity can't be used by you to dissemble, quite so easily. [/quote]
Did I miss Bob's reply to this one or is it one of those none technical posts which dont merit a reply?
![[fr]](/mwf/v12/flags/fr.png "France")
By mjlef Date 2011-07-23 20:47
Rybka uses a value of a pawn of 3200 versus Fruits value of 100, so you should expect the Rybka values to be about 32 times bigger than Fruit. So you showing much bigger values is simply deceptive, The PST ration along ranks and files clearly came from Fruit. The probably of mere chance alone having such a perfect match of these is beyond reasonable belief. The sample code presented allowe easier comparison and shows the ration among rows and columns more clearly, and Zach documents and explains this in the PDF if you read the whole thing.
So, please explain how the precise ratios of the piece square tables are the same. Each individual piece square table for each piece type (64 values) are each exactly the same in Rybka as in Fruit times a fixed constant for the whole table (with a couple of pawn entry exceptions). We are talking about 64*6 values here being the same (just multipled by a different scaling value). Any decent programmer would agree the Rybka values were taken from Fruit, and a scaling factor (for the pawn value differences, which could also tune it a bit) applied.
Reply Report
By bob Date 2011-07-23 21:01
We've been through this, up and down, back and forth, inside and out. You are wasting your breath trying to explain something to someone who absolutely refuses to have it explained to them, because they refuse to accept it.
There is little hope you will accomplish anything other than waste a few k bytes of storage on this forum server...
Reply Report
Well, you two, you've had your explanation, not the one you wanted of course, but can you both now explain your statement, bolded above ....
Each individual piece square table for each piece type (64 values) are each exactly the same in Rybka as in Fruit times a fixed constant for the whole table (with a couple of pawn entry exceptions).
Really? You're quite sure about that are you?
Rybka uses a value of a pawn of 3200 versus Fruits value of 100, so you should expect the Rybka values to be about 32 times bigger than Fruit. So you showing much bigger values is simply deceptive, The PST ration along ranks and files clearly came from Fruit. The probably of mere chance alone having such a perfect match of these is beyond reasonable belief. The sample code presented allowe easier comparison and shows the ration among rows and columns more clearly, and Zach documents and explains this in the PDF if you read the whole thing.
So, please explain how the precise ratios of the piece square tables are the same. Each individual piece square table for each piece type (64 values) are each exactly the same in Rybka as in Fruit times a fixed constant for the whole table (with a couple of pawn entry exceptions). We are talking about 64*6 values here being the same (just multipled by a different scaling value). Any decent programmer would agree the Rybka values were taken from Fruit, and a scaling factor (for the pawn value differences, which could also tune it a bit) applied.
Reply Report
By bob Date 2011-07-23 21:01
We've been through this, up and down, back and forth, inside and out. You are wasting your breath trying to explain something to someone who absolutely refuses to have it explained to them, because they refuse to accept it.
There is little hope you will accomplish anything other than waste a few k bytes of storage on this forum server...
Reply Report
Well, you two, you've had your explanation, not the one you wanted of course, but can you both now explain your statement, bolded above ....
Each individual piece square table for each piece type (64 values) are each exactly the same in Rybka as in Fruit times a fixed constant for the whole table (with a couple of pawn entry exceptions).
Really? You're quite sure about that are you?
![[us]](/mwf/v12/flags/us.png "United States")
Don't try to confuse bob with the facts, his mind is made up!
Do they generate the same moves? NO? they're not the same code.
Does "its exactly the same except for all the differences" mean "is exactly the same"?
Do they generate the same moves? NO? they're not the same code.
Does "its exactly the same except for all the differences" mean "is exactly the same"?
Topic Rybka Support & Discussion / Rybka Support / Really About Fruit &Crafty code? Or vehicle for a Ban!
Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill