Ideas versus Implementations

Code, algorithms, languages, construction...
User avatar
Rebel
Posts: 515
Joined: Wed Jun 09, 2010 7:45 pm
Real Name: Ed Schroder

Re: Ideas versus Implementations

Post by Rebel » Thu Apr 26, 2012 11:36 am

Chris Whittington wrote: You simply place Vas and any other young programmer into a Catch 22 bind. Fruit and maybe other strong open sources essentially chose a sub list from your "47" possible evaluation features on the basis of most popular. Vas also chose most popular plus a few others. The LIST of eval features can't be copyrightable or protected for this reason else all programmers would be forced to choose a sub-optimal (based on crowd popularity) listing. The analogy with a Lincoln speech is nonsense, of course a speech which could be composed of any mix of 200,000 words is plagiarised/copied at the level you propose. Of course a chess evaluation function which would be composed from 47 (your number) of sub components where some sub components are both highly used/popular and vital to the functionality, is in no way comparable. One is a small subset of a huge list, the other a large subset of a small list where inclusion or not is pre-ordained.

You then Catch 22 the targeted culprit on the basis that any differences between implementations of sub-features (most of which are formulaic) are "translations". GUILTY! If it's the same, he copied. If it's different he translated and copied. Catch 22.

But, of course, as Sven Schule showed on talkchess with reference to mobility functions, the implementations are way more likely in fact to be original writes. The functionality appears similar because it is formulaic.

In summary: the function list is not free choice, nor is each individual implementation. Your COMPEVAL appears to imagine contrarily that subfunction choice is random, and implementation choice is wide. Both of your assumptions are false.
Here is a question, you want to write an evaluation function and you take Rebel's EVAL [ http://www.top-5000.nl/authors/rebel/chess840.htm#EVAL ] as your inspiration then what have you done?

1. non-literal copying ?

2. taking idea's legally ?

3. Allowed to play in ICGA tournaments ?

User avatar
Chris Whittington
Posts: 437
Joined: Wed Jun 09, 2010 6:25 pm

Re: Ideas versus Implementations

Post by Chris Whittington » Thu Apr 26, 2012 6:22 pm

Rebel wrote:
Chris Whittington wrote: You simply place Vas and any other young programmer into a Catch 22 bind. Fruit and maybe other strong open sources essentially chose a sub list from your "47" possible evaluation features on the basis of most popular. Vas also chose most popular plus a few others. The LIST of eval features can't be copyrightable or protected for this reason else all programmers would be forced to choose a sub-optimal (based on crowd popularity) listing. The analogy with a Lincoln speech is nonsense, of course a speech which could be composed of any mix of 200,000 words is plagiarised/copied at the level you propose. Of course a chess evaluation function which would be composed from 47 (your number) of sub components where some sub components are both highly used/popular and vital to the functionality, is in no way comparable. One is a small subset of a huge list, the other a large subset of a small list where inclusion or not is pre-ordained.

You then Catch 22 the targeted culprit on the basis that any differences between implementations of sub-features (most of which are formulaic) are "translations". GUILTY! If it's the same, he copied. If it's different he translated and copied. Catch 22.

But, of course, as Sven Schule showed on talkchess with reference to mobility functions, the implementations are way more likely in fact to be original writes. The functionality appears similar because it is formulaic.

In summary: the function list is not free choice, nor is each individual implementation. Your COMPEVAL appears to imagine contrarily that subfunction choice is random, and implementation choice is wide. Both of your assumptions are false.
Here is a question, you want to write an evaluation function and you take Rebel's EVAL [ http://www.top-5000.nl/authors/rebel/chess840.htm#EVAL ] as your inspiration then what have you done?

