Not logged inRybka Chess Community Forum
Up Topic Rybka Support & Discussion / Rybka Discussion / The obfuscation story
1 2 3 4 Previous Next  
- - By Rebel (****) Date 2013-08-29 10:01
Based on a yesterday posting I got some inspiration, the below (better formatted of course) + links on my website.


The obfuscation story


I lost track counting the number of obfuscation allegations made by various chess programmers in order to proof that RYBKA=FRUIT. It's reasoning from a biased point of view that Vasik is guilty of having copied Fruit no matter what despite different code. The latest example yesterday.

Robert Hyatt - Looks like Vas decided to clean that up since the individual scores for each side are not used individually inside..

Mark Lefler on the same issue - My understanding was this was on purpose. Fabien wrote the code so it would work from either side, so he just looped over the to sides and correct for black by subtracting. A classic speedup trick is to unroll the loop, and this is what was done in Rybka. Save a little time since the two score do not need to be combined.

Mark Watkins - It also seems (see node counts and depth) that Rajlich did in fact have "obfuscation" as one of the things on his mind during this period [though maybe just externally].


So fundamental for VIG folks. It's ugly logic also repeatedly found in Zach's accusing (non-scientific) document.

If something is specifically Fruit (an unique Fabien programming sign) that is not in Rybka then Vas is guilty after all since he.... whatever suits VIG folks. "cleaned-up" this time (Robert Hyatt), optimization another time (Mark Lefler) or an obfuscation (Mark Watkins) for the lack of being always guilty, no exceptions.

Fact is, something very fundamental Fruit (evaluation in stages) is not in Rybka. It's a sign of originality. It can not turned into always guilty.



My main objection to this kind of thinking is that Vasik Rajlich an unknown name in computer chess back in 2005, that Vasik was so brilliant he already realized in 2005 he would become so famous that he foresaw the scenario that his program would be disassembled, reverse engineered and to avoid being accused of copying Fruit he needed to introduce loads of obfucations in the code to hide the Fruit origin.

So let's make a list of deliberate obfuscations in VIG style.

1. FEN parsing - Fruit has "fen ", so lets remove the space in Rybka to "fen" so I (Vas) will have an excuse I did not copy the fen-parsing. Wait, I (Vas) will have to do the same for Fruit's "moves ", remove that space again to "moves". And for security reasons let's also change the start position string
FRUIT -  rnbqkbnr /pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1
RYBKA - rnbqkbnr /pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq -

And now I (Vas) am definitely safe.


2. Time Control - Fruit's time control is cute, I (Vas) like to use it but I need to hide the Fruit origin as I can't afford to be exposed, it's a lot of work, but let's start first by converting all the Fruit floats (whoops, I forgot 2 of them) to integers and further rewrite allmost everything to the extreme including the key strings: 

Fruit -  if (string_equal(ptr,"infinite"))
Rybka checks for "is_infinite";

In retrospect, yikes, I (Vas) did a bad job after all, in all the obfuscation chaos I introduced 2 bugs, now my engine frequently loses on time and also the "fixed time" level is bugged. I (Vas) really did a bad job hiding the Fruit origins. Next time I will write the code myself.

3. Fruit Pawn value is 100. Hmmm..... too common, too fundamental also, I (Vas) need something else, something that really hides the Fruit origin, let's take a crazy value no one has ever used, not the standard decimal 100 | binary 128 | binary 256 or 1000 but binary 3200.

I (Vas) am safe again. No Fruit trace.

Reality is there is an unique thought behind this crazy value now in use by many programs to use different values in search and eval for speed-up reasons but nevertheless it was labeled as an obfucation by his accusers, see the link.


4. Order in Evaluation. I (Vasik Rajlich) will be surely accused of copying Fruit if I leave the order of the evaluation unchanged. So I will need to swap a lot of eval ingredients to other places else I am toasted. But wait, that's maybe still not convincing enough, let's remove Fruit's late-endgame knowledge completely.

I (Vas) am safe again. I (Vas) am so smart. I forsee this all and I will have my answers ready whenever someone dares to accuse me of copying.


5. Fruit's unique QUAD function - Wow Fabien, that's quite an unique way of doing things. If I leave that untouched then surely the hackers will expose me as a "copy boy". Hmm... I need to rewrite that.

Done...... just the classic way adding directly to score. I am safe again. Good that I noticed that one!
Phoe... obfuscating an existing engine is surely an art not to take too lightly.

