OpenChess

Hello to All,


To Jeremy, you say: "Can we please de-escalate? We're in the process of taking care of the situation. Please don't make it worse."
Well, could you start first and restore my ability to use colors LIKE ANYBODY ELSE, if it is not too much to ask?!! That would be a step in the right direction. Especially when I consider you as the person who canceled my right to use colors in my posting LIKE ANYBODY ELSE!

ALL of you have NOT read the source code of Rybka's chess programs and yet you dare making the completely false and highly defamatory accusations against Rybka's programmer Vasik Rajlich. Could you have the decency to stop accusing people falsely when you do not have the facts to support your false claims?!!

What this thread proves is that very few among you are ready to accept different points of view than yours! And you are all living in democratic countries but you still find a way to want to behave very undemocratically on the Internet! This shameful behavior has to change and you have to learn to accept that others will not have the same points of view than yours. I do but not when I am censored for false and dishonest reasons!

WHEN I HAVE A POINT OF VIEW, I BASE IT ON FACTS, NOT ON RUMORS FROM PEOPLE WHO HAVE A HIDDEN AGENDA!! The facts are clear: NO ONE has read Rybka's source code of Rybka's chess engine programs! Yet, many have started a campaign of defamation against Rybka's programmer Vasik Rajlich, a guy who has contributed so much to improving the state of the art of chess engine programs that he simply has no equal except one at the moment!

When someone has a different point of view than yours, you invent false reasons and you dare asking the blind moderators to censor this person's posting! That what happened to me in this thread. So desperate you are that you even ask the moderators to cancel my ability to use colors! I know you are very black and white people but not all are like you! This behavior is very unfair and very undemocratic, especially on a forum whose web site is called "OPEN"-chess.org!!

This idea that one would shout because he uses capitals is completely ludicrous! I am fully aware that it is a (false) belief very widely held on the Internet by many but, when there is no other means to highlight words, capitals are what is left to highlight important points and it should NOT be considered as a way to shout!

The completely irrelevant ICGA "World Computer Chess Championships" are dead! That is the reality as of today. It started last year in 2010 when Rybka 4.0 did not even make the effort of participating at the completely irrelevant World Computer (Chess) Software Championship (WCSC)!! Again, and I will keep repeating it many times, there are a few reliable and trustworthy chess engine rating lists that I have clearly indicated in my past posts. And there is now THE TCEC TOURNAMENTS THAT ARE THE TRUE WORLD COMPUTER CHESS CHAMPIONSHIPS at http://www.tcec-chess.org/ WE DO NOT NEED YOUR RIDICULOUS AND HIGHLY INAPPROPRIATE INQUISITION, ICGA, YOU ARE DEAD!!

The only thing that the ICGA people seem capable of doing for chess engine programming (apart from being a bunch of arrogant and vain academics!!) is to witch-hunt the EXTREMELY FEW best and most talented chess engine programmers, among them Rybka's programmer Vasik Rajlich. And for what benefit to chess engine programs and to chess engine programmers?!!! NOTHING EXCEPT THE ICGA PEOPLE'S VANITY AND ARROGANCE!!
Honestly, blind purists who are desperate to witch-hunt the best chess engine programmers, what on earth do you plan to achieve with this new witch-hunt against those like Vasik Rajlich who should be praised for their amazing accomplishments? Again, NOTHING!!

The ICGA is dead! So is your witch-hunt against the best and talented chess engine programmers who truly did something big to advance the state of the art of chess engine programming! You can get lost getting any tiny bit of source code from the best chess engine programmers after your shameful witch-hunt! A few of them might have been willing to open source their code but, with your ridiculous and defamatory witch-hunt, this prospect is surely over.

FOR THOSE WHO WANT TO SEE IMPROVEMENTS IN THE STATE OF THE ART OF CHESS ENGINE PROGRAMS, WE DO NOT NEED YOU ICGA USELESS AND ARROGANT INQUISITORS!! YOUR WITCH-HUNTS ARE A PURE WASTE OF TIME AND FOR WHAT BENEFITS TO THE ADVANCEMENT OF THE STATE OF THE ART OF CHESS ENGINE PROGRAMS? NONE!