1. non-literal copying ?
You've written a manual and offered it for free reading. Anyone can freely use that information to write a program. If you had included source and asserted some sort of appropriate copyright, that still does not stop someone extracting a "manual" out of that and then freely using that information on a how-to-make-a-chess-program basis. The person would have to write their own code and use their own weights.
2. taking idea's legally ?
of course, you offered the information and ideas to the public to use.
3. Allowed to play in ICGA tournaments ?
Why would anyone want to do that? Fewer and fewer do, it costs a lot of money, time and travel and there's a severe danger of being attacked if you are successful.

hyatt
Posts: 1242
Joined: Thu Jun 10, 2010 2:13 am
Real Name: Bob Hyatt (Robert M. Hyatt)
Location: University of Alabama at Birmingham
Contact:

Re: Ideas versus Implementations

Post by hyatt » Thu Apr 26, 2012 8:45 pm

Rebel wrote:
Chris Whittington wrote: You simply place Vas and any other young programmer into a Catch 22 bind. Fruit and maybe other strong open sources essentially chose a sub list from your "47" possible evaluation features on the basis of most popular. Vas also chose most popular plus a few others. The LIST of eval features can't be copyrightable or protected for this reason else all programmers would be forced to choose a sub-optimal (based on crowd popularity) listing. The analogy with a Lincoln speech is nonsense, of course a speech which could be composed of any mix of 200,000 words is plagiarised/copied at the level you propose. Of course a chess evaluation function which would be composed from 47 (your number) of sub components where some sub components are both highly used/popular and vital to the functionality, is in no way comparable. One is a small subset of a huge list, the other a large subset of a small list where inclusion or not is pre-ordained.

You then Catch 22 the targeted culprit on the basis that any differences between implementations of sub-features (most of which are formulaic) are "translations". GUILTY! If it's the same, he copied. If it's different he translated and copied. Catch 22.

But, of course, as Sven Schule showed on talkchess with reference to mobility functions, the implementations are way more likely in fact to be original writes. The functionality appears similar because it is formulaic.

In summary: the function list is not free choice, nor is each individual implementation. Your COMPEVAL appears to imagine contrarily that subfunction choice is random, and implementation choice is wide. Both of your assumptions are false.
Here is a question, you want to write an evaluation function and you take Rebel's EVAL [ http://www.top-5000.nl/authors/rebel/chess840.htm#EVAL ] as your inspiration then what have you done?

1. non-literal copying ?

2. taking idea's legally ?

3. Allowed to play in ICGA tournaments ?

You didn't provide enough information. For example, when I decided to eliminate Blitz version V, which was a major program (>100K lines of fortran) and go to a chess 4.x-like simple iterated search, I read Frey's book carefully (the chapter by Slate). But Slate gave no code. And wrote at a fairly abstract level. If one wrote with his chapter in front of them, they would not be writing a clone of chess 4.x, because there were very few implementation details in the chapter.

I have not looked at what Ed wrote. But I suspect that he did not give implementation details. If that is true, I would not see any form of copying being done that would be counter to ICGA rule 2. If he gives actual source code, then one can go too far in copying same, of course.

If you look at the chapter I wrote in the book Schaeffer edited, "Computers, Chess and Cognition" I gave a lot of details about the Cray Blitz evaluation, but no implementation details, just a fairly complete enumeration of chess concepts that it evaluated. I would not see any issue if someone took that, and wrote an evaluation, I would not see any problems. But in looking at the book right now, I notice that for pawn scoring, I did get very specific about the conditions being tested, in chess terms, but not in programming terms. One could argue that given the description I gave, there is only only one way to write the code so that two programs could look very similar if derived from that specific book chapter. But then I look at the Cray Blitz source, and notice that the implementation details are very different from the very abstract explanation given in the book, and realize that such an argument is wrong, because there are clearly several different ways of implementing a (even) simple chess concept. We did things incrementally back then that I do not do incrementally today. So even things that are "common" between CB and Crafty don't look the same even though at an abstract chess level, they are similar (backward pawn, anyone?)

The issue we have here (the rybka/fruit case) is that the codes simply match up so well, testing the same things, in the same way, with the same quirky ways of adding bonuses or subtracting them back out, and such, that it is not very plausible to suggest independent development.

What would be interesting, would be to have 5 or 10 different programmers write an eval that comes directly from Ed's description, or my description in the above book, and then compare them to see how similar they look. Be a significant loss of time so it is not very likely to happen, but it might prove enlightening for everyone to finally see how a very specific description still produces significantly different implementations.

User avatar
Chris Whittington
Posts: 437
Joined: Wed Jun 09, 2010 6:25 pm

Re: Ideas versus Implementations

Post by Chris Whittington » Fri Apr 27, 2012 8:00 pm

hyatt wrote: The issue we have here (the rybka/fruit case) is that the codes simply match up so well, testing the same things, in the same way, with the same quirky ways of adding bonuses or subtracting them back out, and such, that it is not very plausible to suggest independent development.
Yes, we understand your position. You wish to suggest that your "matches", such as they are, and they are not "source or any other code" matches btw, do the "same" things, and, when they don't "do the same things" that is because they were copied and altered(!!); and in the "same way", except when they don't when you blame that on the abstracted data structure and "alteration" (again). Which then leaves you grasping at "quirks" which would be fine if you didn't call provably the most efficient implementations as "quirks".

Catch 22. If it's the same he copied it. If it's different he copied it and changed it.

I refer you to the Sitwala post: with sufficient abstraction you can prove diamond and coal to be identical. With sufficient abstraction Mr Watkins could give the diamond-coal pair a matching value of 1.0, but that would only be because he ignored and threw away the abstracted differences, would it not? Now there's a thought. Should the metrication of similarity/difference of any subfunction pair (to be used to incriminate another programmer for copying) re-include the thrown away abstractions, or not?

User923005
Posts: 616
Joined: Thu May 19, 2011 1:35 am

Re: Ideas versus Implementations

Post by User923005 » Fri Apr 27, 2012 9:54 pm

There are lots of things that everyone copies and they do it in a very similar way.
Null move, Zobrist hashing, pvs search, LMR, etc. look about the same in everyone's program. Sure, they have to modify these concepts to work with their own data structures and probably have to tweak them a bit to get them to work right in their frameworks, but the fingerprints are unmistakable and obviously everyone borrows these sorts of ideas if they want their program to beat other programs in a contest.

This does not seem to bother anyone very much, despite the fact that they make the program play much, much more powerfully. The branching factor of a program (if we are trimming off the right things and not the wrong things) is dominantly more important than the evaluation terms. A chess program with a branching factor near 2 and a very modest evaluation will thrash any program with a branching factor of 6, not matter how clever the evaluation might be.

With the evaluation terms, some people get their bun in a knot even though these same evaluation terms are found in any good beginner's chess book (See, for instance, the series by Yasser Seirawan found here: http://www.amazon.com/s?ie=UTF8&field-a ... wan&page=1). There is literally no mystery to any chess evaluation term and no invention either. All of them are laid out before us like food items at a smorgasboard. Or does someone here imagine that they invented king safety or bad bishops or closed centers?

Now, use of similar evaluation terms will not lead to enormous strength differences, despite the countless hours spent honing these terms into perfection. I think it would be a wonderful experiment to contrast the simple eval of Olithink with the evaluation of (say) Ivanhoe by simply adding Ivanhoe's eval to Olithink without changing anything else about the search. I bet the Elo raises less than 100 points.

If it is illegal to use other people's chess ideas in your program if they make your program play stronger, then it is illegal. Rip them out and write every chess idea from your own brain without using someone else's idea or concept. If it is not wrong to share these ideas then share them and use them.

Now, it is wrong to steal things. There are clear license terms to many software packages and these license terms are clear enough so that we should not have much ambiguity about right and wrong when it comes to using these things properly. However, I do think that if we are going to accuse someone of license violation it should be handled properly in a court of law so that a bunch of amateurs do not spoil someone's good name because his actions violate their personal, magical standards.

