0. What should we do with the WitchFinder General and his entire process when he is caught lying over such a serious matter, saying the PST tables in both programs were identical except for a multiplier constant? A very damaging allegation against Vas which is now shown to be completely untrue?
> "saying the PST tables in both programs were identical except for a multiplier constant"
Do you have a reference for where the accusers said this? (URL, document page number?)
I am assuming that reviewers like Ken Thompson did not do their own hexrays/Ida Pro disassembly and just looked at the available evidence. It would be good to get their opinions if that evidence has changed.
> for non-programmers, this piece of code is basically adding 0 (zero) 64 times into the PST for the king, opening game phase. Very funny. And totally purposeless.
> I do not believe Vas would write code to add zero 64 times in Rybka.
Several of the weights in Fruit are zero:
KnightBackRankOpening = 0;
QueenCentreOpening = 0;
I guess at the time Fruit was programmed, it wasn't known what values might be best, and it turned out that zero was best.
> 384 numbers, chosen one at a time out of a potential sample pool of 2^64 possible 64 bit integers.
Sorry for interrupting, but no sane programmer would want to give a static bonus of 21474836 pawns for a knight on any square ... (and that is still only 32bits and with unit of pawn=100). Your 2^64 is pure BS (sorry). PSQ-table bonuses/penalties out of the range of +- 2 Pawns are just ridiculous and will not work.
Edit: reasonable value is something like 2^8. That is with completely random numbers. Considering common sense (i.e. centralisation idea - knights on center squares are better than knights in the corners) the sensible range becomes considerably tighter. Maybe we are down from number of atoms on earth to number atoms in your glass of whiskey :)
384 numbers, 2^16 choices for each. which is 6 x 2^6 x 2^12 = 3 x 2^18, So the probability of picking one set is 1 in 600,000 or so (1 / (3 x 2^18) to be exact). The probability of two people picking the same weights is 1 / (9 x 2^36) which is getting way on down near zero.
Besides the range, these numbers are not random.
Give me a sample 9 sets of 384 _random_ numbers + 1 set of _real_ piece square tables. Any amateur chess programmer will tell you in a few second which is the real one.
I still consider it impossible for two different programmers to come up with the _same_ set of values...
I have a feeling that it's not that helpful to just copy the tables. The optimum tables for one program are probably very different than the optimum tables for another program.
I think "obfuscation" is the process you want to pull off here...
But it will only work on those that don't have the technical savvy to understand what is going on.
BTW, do you know how many potential piece/square tables there are, when you have 6 pieces x 2 sides x 64 squares x 2^32 (on 32 bit hardware, 2^64 for 64 bit hardware) possible values? Let's see. 2^64 x 2^6 x 2 X 6 comes out to 2^72 x 3 different tables.
Feel free to start enumerating those. And _please_ don't come back until you have them all ready. I'm not sure where you are going to store them, since that number is pretty close to the number of atoms in planet earth, so you might have a small problem.
But then, math never was your strong point, I take it???
However, as I clearly pointed out, none of what you enumerate is copyrightable by itself. Now if you somehow come up with a scheme to produce just 12 X 64 values, and you invest significant effort into creating just that set of values, you can claim copyright. But you missed that point, completely, and go off into the bizarre end of things...
The point being that if you could store one number per atom, a _real_ trick, you need a _really_ big storage device. Just a tad bigger than what could be built here.
I think stronger engines are here for mankinds benefit and we should move past all this muddling.
Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill