chrisw wrote:Zach,Zach Wegner wrote:Gerd,
Thank you for your interest. This kind of posts are what we need: calm, objective observations.It is certainly strong evidence. Unfortunately nobody seems to take it as "evidence".UCI 'go' parser seems the strongest point so far.Yes, at this point, the semantics are the same. It is a plausible order, i.e. it makes sense, but it is just rare to have the exact same order. The most important points here IMO are the setjmp, the limit depth, and the lookup hash move. Not many engines do a hash probe before starting with iterative deepening.Looks like a plausible order to me - except probably Setjmp
Of course you need to generate moves before ordering them
Does 150 have the same semantics in Fruit and Rybka 1.0 beta, e.g. centipawns?
Yes, these things might be "typical". But very few engines use them. I am merely trying to accumulate such low level similarities. As of yet, I haven't found any such similarities with any other engine I am aware of.Might be quite common as well - since you always fetch both game stages simultaneously. In assembly it could be an array of structs as well.While I see this point, we have to keep in mind that Rybka was already a 2000 engine before Fruit. I would expect it to already have hash tables, piece square tables, etc. So it's either a coincidence that such similarities exist, or Vas rewrote many fundamental aspects of his engine after Fruit came out.This is interesting, but might be considered as taking ideas rather than code.
I would think that would be obvious. Take two situations, from the beginning of the game. Castling status is 1111b. Now white can lose its castling rights in two ways, moving its king or both its rooks. Which would happen like this:I think the next one is quite common as well. I also use WK=1, WQ=2, BK=4, BQ=8 and used to use the stack that much and have separate make_null, undo_null. Why is CastleHash[oldflags] ^ CastleHash[newflags] more natural?
hashkey ^= CastleHash[1111 ^ 0011 = 1100];
hashkey ^= CastleHash[1111 ^ 0111 = 1000];
hashkey ^= CastleHash[1111 ^ 1011 = 0100];
Both of these must result in the same hashkey, which means that CastleHash == CastleHash ^ CastleHash. So you can't simply fill CastleHash with random numbers, you have to create 4 hashkeys at first (for each of 1, 2, 4, 8), and then make CastleHash[abcd] = CastleHash[a000] ^ CastleHash[0b00] ^ ..., with of course CastleHash = 0.
And then of course when reading a fen, you must initialize the hashkey with hashkey ^= CastleHash[1111 ^ flags].
I won't comment on the UCI go parser, this is the sort of coding I had done for me by support programmers and its outside the engine and I don't really understand it. I'm looking for a proof that exists within engine code, not UCI, I understand some people may take issue, but to show one engine is a clone of another surely requires *engine* code correspondence, no?
Your use of the word "clone" is incorrect in the context of this discussion and could lead to severe misinterpretation.
We are talking about a possible breach of the GPL, the license under which the author of Fruit has published his work. This license explicitely forbids any derived work from Fruit 2.1 to be published as closed source. Such a derived work should be published under the GPL license. It is the will of the original author.
As far as the engine stuff goes, I'm inclined to agree with Gerd and Uri(?) that this material shown so far can well be use of ideas.
I also take issue with the comment:
"But very few engines use them. I am merely trying to accumulate such low level similarities. As of yet, I haven't found any such similarities with any other engine I am aware of."
There are a lot of engines around. Many written before the days of public source, and many which have not revealed their source. Both you and Bob and anyone else know a subset of engines only. As case setjmp() shows. "Few engines use them" or "engine I am aware of" can sound plausible but is ultimately not scientific and can't be used in a logical proof.
On a positive note .... yesterday saw some heated and emotional and slightly wild and personal material - this does not help the discussion forward. It also saw quite a bit of code hieroglyphics posted, so its difficult to know where to start. Would it be possible that you generate some corresponding identical Fruit/Rybka engine code fragment in a strongest case version. ie the one you believe you could base your case on and which is most difficult to refute? Both sides can then concentrate their expert firepower onto this one case. If the anti side can't shoot your example down, then maybe Vas could be asked to comment?
Such side-by-side comparison has been posted (thanks to Norman). Here:
http://pagesperso-orange.fr/ct_chess/Fr ... rt_go.html