I also implore chess programmers not to take the lazy way out and simply copy/paste with other people's hard work (calling it their own without giving credit where credit is due). Not only should this approach be unsatisfying, but it is also deplorable.

IMO-YMMV

syzygy
Posts: 148
Joined: Sun Oct 16, 2011 4:21 pm

Re: Ideas versus Implementations

Post by syzygy » Fri Apr 27, 2012 11:54 pm

BB+ wrote:
syzygy wrote:From the point of view of copyright I would say these are still concepts / ideas / algorithms. You can (and do) phrase them in terms of chess pieces and ranks, not in terms of any concrete board representation. The way you express them in natural language is probably protected, but I am free to express them in my own words in natural language (or in source code). (Maybe this is helpful: do you consider that your precise natural language descriptions of the various evaluation features are protected by the copyright on Fruit and/or Rybka?)
As Letouzey put the Fruit issue: copy with different words if you like, similar to a translation.
I have underlined the word copyright, not because it would be my opinion that Rule 2 is about copyright, but because the discussion always seems to go back to copyright. If we talk about copyright, then what Loutezey thinks is not so important, because he is (probably) not an expert in copyright law. The fact that he feels (on second thoughts) that his "intellectual property" has been infringed does not imply that there was a copyright violation. Copying of technical ideas can easily give one this feeling, but is not a copyright violation.

You did not answer my question whether you consider that your detailed description in natural language of the Fruit evaluation features is protected by the copyright on Fruit.
I find the Rybka re-expression of the Fruit expressions typically to fall rather close to translation in this sense. I'm also not sure what role the concrete board representation has? I would say it's like choosing what font to use when printing a file -- there is already suitable expression in the text itself.
Ok, you are not reasonable either. Further discussion does not seem useful.
BB+ wrote:Again I find this rather categorical. Many computer programs (such as video games) have aspects beyond the mere "functional"
I'll just note that you took the video game example from me. The video game concept is not protected by the copyright source code, but may itself be a protected work. See e.g. C-393/09.

hyatt
Posts: 1242
Joined: Thu Jun 10, 2010 2:13 am
Real Name: Bob Hyatt (Robert M. Hyatt)
Location: University of Alabama at Birmingham
Contact:

Re: Ideas versus Implementations

Post by hyatt » Sat Apr 28, 2012 2:53 am

Chris Whittington wrote:
hyatt wrote: The issue we have here (the rybka/fruit case) is that the codes simply match up so well, testing the same things, in the same way, with the same quirky ways of adding bonuses or subtracting them back out, and such, that it is not very plausible to suggest independent development.
Yes, we understand your position. You wish to suggest that your "matches", such as they are, and they are not "source or any other code" matches btw, do the "same" things, and, when they don't "do the same things" that is because they were copied and altered(!!); and in the "same way", except when they don't when you blame that on the abstracted data structure and "alteration" (again). Which then leaves you grasping at "quirks" which would be fine if you didn't call provably the most efficient implementations as "quirks".

Catch 22. If it's the same he copied it. If it's different he copied it and changed it.

I refer you to the Sitwala post: with sufficient abstraction you can prove diamond and coal to be identical. With sufficient abstraction Mr Watkins could give the diamond-coal pair a matching value of 1.0, but that would only be because he ignored and threw away the abstracted differences, would it not? Now there's a thought. Should the metrication of similarity/difference of any subfunction pair (to be used to incriminate another programmer for copying) re-include the thrown away abstractions, or not?

I think we have been quite clear. The ONLY differences we chose to ignore were those differences dictated by the board representation differences. One asks a chess question in a clear and concise way to a chess player. A programmer will take that specific question and implement it according to what he has to work with. One can actually, if they REALLY want to, write a bitboard program that looks almost identical to the mailbox program. It would not be efficient, and it would ignore one of the major advantages of bitboards, that ability to work with a set of squares as opposed to a single square in an array.

I don't see where this is a hard comparison to make, although for someone that is either not familiar with mailbox board representation (or bitboard representation) it might be difficult to conduct a meaningful comparison. I simply choose to look at the questions asked in the mailbox implementation, and compare them to the questions asked in the bitboard representation. I've repeatedly said that not all eval terms are created equally, using a single concept like backward pawns. Is it worse on an open file? What if there are no rooks, why would the file matter? Etc. So the basic idea is straightforward, but no one implements the chess knowledge in a simple and straightforward way, because it becomes (a) too slow and (b) is not accurate enough to provide high-level play.

I found it interesting to look at my chapter in the Schaeffer book the other day when Ed posed his hypothetical. I have my own ideas about how a "passed pawn race" (or sometimes called a freepawn or whatever else) ought to be done. In Crafty, I chose to do what I did in Cray Blitz, such as handling queening with check, or attacking the other side's queening square, location of kings that might provide support, and such. There's no "single global recipe" for that evaluation. At one of the ACM events, Larry Kaufman was there with Don (*Socrates) and he had created a set of chess positions that he fed into various chess programs and used the time-to-solution to produce a pretty good Elo estimation. Except for Cray Blitz, which solved every one of 'em in 0 seconds and blew his formula. We discussed positions at length, and he had several that were based on this particular type of ending and he was astounded that we did all the things a human would do to decide which side was winning. He thought it would be far too slow to be doable. And he was likely right on a micro. But not on a big vector box like the Cray. I included what I thought was doable, in a way that was not too expensive (some done incrementally during MakeMove(), some done at endpoint evaluations, and ended up with an implementation that I have yet to see duplicated, even though the simple "square of the pawn" is well known and covered early in Fine's book. The degrees of freedom in analyzing that specific concept is amazing. And that's the key to most evaluation terms. The concepts are often well-understood, until you look at the implementation details and notice the variability between different programs for the same basic bit of chess knowledge...

I can't imagine any comparison that would conclude diamond and coal are identical, unless you want to look at an individual atom. I don't think anyone wants to abstract that far away from things to compare anything. Otherwise you just get "both do passed pawns, both do backward pawns, both do isolated pawns, and such." I don't think ANY of us considered that interesting. How the evaluation terms were done was what we looked at. Were they both doing exactly the same comparisons (using different board representations). Did they check the same squares, the same conditions, the same piece interactions, etc? That was the crux of the analysis. And there was far more matching between Fruit and Rybka than between any other pair of programs examined, which is very difficult to explain away as "luck."

hyatt
Posts: 1242
Joined: Thu Jun 10, 2010 2:13 am
Real Name: Bob Hyatt (Robert M. Hyatt)
Location: University of Alabama at Birmingham
Contact:

Re: Ideas versus Implementations

Post by hyatt » Sat Apr 28, 2012 2:56 am

syzygy wrote:
BB+ wrote:
syzygy wrote:From the point of view of copyright I would say these are still concepts / ideas / algorithms. You can (and do) phrase them in terms of chess pieces and ranks, not in terms of any concrete board representation. The way you express them in natural language is probably protected, but I am free to express them in my own words in natural language (or in source code). (Maybe this is helpful: do you consider that your precise natural language descriptions of the various evaluation features are protected by the copyright on Fruit and/or Rybka?)
As Letouzey put the Fruit issue: copy with different words if you like, similar to a translation.
I have underlined the word copyright, not because it would be my opinion that Rule 2 is about copyright, but because the discussion always seems to go back to copyright. If we talk about copyright, then what Loutezey thinks is not so important, because he is (probably) not an expert in copyright law. The fact that he feels (on second thoughts) that his "intellectual property" has been infringed does not imply that there was a copyright violation. Copying of technical ideas can easily give one this feeling, but is not a copyright violation.

You did not answer my question whether you consider that your detailed description in natural language of the Fruit evaluation features is protected by the copyright on Fruit.
I find the Rybka re-expression of the Fruit expressions typically to fall rather close to translation in this sense. I'm also not sure what role the concrete board representation has? I would say it's like choosing what font to use when printing a file -- there is already suitable expression in the text itself.
Ok, you are not reasonable either. Further discussion does not seem useful.
BB+ wrote:Again I find this rather categorical. Many computer programs (such as video games) have aspects beyond the mere "functional"
I'll just note that you took the video game example from me. The video game concept is not protected by the copyright source code, but may itself be a protected work. See e.g. C-393/09.

I think the discussion eventually rolls around to copyright, because if one proves a copyright infringement, then there is no way to skirt around the obvious rule 2 violation that would prove. Proving copyright in this case is problematic from the get-go, as previously mentioned, because of the necessary differences in board representation. But that does NOT mean copyright infringement can't be proven at all, it just means it is a complex issue, nothing more or less.

BB+
Posts: 1484
Joined: Thu Jun 10, 2010 4:26 am

Re: Ideas versus Implementations

Post by BB+ » Sat Apr 28, 2012 5:26 am

syzygy wrote:You did not answer my question whether you consider that your detailed description in natural language of the Fruit evaluation features is protected by the copyright on Fruit.
To the extent that the description determines the evaluation features [and that there are no filtration issues], I would say yes. As an analogy, let's say that I have a logo [as an artistic work, not as a trademark]. A natural language description might be rather inspecific, such as: it is generally wedge-shaped, with three pointy triangles coming out the top, and a saucer-like disk in the lower-right -- there's also about 10 small dots/stars in a wave-like pattern running from lower-middle to middle-right. Or it could be rather pedantic: there is a 240 degree wedge of radius 5cm oriented south, with three protruding isosceles triangles of sizes [...]. The latter might still not be quite so completely expressed as something like Postscript code, but tends more to expression than the former. Similarly, if the evaluation features were sufficiently generic ("Rooks on 7th"), there would be no argument, but the comparison made was at a much finer level. [And as I say, all the above ignores filtration issues for now]. Suppose, then, you take the detailed logo description such as above, and from this reexpress it on a T-shirt, while also making it 125% as large, rotated by 30 degrees, and green/white instead of red/blue. Depending on how perfectly the detailed description was followed, you could still have (say) something that an outside observer would perceive as sufficiently similar (the questions of whether size, orientation, and colour scheme play a part of the artistic content would obviously also be relevant). If you want to go back to computer programs, cleanroom descriptions should not be overly specified to the extent that they produce a substantially similar work (in this regard, one reason why the cleanup of OSCAR was deemed legitimate is that functionality dictated much of the similarities).
syzygy wrote:
BB+ wrote:I find the Rybka re-expression of the Fruit expressions typically to fall rather close to translation in this sense. I'm also not sure what role the concrete board representation has? I would say it's like choosing what font to use when printing a file -- there is already suitable expression in the text itself.
Ok, you are not reasonable either. Further discussion does not seem useful.
I think I am essentially following the abstractions test for literary works. If I write a novel, the underlying story (one abstraction level up) is also subject to copyright. In some cases (depending how generic the story is, for instance), you would not be free to realise the same story as a motion picture, without infringing copyright. Similarly, using something akin to translation, and then claiming this is re-expressing the "idea" behind source code seems to me to be misapplying the word "idea".
syzygy wrote:
BB+ wrote:Again I find this rather categorical. Many computer programs (such as video games) have aspects beyond the mere "functional" [quotation truncated here -- it continued] though I admit the most copyrightable aspects therein are often shunted out to audiovisual and/or user-experience considerations.
I'll just note that you took the video game example from me.
I was actually recalling my own post (at the very bottom), though this itself was merely quoting Altai concerning Stern/Kaufman: See Stern Electronics, Inc. v. Kaufman, 669 F.2d 852, 855 [213 USPQ 443] (2d Cir. 1982) (explaining that an audiovisual works copyright, rather than a copyright on the underlying program, extended greater protection to the sights and sounds generated by a computer video game because the same audiovisual display could be generated by different programs). Your truncation of my quotation in particular scrubbed the word "audiovisual" which appears in the above citation (but not in your post).

EDIT: Hmm, it seems that I might also have been remembering an earlier part of that same post, where I quoted Midway/Bandai, again on audiovisual considerations. In fact, reading this again, the court opinion addresses the "overly specified idea" question, so I will quote it here:
Midway v. Bandai wrote:Audiovisual works such as these are primarily unprotectable games. Atari, 672 F.2d at 617. As the Seventh Circuit noted, however, the particular forms in which they are expressed — "shapes, sizes, colors, sequences, arrangements, and sounds" — add something beyond the mere game idea. Id. Thus, "The audio component and the concrete details of the visual presentation constitute the copyrightable expression of that game `idea'". Id. Nonetheless, Bandai argues that any similarities between its games and Midway's are nonactionable since they result from an allegedly inevitable connection between the expressions and the similarities in the underlying unprotectable ideas.
Bandai's position fails as a matter of law. It assumes, sub silentio, that the idea of Midway's Galaxian game actually includes the physical characteristics of the characters involved. If such reasoning were accepted, a copyright defendant could always avoid liability merely by describing a plaintiff's work in great detail and then labeling that description the "idea" of plaintiff's work. The "idea" of any work could always be defined in such detail that the description of the expression would add nothing to the "idea", thus allowing a defendant to engage in all but verbatim copying. Such a ploy cannot be allowed. As the Krofft court noted, the description of the work for the purpose of identifying its idea must be a simple one. [...]

User avatar
Rebel
Posts: 515
Joined: Wed Jun 09, 2010 7:45 pm
Real Name: Ed Schroder

Re: Ideas versus Implementations

Post by Rebel » Sat Apr 28, 2012 11:48 am

Chris Whittington wrote:
hyatt wrote: The issue we have here (the rybka/fruit case) is that the codes simply match up so well, testing the same things, in the same way, with the same quirky ways of adding bonuses or subtracting them back out, and such, that it is not very plausible to suggest independent development.
Yes, we understand your position. You wish to suggest that your "matches", such as they are, and they are not "source or any other code" matches btw, do the "same" things, and, when they don't "do the same things" that is because they were copied and altered(!!); and in the "same way", except when they don't when you blame that on the abstracted data structure and "alteration" (again). Which then leaves you grasping at "quirks" which would be fine if you didn't call provably the most efficient implementations as "quirks".

Catch 22. If it's the same he copied it. If it's different he copied it and changed it.
And about "quirks"

Fruit quirks
1. The 2 step evaluation
2. The quad function
3. Float based time control
4. Only one evaluation table (king safety)

Rybka quirks
1. Pawn value of 3200
2. Losing 20% of blitz games on time.
3. Lacking any knowledge about standard endgames, can not even mate the KBNK ending.

None of the above 4 Fruit oddities
Chris Whittington wrote:I refer you to the Sitwala post: with sufficient abstraction you can prove diamond and coal to be identical. With sufficient abstraction Mr Watkins could give the diamond-coal pair a matching value of 1.0, but that would only be because he ignored and threw away the abstracted differences, would it not? Now there's a thought. Should the metrication of similarity/difference of any subfunction pair (to be used to incriminate another programmer for copying) re-include the thrown away abstractions, or not?
I never gave Mark's COMP_EVAL much attention. At best (VIG) it can only indicate that Vasik modelled his EVAL to Fruit's. It can not proof copying. Free idea's how to create an evaluation function voluntarily put on the Internet by Fabien himself. That's not cloning but learning and coding what you have learned.

But to comment on the above I think for a more fair comparison a subtraction of 0.2 point for each MB/BB eval term is in place. Somehow the Rybka investigators were able to undermine Rybka's MAIN unburden evidence (a bit-board engine) into a disadvantage that greatly worked against Vas. If there is a difference between Fruit and Rybka blame it on the bit-boards and the difference magically disappears. I think that's pretty unfair.

Post Reply