What do you folks make of this ?

[BB+]

No need for me, it's clear enough.

In any case, I would rather have a more complete reference document of exactly what the Rybka/Fruit claims are, rather than just a endless slew of postings to parse.

It is forbidden to change, split, disassemble or produce any changed form of this product.

This seems closer to the Galoob/Nintendo case with the Game Genie. The definitive phrase from that decision is: Having paid Nintendo a fair return, the consumer may experiment with the product and create new variations of play, for personal enjoyment, without creating a derivative work. This doesn't address the further issues of hackers and/or intellectual property.

My impression is that the validity of your disclaimer would likely depend on whether it is part of a license (which is essentially imposed on the user, as often they buy the product w/o knowledge of what the license says, and returning it afterwards is nontrivial), or could be construed as part of a contract (which would deem that there was some agreement between the buyer and seller).

From various statements Vas has made it seems that the entire Rybka engine is now produced in this way (autogenerated).

Yes, I get the same picture. He has mentioned [though I can't find it now] a impressive amount of "helper code" he has written with the Rybka project. I don't really think it was obfuscation, just his (rather odd) development technique.

[Harvey Williamson]

My impression is that the validity of your disclaimer would likely depend on whether it is part of a license (which is essentially imposed on the user, as often they buy the product w/o knowledge of what the license says, and returning it afterwards is nontrivial), or could be construed as part of a contract (which would deem that there was some agreement between the buyer and seller).

This statement is interesting in the case of Hiarcs and Junior as you can download the entire product before you buy an activation code which allows the engine to play at full strength. So it could be argued that a customer should read the licence before they purchase.

[Rebel]

It is forbidden to change, split, disassemble or produce any changed form of this product.

This seems closer to the Galoob/Nintendo case with the Game Genie. The definitive phrase from that decision is: Having paid Nintendo a fair return, the consumer may experiment with the product and create new variations of play, for personal enjoyment, without creating a derivative work. This doesn't address the further issues of hackers and/or intellectual property.

My impression is that the validity of your disclaimer would likely depend on whether it is part of a license (which is essentially imposed on the user, as often they buy the product w/o knowledge of what the license says, and returning it afterwards is nontrivial), or could be construed as part of a contract (which would deem that there was some agreement between the buyer and seller).

I knew I was finishing in troubled juridical water but I thought that creating an obstacle wouldn't hurt and could scare hackers enough.

I don't really think it was obfuscation, just his (rather odd) development technique.

Just name one advantage. There must have been.

Ed

[BB+]

I think the point again is that the relative scaling is exactly the same, even to the matching of the output of the quad() function of Fruit.

I had the audacity to recheck the evidence, and found that the Rybka table-values for the 10-30-60-100 scaling do not exactly match the output of quad(), but instead come from truncation as (Bonus[]*(max-min))/256 rather than rounding (there is still the curious 26-77-154-256 item, though).

[Uly]

I don't really think it was obfuscation, just his (rather odd) development technique.

Up to this date he clearly obfuscates his depth and node count, I don't see why wouldn't he obfuscate his code too.

[BB+]

Just name one advantage. There must have been.

Could is simply be that "being more familiar with X" would be the main advantage? Maybe he just imitated the development methods from the "military-oriented research outfits" where he had worked.

[Chris Whittington]

Needless to say, I do not accept your statistics about ordering of functions. Technically you may be correct, but in terms of interdependency and human behaviours, you are not.

I tend to agree with this. For instance, maybe some guide like "How Computers Play Chess" used one ordering, and many others simply imitate it. A similar case could be Zobrist keys: more than one person might have decided to use some algorithm from Knuth or Marsaglia to get a bunch of random numbers (there is still some question of how to order them, though).

I don't agree with this based on one issue, I have looked at the source for several chess engines that are available, and they simply don't do the same things in the same order using the same approach, which is what Chris/I were discussing. Hard to compare code between a bitboard and mailbox board representation, but one can look at A and make a very good determination about whether B came from A or is original.

I think this topic is worthy of a another thread actually.

My claim is that your "functional equivalence" is a catch-all to use to condemn all witches. Just to see if we can get some sort of consensus - never known with Bob since 1995 .........

..... let's switch to the module genmoves. there's little or no creativity, the outputs are defined pretty much by the rules of chess. Let's suppose, I, Muggins, write another chess program. What's to stop Bob and Zach claiming my genmove module is "functionally equivalent" to Crafty (no matter whether I wrote in BB or 0x88 did it by lookuptable), and not only functionally equivalent at a module level, but also at a host of sub levels. rhetorical question and the answer is there's nothing to stop them, because indeed what I write will be functionally equivalent, whether I based it on Crafty code or not.

They got me. *If* "functional equivalence" is a valid concept for copy detection. Hence, obviously, it can't be.

Actually, it will be down to data (knight offsets say, if 0x88) and ordering of sub functions, and/or ordering of the resultant move list. Won't it? The "functional equivalence" will be neither here nor there. Although, if I random up the data and the move ordering, Zach report will say "the mover order has been randomised to obfuscate the result".

Now, a further leap, that Bob will argue with no doubt - the ordering (above, whether of moves or sub-functions) contains no information, no chess AI, no nothing - it's irrelevent. So, how could I 'copy' something that contains NO information, or, if I did, so what? Doesn't make any difference to the program ultimately.

So, now we're down to data. But just how protected is a list of knight offsets? Not at all. How protected is the ordering of a list of knight offsets? It's an irrelevent big deal, makes no difference to the AI, and contains no information.

Bob/Zach's line appears to be that the quantity makes up for the lack of quality in each case. The whole picture they say. But in the final analysis, even if there's some data match, how to demonstrate that the different code (and back to Rybka case, it is different code) was written by copying or written independently? You have a pointer to suspicion in some of the data, but no proof at all in the code - functionally equivalent or not.

[BB+]

What's to stop Bob and Zach claiming my genmove module is "functionally equivalent" to Crafty (no matter whether I wrote in BB or 0x88 did it by lookuptable), and not only functionally equivalent at a module level, but also at a host of sub levels. rhetorical question and the answer is there's nothing to stop them, because indeed what I write will be functionally equivalent, whether I based it on Crafty code or not.

I think you need to specify this better, for at least to me, "functional equivalence" means that the the output from a given input is identical. It also depends upon whether sorting is done inside of movegen or not. Finally, to borrow from IPPOLIT/Rybka, the "move" might have more information that just the move. For instance, the to-from order, flags for promotion, use of (say) the upper 16 bits of a 32-bit datatype for MVV/LVA or SEE purposes, etc. There is a wide panoply of ways one can vary things here, and yet still have the same "functional equivalence" of generating moves in an unspecified order.

So movegen with a given ordering constraint is well-posed, but otherwise is not. Additionally, appending scores for sorting need not be sufficient to make this sensible, as ties can still occur (for instance, Nb1xRc3 and Na2xRc3 -- which goes first in the move list? Is this is matter merely for the sorting function, or is the sorting implementation dependent on the original order of "tied" entries?). There was a thread awhile back about multiple "mate-in-1" positions as a way of detecting engine similarities, particularly in movegen ordering.

How protected is the ordering of a list of knight offsets? It's an irrelevent big deal, makes no difference to the AI, and contains no information.

I've always tried to steer clear of what "protected" means, choosing my standard of comparison rather to be that which I would expect to be used in computer chess competitions to detect derivatives and/or multiple entries. Historically this standard is quite exacting. For instance, if you used Ed's exact REBEL knight array for move ordering, I can't say that you would pass the "originality" test. This is what the REBEL.pdf gives, though the lack of symmetry makes me think that a transcription error might have occurred.

Code: Select all

00 10 20 20 20 10 10 00
10 24 26 26 26 24 24 10
10 28 40 50 50 28 28 10
10 23 36 40 40 23 23 10
10 22 28 30 30 22 22 10
00 26 26 30 30 26 26 00
05 20 20 23 20 20 20 05
00 05 15 15 15 15 00 00

..... let's switch to the module genmoves. there's little or no creativity, the outputs are defined pretty much by the rules of chess.

Except in the case of various underpromotions.

[Chris Whittington]

What's to stop Bob and Zach claiming my genmove module is "functionally equivalent" to Crafty (no matter whether I wrote in BB or 0x88 did it by lookuptable), and not only functionally equivalent at a module level, but also at a host of sub levels. rhetorical question and the answer is there's nothing to stop them, because indeed what I write will be functionally equivalent, whether I based it on Crafty code or not.

I think you need to specify this better, for at least to me, "functional equivalence" means that the the output from a given input is identical. It also depends upon whether sorting is done inside of movegen or not. Finally, to borrow from IPPOLIT/Rybka, the "move" might have more information that just the move. For instance, the to-from order, flags for promotion, use of (say) the upper 16 bits of a 32-bit datatype for MVV/LVA or SEE purposes, etc. There is a wide panoply of ways one can vary things here, and yet still have the same "functional equivalence" of generating moves in an unspecified order.

So movegen with a given ordering constraint is well-posed, but otherwise is not. Additionally, appending scores for sorting need not be sufficient to make this sensible, as ties can still occur (for instance, Nb1xRc3 and Na2xRc3 -- which goes first in the move list? Is this is matter merely for the sorting function, or is the sorting implementation dependent on the original order of "tied" entries?). There was a thread awhile back about multiple "mate-in-1" positions as a way of detecting engine similarities, particularly in movegen ordering.

How protected is the ordering of a list of knight offsets? It's an irrelevent big deal, makes no difference to the AI, and contains no information.

I've always tried to steer clear of what "protected" means, choosing my standard of comparison rather to be that which I would expect to be used in computer chess competitions to detect derivatives and/or multiple entries. Historically this standard is quite exacting. For instance, if you used Ed's exact REBEL knight array for move ordering, I can't say that you would pass the "originality" test. This is what the REBEL.pdf gives, though the lack of symmetry makes me think that a transcription error might have occurred.

Code: Select all

00 10 20 20 20 10 10 00
10 24 26 26 26 24 24 10
10 28 40 50 50 28 28 10
10 23 36 40 40 23 23 10
10 22 28 30 30 22 22 10
00 26 26 30 30 26 26 00
05 20 20 23 20 20 20 05
00 05 15 15 15 15 00 00

..... let's switch to the module genmoves. there's little or no creativity, the outputs are defined pretty much by the rules of chess.

Except in the case of various underpromotions.

Bob/Zach have claimed functional equivalence in the CODE even when the outputs have been different (eg weights different).This is very dangerous imo. I think the expression used was "functionally equivalent but with different weights" even implied or wrote on occasion "functional equivalent but weights changed or order changed for obfuscation reasons". It's a ducking stool for witches, guilt already assumed, guilty whatever.

[Rebel]

It is NOT unusual for the purpose of jumping out of search and returning to the root. Ed used it, I used a more primitive version of it until I got hassled by support programmers, one of my programmers used it and refused to stop using it. Bob really can't claim use of setjmp() means copying, or that the code around it means copying, because the code around it is quite likely forced anyway.

Just re-reading this thread. Chess programmers do anything for optimizations, even the smallest. The simple logic is that many small ones will produce a good speed increase as final result.

Here is one of my crazy ones, against all rules, but in EVAL I used the EBP and even the ESP register as always available counters and/or ESP register for updating the score.

Instead of:

INC    [counter in memory] into
INC    EBP

or instead of:

ADD    [score in memory], EAX
ADD    ESP,EAX

Small speed-up's........ crazy code.