6. Fruit's unique way of evaluation in stages - Already addressed in the introduction. Apparently anno 2013 it's still not understood you can not assume obfuscation because it suits your belief.

7. I (Vas) obfuscated the real NPS (dividing it by 16) and also hiding the real depth (subtract 2). And the latter was a big mistake because by doing this Rybka 1.0 beta showed similar depths as Fruit 2.1. Stupid me, I am not good at this!

8. I (Vas) have done many more obfuscations but I have saved my best obfuscation for the last, the complete rewrite of Fruit's mailbox data structure to bit-board effecting 50-60% of the engine, a complete rewrite of move_gen, move_do, move_undo and the evaluation function. It was quite a job but hey it really paid off, now I have removed every Fruit trace.

I am perfectly safe now and I am ready to crush everyone who dares to accuse me of copying Fruit.


Question - if Vasik did all that to hide the origin of Fruit then why did he not pointed out all these alleged obfuscations for the purpose they were created, to his defence ?
Parent - By Venator (Silver) Date 2013-08-29 15:46
let's remove Fruit's late-endgame knowledge completely.

I think this is one of the best reasons to dismiss the nonsense that 'Vas started with Fruit'. Why on earth would he throw out this valuable endgame knowledge? I still remember the numerous complaints on this forum, when Rybka blew another winning game because it did not know about a/h pawn and bishop of the wrong colour.

This doesn't make any sense at all, but I have no doubt Bob can find some convincing 'explanation' for it :wink:
Parent - - By bob (Gold) Date 2013-08-29 16:06
Your basic assumption is flawed.  "fundamental" means basic AND important.  For example, one definition:  forming a necessary base or core; of central importance.

the two opening scores for white and two for black are NOT a "fundamental" part of fruit.  They can easily be eliminated with a few minutes of editing without changing a thing.  I suspect they were done because at some point Fabien thought "I might want to look at the white and black scores independently..."  But later he decided that was unimportant.  Doing what he did adds one ADD instruction per evaluation.  Impossible to measure such a small cost, so no reason to go back, edit and remove that stuff and possibly introduce a bug or two in the process.

That is NOT a "fundamental fruit" issue.  Since vas obviously did some significant optimization work (splitting hash into separate pieces for a tiny speed improvement as an example) it is not unreasonable to expect that he cleaned the score totals up at the same time...

As to the "why did Vas not.."  Who knows?
Parent - - By Rebel (****) Date 2013-08-29 16:26
As to the "why did Vas not.."  Who knows?

Because he never did all that ?
Parent - - By bob (Gold) Date 2013-08-29 16:45
That is an explanation.  But not a very plausible one considering the evidence...
Parent - - By Rebel (****) Date 2013-08-30 09:10
It's what your copy+modify model stands for, assumptions, assumptions and assumptions.

In the OP I gave you just 8 differences, in reality there are a lot more.

Every major eval ingredient is coded different, mobility, king safety, passed pawns, double pawns, backward pawns, complete lack of Fruit's late endgame knowledge, material table different, absence of Fruit's quad function, trapped bishop different, rook evaluation different, bishop pair different and most important Fruit in an unique way evaluates in stages, Rybka adds directly to score as every other program on the planet.

Other than that:

1. Time control different
2. Fen parsing different
3. Rybka extracts the mainline from TT, Fruit via the classic triangle table
4. Rybka displays a mainline of max. 10 moves, Fruit produces long ones.
5. Rybka bitboard, Fruit mailbox
6. Rybka pawn value = 3200 (unique), Fruit the classic value of 100.
7. Order in eval not similar
8. Rybka has lazy eval, absent in Fruit
9. Futility pruning different.
10. Rybka LMR vs Fruit history reductions
11. Fruit history table, absent Rybka.
12. Fruit only has one evaluation table (king safety), Rybka has many.
13. Different move format (Richard)
14. Rybka absence of minor promotions
15. Different hash table code (Richard)
16. Different handling of repetitions and 50-move rule in search (Richard)
17. Fruit maintains piece-lists, not present in Rybka (Richard)
18. Fruit maintains a pseudo "bitboard" for pawns, Rybka has the real thing (Richard)
19. Contrary to Fruit Rybka needs to update 4 rotations of occupancy bitboard (Richard)
20. Contrary to Fruit Rybka updates a rough estimate of material balance with weights of 1:3:3:5:10 (in the eval this value is then corrected by a delta obtained from the material table) (Richard)
21. Fruit has 16*16 square mailbox, Rybka 8*8 (Richard)

That's 33 indisputable differences (of which some very fundamental) not counting the ones you can argue about such as the PST's, the contents of the TT.

Why didn't Zach & Watkins come up with this list and only found 5-6-7?

And if Zach & Watkins had researched the REAL version, that actually played in an ICGA tournament (and not Rybka 1.0 beta) that list would be longer. Not so?

And as you (like Watkins BTW) have argued sooooo many time, but lemme quote Watkins:

Mark Watkins - I think the case for "copyright infringement" (or plagiarism) of the evaluation function as a whole is quite weighty, particularly when combined with the various other Fruit 2.1 bits that appear here-and-there in Rybka 1.0 Beta.

So by your own standard (and Watkins) I want you to judge the contra evidence as a whole (33 points) too then would you not agree the opposition has (lemme put it mildly) some sort of point?
Parent - - By user923005 (****) Date 2013-08-30 09:50
I think that maybe both sides should listen better.  By that I mean, nobody pays any attention whatsoever to the opposing arguments when they are inconvenient.  For instance, the Crafty 1.4.x-1.6.x beta stuff, Robert is right.  But everyone goes "poo-poo!" just because it was Robert Hyatt who said it.  And on the other side of the fence, all the obvious problems with the original analysis are ignored because they are inconvenient.  In fact, the arguments in *both* cases that I mention here are simply ignored and never addressed.  We see the "yeah, but..." defense.  Which means, "I am going to ignore your point and move on to something where I feel more comfortable."

Right is right and wrong is wrong.  I also don't think that either side of the argument is utterly absurd.  While Robert and I have been teasing each other with cat calls, I hold him in high respect.  Maybe it is time for everyone, all together to say, "You know what, the other side does have some good points."

For instance, it is not impossible that Vas did something wrong (though I remain unconvinced that it has been proven).  Instead of dealing with absolutes like we are all some sort of experts in intellectual property laws, let's consider the possibility that everyone was trying to do their best.  Recall that both Ed Schroder and Marcel van Kervinck were at one time convinced that Vas had probably done something wrong but have since reconsidered in the light of new evidence.  Now that more information has come to light,  I think we should consider this information.  We don't need to pound each other over the head with blame mallets.  I suspect that each and every person who has engaged in these debates has made some kind of errors.  I think that Vas made some bad judgments for sure with the betas sent to Oscar.  I think that the result of the panel's decision was pretty well the destruction of the whole Rybka project.  Yes, we still see the cluster.  But the job of Rybka developer pretty much got vaporized by the bad publicity.  If the outcome is stomping on someone's career, we should be awfully certain that everything is done correctly and leave a very wide margin for error.  And, if things get overlooked, maybe we can think about the new information and revise the theories.

I guess that everyone involved is too emotionally tangled in the entire controversy to think clearly about it.  I can be wrong, Ed can be wrong, Vas can be wrong, Robert can be wrong -- all at the same time.  That is part of human nature.

Not sure what I am reaching for here except to say, perhaps mistakes were made in the past -- more than anything else -- in the way that we treat each other.  Let's not have the cycle of mistakes circle forever.  Some people may be so absolutely sure that they are right that nothing else seems possible to them.  I consider this to be a bad trait.  I find that I am wrong a lot (e.g. I go over the top now and then teasing Robert Hyatt).  Adults should be able to reflect, and not think more of themselves than is absolutely necessary.

Parent - By Rebel (****) Date 2013-08-30 11:06
Your approach is admirable and it has been tried in the beginning (July 2011). But my naivety ended after a couple of months debating Bob and his brother in arms (and ICGA secretariat) member Mark Lefler. Unfortunately there is no middle ground in the R/F case for them. Bob is 100% right and you are 100% wrong and Lefler is not much different, he refutes every point you raise as "rethoric", it has been that way since July 2011. No middle ground possible.

I stick to what I wrote a couple of hours ago.

Parent - - By bob (Gold) Date 2013-08-30 16:39
A couple of key points.

1.  What you call "coded differently" I call "the differences between bitboard and mailbox" which MUST be coded differently.  Those differences do not preclude copying in any way.

2.  The differences in other parts of the code are irrelevant.  What was key to the ICGA investigation was "were parts of Fruit copied or non-literally copied?"  (a derivative work) Not "was Fruit copied and used "as is" (a clone).  Differences are great.  The more the merrier.  But the issue was/is, "does Rybka contain too many pieces of Fruit?"