Best Regards to All (except the inquistors from ICGA!),
MichaelIsGreat

Michael I think you must understand that you do not pay to post on this forum.

Just like going out and playing when you were a kid. If you didn't return home for dinner mom might not let you go out again the next day. Also just want you to note that I did not read a single one of your posts. Instead of making points with the colors it seemed to me to be one garbled mess. The same way a teenage girl would post.

Not trying to offend, only hope to offer my opinion on the matter.

it seems to be necessary to clarify a few misunderstandings:

This always seems to be a burden.

*) I am not on the Secretariat of the Panel [Bob, Harvey, Mark Lefler], but merely on the Panel (which has many members, some of whom signed the open letter, and some of whom did not, and is open firstly to ICGA members, and more generally to other approved programmers and useful people).
*) The Panel itself is not invested with any deliberative power, but only to advise the ICGA.
*) Conflict of interest is almost impossible to remove completely, but I certainly expect the ICGA to try to minimise its effects (whether or not they care about the perception of such conflict of interest is a different question).
*) As Tord said, the primary issue is not copyright or GPL per se (though they are related), but the tournament rules of the ICGA -- as such, the ICGA itself is eminently qualified to interpret said rules.

Edit: Does anyone know the text of the ICGA rule in question? I can't find it on their site or in the open letter.

http://www.grappa.univ-lille3.fr/icga/e ... .php?id=43

2. Each program must be the original work of the entering developers. Programming teams whose code is derived from or including game-playing code written by others must name all other authors, or the source of such code, in the details of their submission form. Programs which are discovered to be close derivatives of others (e.g., by playing nearly all moves the same), may be declared invalid by the Tournament Director after seeking expert advice. For this purpose a listing of all game-related code running on the system must be available on demand to the Tournament Director.

For a prior interpretation of this, see here.

kingliveson wrote:That is I didn't mention Rybka 3 & 4 source code being released because there's no evidence to suggest Fruit traces. Especially in the case of version 4, prior to its release, the Rybka/Fruit debate was a hot topic -- so I doubt Vas would have been that negligent. Would it have mattered if version 4 was released under the name Bugka 1.0a ?! Just my opinion...

Ah, sorry I misunderstood. FWIW, I haven't noticed extra bugs in R4, though I know they are widely reported. I only use engines for one thing: multi-pv mode in ChessBase to analyze games and openings. I've been doing this with most top engines since Fritz 3, the first Deep Junior (on a dual Pentium II), Shredder, Fruit, all versions of Rybka, Stockfish, Houdini... Rybka has long had problems with multi-pv, and R4 is no exception. Oddly, few people seem to use this mode. I described the bug to Vas and he said "that should be easy to fix" and then didn't seem to do anything about it. But despite its weird hiccups, Rybka still provides a far more stable eval for analysis than Stockfish or Houdini. I should give Critter a try. -Carl

BB+ wrote:2. Each program must be the original work of the entering developers. Programming teams whose code is derived from or including game-playing code written by others must name all other authors, or the source of such code, in the details of their submission form. Programs which are discovered to be close derivatives of others (e.g., by playing nearly all moves the same), may be declared invalid by the Tournament Director after seeking expert advice. For this purpose a listing of all game-related code running on the system must be available on demand to the Tournament Director.

Thanks, BB+.

It seems the language is meant for actions being taken around the time of the tournament, not 5 years later. Levy's panel charter is quite bold in comparison.

For a prior interpretation of this, see here.

80%... of the moves the same? Something the same? A nonstarter in any case. I suggest ELO alone is the best metric available, if binaries are to allowed to compete at all (a questionable practice, given that the point of such prizes is usually to encourage contributions by individuals to the community).

Vas' cluster and versions 2-4 put him in a position to comfortably answer these accusations by publishing the Rybka 1 source. His failure to do so is the most damning "evidence" I see here. -Carl

It seems the language is meant for actions being taken around the time of the tournament, not 5 years later. Levy's panel charter is quite bold in comparison.

The main differences regarding "tournament-time" and 5 years down the road are ones of expediency. During the tournament, "time is of essence", with is one reason why the List situation was concluded in the manner it was. On the other hand, after the tournament, at some point a "statute of limitations" must kick in -- that is, a time frame in which the "source code" can reasonably be expected to be requested. On the third hand, there is the concept that some issues are not bound in time, with the initial clause about originality being one of these.

As for your interpretation that Elo should be a principal metric, I might note that the ICGA has never particularly used "strength" to override other objections to "originality" (in the PDF, I mention the Berliner/Hsu case, which though not ICGA-based IIRC, set a precedent that no code could be borrowed from someone else without permission). There is certainly some "creative spark" involved in making an existing engine better by 100 or more rating points, but it is very difficult to declare it to be the work solely of the one who made the modifications (cf. Each program must be the original work of the entering developers).

80%... of the moves the same? Something the same? A nonstarter in any case.

The rule, as noted by van den Herik says "close" and nothing more, which I would thus construe as a subjective measure dependent on field expertise. I think this is a typical practise in many fields (Gijssen might be happier with a numerical criterion, though I don't see that as a panacea either). In the LION++ case, both the experts agreed that "close" was a suitable word in the given situation. Presumably a "second opinion" could be required/requested in difficult cases. In particular, van den Herik specifically rejects any argument (from the LION++ team or otherwise) that the sum-total of "originality" is determined by the secondary clauses in the rule (such as playing many moves the same).

Furthermore, referring back to the first clauses of the rule, even "non-close" derivatives are only allowed when all authors agree to this. [For instance, with the GridChess/ClusterToga entries, you can see that Letouzey and Gaksch (and Hyatt for the former -- though he had some objections, it seems as though he wasn't going to balk if the ICGA thought the "GridChess" concept was in principle OK, particularly as Crafty was just the "controller" of the system) are listed as authors].

Obviously, any engine playing 100 Elo above another is not "close" by any meaning of the term. -Carl

Obviously, any engine playing 100 Elo above another is not "close" by any meaning of the term. -Carl

Elo is not much of a measure of "closeness" when talking about derivatives. Add null move to TSCP. This gains that at least 100 Elo I suspect, in an effort of about 5-10 lines. Are the resulting engines not "close" in the source code sense? Or add SMP capabilities to (say) Komodo. This will gain 100 Elo, and it will certainly require some work to get the implementation to work, but again no one would say that this is not a "close" derivative of Komodo. So at best one of Komodo and KomodoSMP can enter the event. But back to the point I made before -- this KomodoSMP could not enter at all if the Komodo authors did not grant permission. In particular, the last part of the rule (cannot be close derivatives) is not the totality of the "originality" concept.

If you want another example, Naumov claimed that a bug in his UCI implementation (clearing the hash on every move) cost about 100 Elo -- are Naum UCI and Naum Winboard therefore not "close"?

BB+ wrote:Elo is not much of a measure of "closeness" when talking about derivatives. Add null move to TSCP. This gains that at least 100 Elo I suspect, in an effort of about 5-10 lines. Are the resulting engines not "close" in the source code sense?

Generally speaking, an engine is probably not very good if a trivial change results in a large improvement. There is certainly no reason to think such a change would put it ahead of the rest of the field. But Rybka did achieve this, against Toga, commercial Fruit and all others, for a few years.

This will gain 100 Elo, and it will certainly require some work to get the implementation to work, but again no one would say that this is not a "close" derivative of Komodo.

In software engineering, lines of code is considered a poor measure of programmer performance. At any rate, I hope you realize that you must subject other ICGA contestants to the same BB+ -style derivation analysis in order to obtain a prior for the judgment concerning Rybka...

-Carl

clumma wrote:At any rate, I hope you realize that you must subject other ICGA contestants to the same BB+ -style derivation analysis in order to obtain a prior for the judgment concerning Rybka...

I think that using HIARCS or Shredder for this purpose would be an excellent idea. Of course, it's not my time...

Since the authors of both programs are signatories to the letter, they may well be cooperative with providing source code excerpts or help with deciphering decompiled output...

Jeremy