(warning: a very long post coming)
looking at this masterpiece
https://www.chessprogramming.org/images ... _Fruit.pdf
I can't help myself but that's just embarassing for the lack of a better term...
starting with PSQ: Wegner dismantles his own evidence first by stating
Code: Select all
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
then he gives "pseudocode" with several changes that generates Rybka's bakes PSQ, what a brilliant fallacy - hint: Rybka contains NO PSQ initialization
code, so the pseudocode for Rybka is nothing more than a fabricated fantasy
next comes passer evaluation with a mysterious "quad" function, that's nothing but fixed point linear interpolation with rounding with a fancy name
again - Rybka uses (oh my god, who would have thought that!) a precomputed table that can be generated with a code that, again, isn't present in Rybka at all
unstoppable passer: comparing bitboard-based code that's completely different (again where's the "copied code", hello?)
and almost forgot another hilarious quote:
Code: Select all
To do this we make an approximation of the SEE that is usually equivalent. We simply make
sure that for every square in the promotion path that is attacked by the opponent, we also have a piece defending that
square.
so Fruit uses SEE and Rybka doesn't - how is this even funny, when it's something completely different?
king distance: yes, using a precomputed table [fromsq][tosq] with manhattan distance... who would have thought that having this in your code makes it Fruit-based?!
values: as already stated: precomputed linear ramps with magic constant where Rybka has a fixed table
back to quad aka lerp: does anyone seriously believe that linear interpolation can be covered with GPL as is? in general, GPL violation must imply copying of very large chunks of code, otherwise one could claim that using say for (int i=0; i<n; i++) violates GPL; how do you even know it's the same code when decompiled?!
material: Rybka using a table, basically again Wegner dismantles himself :
Code: Select all
The material tables in Rybka were one of the more interesting features introduced. Their implementation was a new
way to evaluate material imbalances. The indexing and evaluations in the table seem to be unique, but there are some
very interesting similarities in the information stored in the table with Fruit.
another hilarious quotes:
Code: Select all
I will note that all of the formulae for
Rybka's flags have been decoded--since the material table is a large constant array in the Rybka executable, the code
to set the flags is not there. The formulae are found by analyzing the pattern of when it appears in the material table.
Code: Select all
The use of 0x08 for a king safety flag in both programs is certainly interesting, though.
yes, the number 8 is very interesting indeed!
still waiting for copied code
so, Rybka uses a huge material table so again the Rybka "pseudo-code" is not present in the binary either
lazy eval - not in Fruit
phase:
(note: tapered eval - what we all do these days - again the idea is to interpolate opening=>endgame based on non-pawn material)
again, don't see anything special here at all.
as usual:
Code: Select all
Rybka has the same formula as Fruit. There is one important difference though:
so yeah, it's the same except... hilarious!
again, phase is stored in the material table so the "Rybka pseudocode" is a lie again as there's no such code in the binary
pawn evaluation:
pawn hash table, ok... again different in Rybka (surprise)
pawn structure eval: nothing special (common) except that Rybka has bitboards (and a much cleaner and nicer implementation btw) - again I don't see any "copied code"
mobility:
again dismantled by Wegner right at the top:
Code: Select all
The mobility calculations of Fruit and Rybka seem different, but Rybka's turns out to be a simple bitboard
translation of Fruit's.
who'd have thought that for (simple) BB engines you simply compute attack mask and count bits, unless you want something fancy
I don't think this is even funny...
rook on open, semi-open... ok, again BB vs mailbox, rook on 7th: no comment
hilarious quote number xy:
Code: Select all
From looking at the piece evaluation of both engines, we find that they are almost identical.
again, no copied code, just pretty common ideas
king evaluation:
blah blah, common stuff, hilarious quote(tm):
Code: Select all
The weights are different in Rybka of course, but both programs have zero weight for pawns.
that plus bitboards vs mailbox (again), no copied node
I'm already a bit exhausted by reading vast amounts of nonsense but let's finish this...
shelter: 3 files adjacent to king, yeah very "uncommon"... plus something interesting that I don't actually do, hmm... who cares
okay, here he can talk about an idea (not code!), that is assuming the pseudo-code isn't store in table again
shelter values:
Code: Select all
This bonus is different in Rybka, and is simply a table.
I don't know if I should laugh, actually
blah... storm, ok...
Code: Select all
All of this shelter evaluation code in Rybka above is an equivalent; it doesn't appear in the Rybka binary
trapped bishop, blocked bishop, blocked rook:
similar ideas but again mailbox vs BB so I see no copied code
so we have concluded Wegner's evaluation comparison between Rybka and Fruit with the only possible outcome: Wegner proved
that Rybka doesn't contain ANY Fruit code when it comes to evaluation.
I wonder what's comes next... or rather not...
so far I'm quite disgusted and when I said the evidence was trash I think I was actually very mild...