You cite "Rybka is bitboard fruit is mailbox" as if one can't copy from one to the other.  I did it in developing the early versions of Crafty.  I had a functional chess program, written in FORTRAN.  A program that worked, had a well-developed parallel search, and which was extremely strong.  I wanted to move to bitboards, AND to C, since FORTRAN is not exactly main-stream as it was in the 60's and 70's (it was the first language taught in MANY early CS programs).  Was Crafty original at the time?  Hardly.  Even though it was in a different programming language, using a different board representation, and using different design features such as recursion (which was not possible in early versions of FORTRAN).  But it was clearly a copy/translate process.  What about today?  VERY DIFFICULT to find any traces of Cray Blitz left, directly.  I can think of a few places that look "similar".  Code to parse a FEN string.  Not spent much time fiddling with that since it has worked since the early 70's...  Repetition detection?  similar.  Search?  completely rewritten with nothing at all remaining.  making/unmaking moves?  Look nothing alike.  Evaluation?  Might be a couple of similarities still, but for the most part, all rewritten.  Multiple times.  Is Crafty today a derivative?  Much more difficult question.  It played its first move in late 1994 (December in fact).  It was clearly a derivative then.  20 years later?  I don't think there's enough left to even talk about.

What about Fruit/Rybka/crafty?  Clearly the early versions of Rybka were by no possible measure "original".  Rybka 1.0 beta?  Better than 1.4-1.6.1, but it STILL contains a lot of recognizable pieces from Fruit.  You claim the bishop mobility is different in many ways, for example.  I see nothing significantly different and the only trivial difference is whether the number of squares is counted as 0-13 or -6 to +7 (same range, different origin).  The SAME set of squares is counted, ALL are weighted equally.  That's a similarity.  Not exactly the same, but then Rybka was worked on for > 1 year after the original copying.  I'd expect things to be different or fruit would be just as strong as Rybka 1.0 beta.  BTW Fruit 2.3 WAS about the same strength, so modifying fruit to gain Elo was clearly possible and not that difficult.

So we are left with a complex question, "Does 1.0 beta contain more of Fruit than what is considered acceptable, more than what would be considered "original"?   A subjective question, but I have no doubt in my mind that the answer is simply "yes".  Nothing to do with the punishment, nothing to do with anything other than that question, "Is it original"?  I believe the ICGA verdict was correct, the evidence shows so many fruit fingerprints it is simply unacceptable.  If you disagree, that's fine.  People disagree on subjective questions all the time.  The only unfortunate issue is the claims of "you lied" or "you mislead".  Never happened.  I've never said ANYTHING I did not believe to be true.  Which means the word "lie" is NOT the right word.  If it turns out I was wrong somewhere, then I was wrong.  But I did not make a statement that I KNEW to be false, ever.  Not one time in the investigation.  I simply believe in what my eyes see, and what my experience tells me.  Nothing more, nothing less...

Why didn't they list differences?  We were not looking for differences.  We were looking for what parts of Fruit and Rybka are identical or nearly identical.  There is no "threshold" in ICGA rule two that says "more than xx% of the code must be original".  It must ALL be original, excepting for things agreed upon in the past (such as Nalimov EGTB code, etc).
Parent - - By user923005 (****) Date 2013-08-30 16:46
In order to accuse someone of "non-literal copying" which is obviously much harder to show than copying, it is a requirement to perform the Abstraction-Filtration-Comparison test.  This test starts with obtaining the source code.  You are accusing someone of a specific crime without having performed the required steps to prove it:
Parent - - By bob (Gold) Date 2013-08-30 17:18
Assembly is quite good enough, because we have the fruit source already...
Parent - - By user923005 (****) Date 2013-08-30 18:17
Your team obviously does not need to follow rules of evidence, and other procedures to make accusations.  I guess that when you only want to prove you are right, all is fair.

"Badges?  We don't need no stinking badges!"

Source code?  We don't need no stinking source code.  We already decided he is guilty.  The source code would only get in the way.
Parent - - By bob (Gold) Date 2013-08-30 21:54
Please.  If this is all you have, it's time to retire from the discussion.  Source would have GREATLY helped the investigation.  We would likely have compared EVERYTHING to fruit.  And I can only guess what we would have found, based on what was discovered in looking at the asm code.  Source code would almost certainly have gotten in Vas' way, of course.  If that is what you were implying.  Not ours...

We decided he was guilty AFTER looking at a ton of code...
Parent - - By user923005 (****) Date 2013-08-30 22:17 Edited 2013-08-30 22:23
That is a LIE.
You never had any code.
You did not even ASK for it.
You did not look at a ton of code.

Three gentlemen have looked at some assembly code.  There conclusion was that "no code was copied."  They left open the door for "non-literal copying".  To prove non-literal copying there is a specific test that must be performed.  You did not perform that test.
You have literally nothing to show that indicates guilt, as far as the ICGA contests go.

What you say in your arguments is getting more and more deplorable because you stretch the truth beyond what the English language allows.  We call that "lying".
Parent - - By bob (Gold) Date 2013-08-30 23:57
I have looked at a TON of code.  Say what you want.  I (and others) KNOW what I have looked at because I have commented specifically and frequently on particular code features.  Try again...

The conclusion was not "nothing was copied".  The conclusion was "due to bitboards, the major piece of eval were non-literally copied".  I don't think there is any doubt that other code was copied.  TT code is already "there"... 

I call what you keep writing "outright lying in the face of hard evidence that refutes your statements".
Parent - - By user923005 (****) Date 2013-08-31 00:49
You may have looked at a ton of code.  Unfortunately you did not have Rybka's code.  So you used some imaginary code produced by humans which was full of errors.

You failed to perform the correct steps to prove "non-literal copying" and yet you keep pretending that all is well.

Parent - - By bob (Gold) Date 2013-08-31 04:52
Rybka's asm is NOT "imaginary".  It is as real as code gets.  It is "code".

You keep saying we did not use AFC.  Unfortunately, for you, if you read Zach's report, you see the abstraction step, followed by filtration, IMMEDIATELY, as necessary due to the bitboard stuff.  Then the comparison step made perfect sense.  No matter how many times you say it was not done.  Either you can't read, or you don't understand the non-literal copying explanation which includes AFC.  Whichever doesn't matter...
Parent - By user923005 (****) Date 2013-08-31 05:02
Step 1, starting with the code....

I know, you consider the assembly to be his source code.
We are just going to have to disagree on that.
Parent - - By nebulus (****) Date 2013-08-30 18:14
"Application of the abstractions test will necessarily vary from case-to-case and program-to-program. Given the complexity and ever-changing nature of computer technology, we decline to set forth any strict methodology for the abstraction of computer programs. Indeed, in most cases we foresee that the use of experts will provide substantial guidance to the court in applying an abstractions test. However, a computer program can often be parsed into at least six levels of generally declining abstraction: (i) the main purpose, (ii) the program structure or architecture, (iii) modules, (iv) algorithms and data structures, (v) source code, and (vi) object code."

Parent - - By user923005 (****) Date 2013-08-30 18:27
The steps laid out required going through each level of abstraction, according to my reading of the document.
Actually, when I read the requirements, I found it surprisingly sensible.
Parent - - By Rebel (****) Date 2013-08-30 22:41
Back in 2011 there was a chess programmer with the name of "MEC". I don't know who he is but he wrote quite passioned about the absence of the required AFC test. Here.
Parent - By user923005 (****) Date 2013-08-30 22:53
He seems very competent.  Too bad nobody bothered to listen.
Parent - - By nebulus (****) Date 2013-08-30 18:39
BTW, where exactly does it say that the "test starts with obtaining the source code"?
Parent - - By user923005 (****) Date 2013-08-30 18:42
"As applied to computer programs, the abstractions test will comprise the first step in the examination for substantial similarity. Initially, in a manner that resembles reverse engineering on a theoretical plane, a court should dissect the allegedly copied program’s structure and isolate each level of abstraction contained within it. This process begins with the code and ends with an articulation of the program’s ultimate function. Along the way, it is necessary essentially to retrace and map each of the designer’s steps – in the opposite order in which they were taken during the program’s creation."

{bolding is mine}
Parent - - By nebulus (****) Date 2013-08-30 18:45
I hope you do realize it says "the code" and not "the source code"!? Object code is also code.
Parent - - By user923005 (****) Date 2013-08-30 18:56
I have proven, with three different algorithms, that non-infringing code produced identical assembly language.
In each case, a small algorithm, clearly different implementations written by different authors, produced identical assembly language.

In every single case of the decompiled Rybka, the assembly was not identical.

Machine instructions have all of the syntactic sugar removed.  The variable names are gone.  The structures have turned into simple blocks of data.  The optimizer has rearranged things for efficiency.  It's not even the same code that was written.

If the assembly was identical, and it was a very long sequence (e.g. 4000 lines from 400 lines of code) then clearly something was copied.  The assembly is not identical.  In fact, each and every person who performed the disassembly said the same thing:
"There is no literal code copying."

The only thing that similar assembly language shows it that a similar algorithm was used.  That is all.
There is literally nothing wrong with that.

Now, if every single algorithm were the same, then that also would be cause for complaint.  But clearly, that is not the case either.

If you have read my thread titled: The proof of plagiarism is in the assembly.
and you still think that it has been proven that Vas copied code, then I think that you are disingenuous and only want to prove your point.
Parent - - By nebulus (****) Date 2013-08-30 19:00

> I have proven, with three different algorithms, that non-infringing code produced identical assembly language.
> In each case, a small algorithm, clearly different implementations written by different authors, produced identical assembly language.

Do you mean those "one-liners" you posted earlier? Maybe you should do the same with bigger blocks!?
Parent - - By user923005 (****) Date 2013-08-30 19:11
Thirteen lines of C produced 31 lines of assembly and you have missed the point altogether.  The third one was about the same size and one was smaller.  I suggest that you examine the full assembly of all of the complete set and you will find lots of similar pairs.  I posted only the identical ones.

Simple routines written by different authors that were clearly independent produced identical assembly language.
If I compose these algorithms (a calls b who calls c, etc. or inline them) I can obviously produce longer and longer sequences of identical assembly language up to infinite size from totally independent programs.

It is obvious by induction that the thing which is to be proven (similar assembly language proves theft) DOES NOT WORK.  I can produce a false positive without any effort.  In fact I produced three of them from existing test routines, all of which were very old.

Sure, If we independently write 1000 line routines using the same algorithm and then compile them there will be some differences even in the assembly. But, as you know, that is EXACTLY what was seen in the assembly language.  Many small, important differences.  Do you deny this?!

People smart enough to understand programming are smart enough to see this.
Parent - - By nebulus (****) Date 2013-08-31 00:00
This is silly. You do realize that would mean you'd never be able to prove reverse engineering, don't you?
Parent - By bob (Gold) Date 2013-08-31 00:21
Do you think THAT really matters?  :)

Obfuscation is the name of the game.  "nothing works".  Etc...
Parent - - By user923005 (****) Date 2013-08-31 00:23
It would, in fact, be quite difficult to prove reverse engineering.
An expert of some sort did weigh in on the lack of the test in 2011 when it was brought up.
Ed gave a link to the post, but I can't seem to find it right now.

I do guess that in order to determine guilt, the court would you to actually follow the procedures demanded to determine guilt.
Since the board did not do that, a pronouncement of guilt would be premature.

Were you on the board?  I can't imagine any other reason that someone would be so abstinent when the facts are so obvious.
Parent - By user923005 (****) Date 2013-08-31 01:43
Here is the link (it comes from just a few posts up):
Parent - - By bob (Gold) Date 2013-08-30 21:58
Yes, and it shows the continual exaggeration you use. "code" supposedly means "source code" to you.  Wonder why they would be SO SLOPPY in that description and not say "source code"?  They mentioned "reverse engineering" which ought to be a hint to you that code means code, whether it be assembly, source, or something in between.
Parent - - By user923005 (****) Date 2013-08-30 22:11
Your interpretation of "start with the code" is "start with the binary"?
You are being deliberately thick.  Obviously, when it says 'start with the code' they are talking about source code.  That is what anyone would mean if they said that.  If they meant to decompile the binary and use the assembly, that would certainly be spelled out.  And, as I have clearly shown, that method does not work anyway.  It is very easy to produce a false positive that produces identical assembly.  The assembly is nowhere close to identical here.

You never answered my question, by the way.  Did you actually perform the test as required, or did you simply use the legal term as if you had performed the test, but did not know how to do it?
Parent - - By bob (Gold) Date 2013-08-31 00:17
I've been programming for 44 years now.  I program in everything from assembly to you-name-the-language.  I can give a list of every language I have used, if you want.

IBM 1620 asm
IBM /360/370 asm
Dec PDP 11/44 asm
Dec Vax asm and microcode asm
Cray-1 thru Cray T932 asm
Sun Sparc asm
Intel x86 from the 8080 to current chips ask.
Texas Instruments 960b asm
HP2100a asm and microprogramming asm.


I believe that qualifies me to discuss "code". Whether it be asm or a higher-level language doesn't matter one scintilla to me.  I specifically told you we followed the classic AFC approach.  We HAD to because of the bitboard to mailbox issues.  So why do you KEEP asking the same question?  Keep hoping for a different answer?  Classic definition of "insanity" is "repeating the same actions over and over, hoping for a DIFFERENT outcome."

I DID answer your question.  You just don't stop to read my answer...

You have proven absolutely nothing except that one can write a 3 line function using the same language, but writing it N different ways, and the compiler will produce the same asm for some of those attempts.  The eval is not "3 lines".  You want to pick one line and say "you can't compare this."  We didn't try to compare "one line" or "one 3 line function".  And you are STILL ignoring the hash issue.  There is no bitboard there, just matches.
Parent - - By user923005 (****) Date 2013-08-31 00:41
You keep saying 3, when it was 13.  It generated 31 lines of identical assembly.
Then there was another about the same size.
And a smaller one.

Since I showed that different code produces identical assembly due to using the same algorithm, your argument is moot.
By the way I have programmed on your platforms, and PDP 11/70, Sun, HP, DEC Alpha OpenVMS, DEC OpenVMS on Itanium, IBM 3090, SCO, BSD, Ultrix, Linux (many flavors), AIX, Tru64 etc.
You left out Cray, for which I am rather jealous.
I have programmed all of your languages except Snobol,  APL.  I have also programmed in DIBOL (VAX COBOL variant), Java, VB.NET, C#, Every database language that you can imagine and more. I am familiar with DCL and JCL job control languages and I have dabbled with Perl, Tcl/Tk, and other scripting languages.  I dabbled in Algol (ACM published all their routines in Algol) but no real jobs.

I have been programming since 1976.  Now, I don't doubt that you have good credentials.  Quite a nice list, really.
Parent - - By bob (Gold) Date 2013-08-31 04:58
I keep saying 3 because it was 3 lines of C.  Rewritten N different times, with the sole intent of producing the same asm code.

Nothing in a chess program is that simple.  We looked at NO 2-3 line snippet to show Vas copied. 

As I said, this is a strawman argument, from the get-go.

As far as platforms go, I am sure I missed several.  I had a dec alpha in my office, loaned to me by Dec, to test their "universal parallel compiler" for C.  I don't count the scripting languages, of which I would include c-shell scripts, python, perl, Make, and who-knows what else.

But none of that matters when you are taking a beyond tiny function, and looking at JUST that bit of code, and say "lookee looked, same asm."  If you look at Zach's report, it encompasses Rybka's and Fruits evaluation.  A "little more" then 3 lines of code.
Parent - - By user923005 (****) Date 2013-08-31 05:01
I saw a few assembly listings side by side.  They were about the size of my snippets.

I saw a few C listings side by side, they were about 5-10 lines.

There is no evidence I have seen of huge blocks of copied code.  What little tiny snippets there are all have significant differences in them.

I find your argument entirely unconvincing.
Parent - By bob (Gold) Date 2013-08-31 05:02
But not a SINGLE snippet, eh?  Think about it. The light will "dawn".
Parent - - By user923005 (****) Date 2013-08-30 16:49
Re" "It must ALL be original, excepting for things agreed upon in the past (such as Nalimov EGTB code, etc)."

All chess programs are collections of other people's chess ideas.

They are almost like conglomerate rock, a collection of things other people created, glued together in the framework of another program.

I recognize that there is considerable leeway for self-induced creativity in this regard.

But since it has been shown that every single thing Vas has been accused of is not 'literally' true, since there are code differences at every turn, and since you have not followed the legal directives to prove what you claim to have proven, perhaps you can see the consternation on everyone else's face is not without reason.
Parent - - By bob (Gold) Date 2013-08-30 17:17
Why don't you jump into the transposition table discussion?  That has some interesting points that don't require any bitboard / mailbox removal at all...
Parent - - By user923005 (****) Date 2013-08-30 18:22
Yes, let's talk about transposition tables.  In particular Zobrist hashing.  To perform zobrist hashing, we need a table of random numbers.  Then we take the piece type, the piece color, the piece location and perform an xor for each instance.  Finally, we do the same for castling rights and e.p. status.  Each and every program does it exactly this way.  So far as I know, Zobrist never rescinded his copyright or put his code into the public domain.  So as far as hash tables go, I suspect 90% of all programmers have picked up this ball and run with it.  That is because it is so easy to make the hash incremental, with the movement of a single piece.

