And maybe even a few will read it sceptically (as it ought to be, even if I weren't an "unknown")...Maybe some of those people will read it, too!
![Laughing :lol:](./images/smilies/icon_lol.gif)
![Rolling Eyes :roll:](./images/smilies/icon_rolleyes.gif)
And maybe even a few will read it sceptically (as it ought to be, even if I weren't an "unknown")...Maybe some of those people will read it, too!
I refer to footnote 2, bottom page 1: Just to recapitulate, this means I am largely going to avoid GPL and/or copyright issues. As the PDF was largely addressed to the ICGA, I considered "originality" in a sense closer to theirs than to copyright law. This may very well differ with the FSF/Fabien complaint/lawsuit.Alan Sassler wrote: By Banned for Life (Silver) Date 2011-03-07 09:01Mark's document is an interesting read, but it really shows only that Vas was very familiar with many of the ideas in Fruit and made good use of them. There is no discussion of other engines where these same techniques might be used, nor is there much discussion about copied or transliterated code. [...] In my opinion, this is not a strong argument for violation of either copyright or GPL.Jeremy Bernstein wrote: By sockmonkey (**) [de] Date 2011-03-07 08:20
Wait, are you saying that you've been going on and on about this, hair-splitting this, relativizing that, without having read any of the evidence that's been presented thus far?
I think there is conflation of licensing and copyright here. See the discussion of Muller (and others) on TalkChess. The "interface" issue is one of copyright, not licensing. To sum up the linked discussion, the Gnu GPL grants a licensed right under certain circumstances for a person to do various things that would otherwise fall under copyright law. If one breaks the license, the licensed right to do such things disappears -- the person might still possess such a right under a different heading (such as "fair use"). Going further, the Gnu GPL does not seem to be "severable" -- that is, it grants a license to a distribution as a whole, and not on a file-by-file or function-by-function basis. Violating the GPL by re-using interface code is just as much a violation as re-using any other part, whereas for copyright it is correct that issues of interfacing and/or de minimis can become relevant. Regarding the cessation of rights upon violation of the license, this seems to be the most relevant section.Alan Sassler wrote:The only exception to this is the UCI parser code, but this is clearly in the interface category, and interface software has different rules, at least here in the US.
Furthermore, it does not seem to me that the example displayed in Appendix A regarding the iterative deepening code can easily be considered "interface" code.Free Software Foundation wrote:5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it.
Well, I'd rather be many other places than this...Alan Sassler wrote:For the remainder, you would basically be falling back on a totality of the evidence argument, which is not where you want to be.
As indicated in the last paragraph of 1.1, page 1: this document is fundamentally incapable of anticipating even legitimate explanations of the evidence here enumerated (in other words, I present prima facie evidence and leave any affirmative defenses for others to submit -- note that such defenses typically reverse the burden of proof). Also, I am unable to find any discussion with Anthony regarding Strelka that possesses much of what I would call substantive -- I will try again later why I am less busy with other things.Alan Sassler wrote:In defense, Vas could explain why he used each of the enumerated ideas, along with many, many others, in building the engine (see for instance, his discussion with Anthony regarding Strelka). To the extent that Vas could authoritatively put these ideas into a much broader framework (as he did with Anthony), the totality argument looks pretty flimsy.
Here is the only Rybka forum post I could find from Rajlich that was directed principally to Cozzie:Alan Sassler wrote:In defense, Vas could explain why he used each of the enumerated ideas, along with many, many others, in building the engine (see for instance, his discussion with Anthony regarding Strelka). To the extent that Vas could authoritatively put these ideas into a much broader framework (as he did with Anthony), the totality argument looks pretty flimsy.
http://rybkaforum.net/cgi-bin/rybkaforu ... ?pid=39198Vasik Rajilch wrote:Osipov's speculation is not correct. Rybka is and always was completely original code, with the exception of various low-level snippets which are in the public domain.
Rybka's scores are minimax score - they are propagated up the search tree. In principle, they should be from the tip of the PV, but because Rybka takes the PV from the hash table, this may not always be the case.
Re. depth, this is simply a tool to drive the iterative search. By conventional I mean 'in the normal range.
However, I still seem not to be finding any post from Rajlich that enumerates many ideas in Rybka.Vasik Rajilch wrote:I've taken a look this morning at the Strelka 2.0 sources. The picture is quite clear.
Vast sections of these sources started their life as a decompiled Rybka 1.0. The traces of this are everywhere. The board representation is identical, and all sorts of absolutely unique Rybka code methods, bitboard tricks and even exact data tables are used throughout. [...]
The author did at first make attempts to hide the Rybka origins, for example by masking the table values in earlier Strelka versions. He also made significant attempts to improve the program. The attempts at improvement are not very original, but they are everywhere. They include PV collection, null verification (and in fact changes to the null implementation itself), some endgame drawishness heuristics, a handful of new evaluation term, a new approach to blending between opening and endgame eval terms, and so on. They also do include various structural changes, such as knight underpromotions, on-the-fly calculations of many tables, the setting of piece-square table values, etc. These changes are extensive and no doubt lead to differences in playing style and perhaps a useful engine for users to have, but they do not change the illegality of the code base. [...]
I agree that, for the purposes of plagiarism, the evaluation feature overlap is the most notable. I might also point out that neither Dailey nor Kaufman have made any secret regarding Komodo, while Rajlich might have done better to say: "... and took many things, such as using essentially the same evaluation features, the PST building scheme [...]"Alan Sassler wrote:Usually you lead with your best stuff, so lets take a more careful look at the first item. There are a large number of possible features, and apparently R1B uses the same subset as Fruit. Coincidence? Not likely. But is this out of bounds?
Before we make a decision, let's look at another case with similar evaluation features, i.e. R3H and Komodo. Both have evaluation functions designed by Larry Kaufman.
BB+ wrote:I agree that, for the purposes of plagiarism, the evaluation feature overlap is the most notable. I might also point out that neither Dailey nor Kaufman have made any secret regarding Komodo, while Rajlich might have done better to say: "... and took many things, such as using essentially the same evaluation features, the PST building scheme [...]"Alan Sassler wrote:Usually you lead with your best stuff, so lets take a more careful look at the first item. There are a large number of possible features, and apparently R1B uses the same subset as Fruit. Coincidence? Not likely. But is this out of bounds?
Before we make a decision, let's look at another case with similar evaluation features, i.e. R3H and Komodo. Both have evaluation functions designed by Larry Kaufman.
Finally, and to the crux of the above quotation, I am not convinced that Komodo and R3H have "similar evaluation features", particularly as much overlap as Fruit 2.1 and Rybka 1.0 Beta . I started to enumerate the Komodo 1.0 personality features versus things in Rybka 3, but this seemed a bit unwieldy (see below). Maybe I should just choose one piece type and be complete.
For instance, referring to the listed features in Komodo 1.0 personalities, and to Rybka 3:
*) pmob: R3 has this, but only on the opposite side of the opposing king - is it the same in Komodo?
*) nmob: In R3, the mobility is safe square and forward, and doubly forward moves get an additional bonus - is it the same in Komodo?
*) bmob: In R3, the mobility calculation is quite complicated -- depending on the quadrant, one considers the pawn skeleton in one direction or the other, and there is an additional forward bonus - is it the same in Komodo? Does Komodo have x-ray/pin bonuses in general? [R3 even has a king safety element here].
*) rmob: See bmob.
*) ropen/rhalf: In R3, there is another adjustment if the file is blocked by a (guarded) opposing minor - does Komodo have this?
*) qmob: R3 has safe-square mobility (as always) with an additional forward bonus.
*) blockedopen: "backward pawn that is blocked or inhibited" -- not sure there is anything quite like this in R3, though see "pbkwd" below
*) kppdist: R3 has this, though I'd have to check details about "distance" (forward rank versus backward rank, and file). I recall also there is a funky "path" array [you'd have to see it to understand] to compute distance from a king to enemy pawns (with the minimum taken IIRC) -- does Komodo have something like this?
*) ntabm/btabm/rtabm/qtabm/ktabm: these are all PST scalings, which I ignore here
*) luftp: R3 has this in essence
*) ksarea/ksdefm/ksattm: these seem too vague to explicate much
*) pthreat: R3 has not only this, but a general "good attacks" bonus (when a lesser piece attacks a greater in value)
*) outpost: R3 has no rook outposts. The details would also need comparison [R3 has a square based bishop bonus, and the same for knights with an additional bonus if near the enemy king], e.g. an "outpost" in R3 just means a piece guarded by a friendly pawn.
*) minorbehind: likely the same in R3/Komodo
*) rook7th: R3 has a different criterion (king on 7th/8th or pawns on 7th), a 6th rank bonus, an 8th rank bonus, and a doubled majors on 7th bonus - does Komodo have the same?
*) pdoubled: likely the same - although R3 has a square-based value array, the contents are constant.
*) predundant: "number squares attacked by pawns" - not sure R3 has this
*) islands: likely the same
*) isoh/isoo: likely the same
*) pbwkd: R3 splits into half-open/closed files for the bonus here
*) ppinc: R3 has something like this, but it's a bit vague
*) ptabm/nwp/bwp/rwp: these would all be in PST or the material imbalance table, which I am ignoring here
*) hmb: maybe R3H has this, but don't think R3 had this in eval, though there was a "tempo" adjustment upon doing null move and with "stand-pat" in qsearch IIRC.
Here are some more things in R3, about which the Komodo situation seems unclear.
*) Queen attacks opposing piece not guarded by a pawn (including an opposing king(!), it seems)
*) Queen on 7th
*) Bishop attacks opposing pawn not guarded by pawn
*) Bishop attacks opposing knight not guarded by pawn (attacking rooks/queens is in "good attacks")
*) Trapped bishops (I'm guessing Komodo has this?) and same with trapped rooks.
*) Rook attacks opposing pawn not guarded by pawn
*) Penalty for knight three squares orthogonally from enemy bishop
*) Penalty for knight two squares diagonally from enemy king
*) Bonus for knight on a colour that no enemy bishop can attack
*) Knight attacks opposing pawn not guarded by pawn
*) Knight attacks opposing bishop, extra bonus if not guarded by pawn
*) Bad bishops (I'm sure that Komodo has it - but is the method the same, or at least similar?)
*) Various pawneval considerations (pawn on long diagonal of king, central blocked pawns with respect to shelter, etc.)
It may very well be that Komodo contains a lot of these, but they are not in the personality file.
Alan Sassler wrote:Before we make a decision, let's look at another case with similar evaluation features, i.e. R3H and Komodo. Both have evaluation functions designed by Larry Kaufman.
There had been a number of comments that I should (say) investigate all engines from tournament X, for completeness. While this seems a bit outlandish to me, in this particular case Alan Sassler mentioned a specific pair, and the work was not too difficult, so I found it reasonable to comment.Ben Stoker wrote:Komodo? Now Komodo is getting sucked into the vortex of BB+ Chess Engine Metaphysics.
Seems to me that then the ICGA does nothing... not sure I can say more than that? [And do I really need a contingency plan for this?]Contingency planning: what happens if ICGA does NOTHING?
The latest version (among other things) makes a crude stab at quantifying evaluation feature overlap. Some might dispute the methodology in general. Others might want more details on my specific numerology . And if I wrote many pages about that, the argument could then shift to saying that I was just one expert (or perhaps a clown with good document formatting skills). In any event, I would opine that the evidential burden regarding evaluation features is now on those who claim that the Rybka/Fruit overlap is nothing extraordinary.hopefully a new PDF version will emerge either today or tomorrow
Thanks, I meant to increase this value some time ago. It's now 1MB.BB+ wrote:As the PDF now exceeds the 256k file limit, I bzipped it first.