Of course, the algorithm itself is not protected.  But would you agree that we will see all of these exact steps, just as I describe in nearly every chess program?
Parent - - By bob (Gold) Date 2013-08-30 21:51
Have you seen any mention about random numbers?  strawman argument.  Have you seen any mention of Zobrist hashing?  Strawman argument.  You DID see specific questions about the very unusual layout of the tt data, aging, replacement, etc.  All match fruit exactly.  All are very unusual.  This is not "an algorithm".

Yes we see the steps you mentioned.  But that is NOT "the hash table implementation".  That is "hash signature implementation" which is a completely separate topic, nothing to do with the tt in fact, except the signature is used to probe and match.  But once you match, what do you get and how do you use it?  That goes far beyond Zobrist who NEVER suggested any sort of tt usage in a chess program...

Again, you ramble off into the area of algorithms and ideas.  The fruit/Rybka tt entry format is not "an algorithm".  how the various fields are modified/used is not "an algorithm"...
Parent - - By user923005 (****) Date 2013-08-30 22:37
RE: "Have you seen any mention about random numbers?  strawman argument.  Have you seen any mention of Zobrist hashing?  Strawman argument.
Unfortunately, you do not understand the meaning of 'strawman' argument.  It means something that is substituted but is easy to tear down, not 'something that shoots my entire position to pieces'. After all, it was you that asked about similar algorithms.  I showed that this algorithm implemented EXACTLY THE SAME WAY IN EVERY SINGLE PROGRAM (including crafty).  According to you, then, crafty has non-literal copying.

You DID see specific questions about the very unusual layout of the tt data, aging, replacement, etc.  All match fruit exactly.  All are very unusual. This is not "an algorithm"."
I agree it is not an algorithm, we call it a 'lie' because none match fruit exactly.

You see, NONE and ALL are what we call opposites.  And when you substitute ALL into a sentence where NONE belongs, then we call that 'telling a falsehood.'
Parent - - By bob (Gold) Date 2013-08-30 23:53
Doesn't match EXACTLY?  Please cite the differences.  Richard posted the code.  And don't give me the "split hash_store() into separate functions nonsense.  A compiler could well do that with inlining, automatically.  So PRECISE differences.  He's already stated "aging is exactly the same."  You can see his code from rybka to see what is updated and when.  Fruit's source is available.  I compared them.

Waiting to hear from you on this...

BTW I have not said "ALL" when "NONE" is the correct term.  That is YOUR problem in this case.  Just show me where NONE of the rybka tt code matches Fruit.  I'm waiting...
Parent - - By user923005 (****) Date 2013-08-30 23:59
If he implemented it in his own way, that is "using the same algorithm" not using the same code.
If there were exact matches, they would show up in the assembly.  They are not there.
There are approximate algorithmic matches in several places, but always with important differences.

Since you are the accuser, the burden of proof is on you, not me.  You have shown nothing.
You did not follow the correct procedures to make the claims that you have made.
What you did was deplorable, and it is far more deplorable now that new facts have come to light and you simply ignore them.

To me, it is one thing to do a wrong in ignorance.  But when the facts are fully known and you keep insisting everything was fine, then that is ten times worse than the original problem.
Parent - - By bob (Gold) Date 2013-08-31 00:07
He didn't implement it "in his own way."  He implemented it in "Fabien's way" as shown in original fruit source.

How about stopping for a minute and reading.  This having to repeat something 10 times before it sinks in is getting pretty old...

Did you look at Richard's post on hashing?  His "tongue-in-cheek" comment (I'll leave the comparison to fruit to the reader...)...
Parent - - By Rebel (****) Date 2013-08-31 09:28
He didn't implement it "in his own way."  He implemented it in "Fabien's way" as shown in original fruit source.

As the 3 CCC links show it easily can be the other way around, that Fabien took the idea from Vas. Vas used MTD (f) in 2003 a year before Fabien came around.
Parent - By bob (Gold) Date 2013-08-31 18:10
Idea, possibly.  But peculiar code with FOUR draft values?  :)
Parent - - By John (**) Date 2013-08-31 13:14
Once again, you are dismissing very strong counter arguments in a sorry way. All in all we can also claim, in the broadest sense, that Crafty is a non-literal copy of many other programs. To use your own way of thinking: Crafty does many things the same way as many other programs, thus it must be copied.

Can you also please explain to me why Fruit's extensive endgame knowledge is not in Rybka and what point it would be to leave that out?
Up Topic Rybka Support & Discussion / Rybka Discussion / The obfuscation story
1 2 3 4 Previous Next  

Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill