What the computer chess community needs to decide

[beram]

Tom,

Why is it out of line?

People that write pages full about ethics and morality in engine development should not eagerly launch themselves in idle and incorrect speculations about other engines.
An author of a top engine (Don and Larry fit that description) should feel some reluctance towards trash-talking other authors of top engines. It's a matter of common decency.

Robert

I am not trash-talking you. I am trying to get an answer to the question of whether you achieved the recent large rating gain by some original idea or ideas, or by adding known ideas to the early Houdini.

As to the claim that Houdini is basically Ivanhoe, I don't know this myself, I just have no reason to disbelieve what Chris wrote. I do know that the evals are very similar to my evals in R3 but scaled down a bit.

It took Vas three year to make Rybka4 approx 40-50 ELO better than Rybka3, so within this regard, how awesome the performance of Robert Houdart must be, by making Houdini1.5 50-60 ELO better within half a year !

And how bitter and frustrated you - Don D and Larry K - must be by denying this huge fact, which certainly is due to something very different than just tuning some "ivanhoe" parameters. You really should be ashamed for this trashtalk

Robert keep up the good work and let the jealous guys be bitter

kind regards Bram

[Christopher Conkie]

Houdini is NOT basically Ivanhoe (and reading Chris C it's obvious that he knows very little about Ivanhoe or Houdini).
Robert

I may be many things but one thing i'm not is blind. Nor are any of the other programmers in here.

Houdini IS Ivanhoe. Fact.

I'd be surprised if you knew how to change program on a telly. It is an absolute certainty that Houdini IS Ivanhoe. There is no doubt whatsoever. Categorically no doubt at all......

You know Robert.....you sound like an amiable fellow even if you are a pathological liar by demonstration. Which low-life put you up to it? Hmmmm? Having said that I think we can guess.......it's not brain surgery.

Things are about to get a little hot for you you see. It's up to you, but "trash talk" will be the least of your worries shortly.

I'm gonna really love it when you to try to explain why it is the entire structure of Houdini is exactly like Ivanhoe to all the ravenous programmers in here. Not sure how tasty you are but I think you are about to get chewed up nevertheless.

Good luck. Better get some really good lies ready.



Chris

[Milos]

This statement identifies you as an amateur at software development. There are bugs in EVERY substantial piece of software and of course they wouldn't be there if the programmers knew about them. Since they don't know about them, they don't know how much they hurt the program.

A programmer might make the statement that they believe with a great deal of confidence there are no substantial bugs affecting ELO, but they can never know for sure. But this would be for the programmers to say, not for you.

When ppl get to certain age they start understanding things only literally. Moreover, they also see a huge decline in their intellectual performance and they get very bitter because of that, and very jealous to young ppl obviously much more capable than what they are at the moment.
I don't approve this, but I can understand it.

Non-old, non-grumpy man regards,
Milos

[hgm]

Surely you have seen chess engine open source code (other than your own) by today. If not then you must know that it is unbelievable. All authors who CURRENTLY develop engines have at least seen chess engine open source of another engine. That was my point.

Accepting that, it is understood that from those who currently develop chess engines not only saw other source code but are using some ideas from them as well.
So no current engine is original.

Note: My point is not that all current developers has copied from source code but rather have at least used ideas from them. Dr. Hyatt believes that translating code without exactly copying still renders an engine not original.

Indeed, I did print out the Fruit evaluation some time ago, to give me something to do when my RSI was so bad I could not do any programming myself. The major thing I learned from that was that it all was pretty inefficient code. Even the basic board representation was weird: Fruit has two boards, one with piece number and the other with piece type, which both have to be updated on a move. What struck me was the large amount of code devoted to recognizing drawish end-games, and the way it handled those (by applying a multiplier < 1 to the normal evaluation score) was new to me. I did not implement that in any of my engines, though, because naively walking into a draw is not really a significant problem for them, and because it is often unknown for the engines I write which material combinations are draws anyway.

So there was no great mystery revealed to me, which I of course had not expected, because I had already read Fabien's statement that Fruit really does not contain any special tricks, and that its major 'secret' is the absense of bugs.

To use ideas you don't need to look at code. Ideas are described in books and on forums. And using ideas is not the same as translating code. So I think you misunderstood Bob. Crafty uses many 'ideas' that were invented by others: null-move pruning, late-move reductions, magic bitboards. Such ideas are the bolts, nuts and cogwheels of Chess programming. It is the way you combine such ideas that makes the Chess program. Just like car manifacturers cannot sue each other for infringement based solely on the fact that tho competitor's car contains tha sime guage nuts and bolts, Chess engines making use of these ideas are still considered original. It is just if two engines use exactly the same ideas in the same combination that they can be considered translations of each other, (if the code that implements the ideas is completely different) rather than original.

[Rolf]

Both - Rybka author and Cray Blitz author stated that a) one could easily detect copies by putting the codes (how much from what parts is my question) side by side and b) that this had been done with Fruit code and Rybka 1 beta code (for what time exactly this had been done and what is the potential offense at that exact time is my question).

The above means that both, Vas and Bob are somewhat comedians because they insinuate simplicity where in truth the task begins.

Putting codes side by side and detecting similarities or identities is useless if you dont define what it would look like if some relevant problem were beginning and what for example is just an artefakt. Hence identical codes isnt the verdict yet but the start of a deeper examination.

In addition to the meaning of identities or similarities we have the legal question what exactly is defined offense for the time in question. Of course this would be the relevant question in a court and long before because without relevance there is no case at all.

The naivety of the whole approach to these two problem parts is extremely high. Because we recall the many periods of different attitudes Fabien's handling at the time. If something had been taken, in what exact period of time was it relevant for a forbidden act in a legal sense.

I fully support George's message from a judge, there will never be a court case for this question, unless some people had too much money to be wasted.

[Harvey Williamson]

http://www.open-chess.org/download/file.php?id=272

is worth a read. A new version updated yesterday.

The document concerning a comparison of Rybka 1.0 Beta and Fruit 2.1 has been reworked to some extent. There has been a re-shifting of sections, more links/pointers to code locations, and some additional disassembly examples. Two appendices have been added, the first being a disassembly of the iterative deepening code of Rybka 1.0 Beta (~100 ASM instructions at the end of root search), while the second draws together various related information (such as later versions of Rybka and statements of Rajlich). This is still to be considered as a "draft" version I guess, and any feedback (even concerning style, readability, or whatever) is appreciated.

[Don]

http://www.open-chess.org/download/file.php?id=272

is worth a read. A new version updated yesterday.

The document concerning a comparison of Rybka 1.0 Beta and Fruit 2.1 has been reworked to some extent. There has been a re-shifting of sections, more links/pointers to code locations, and some additional disassembly examples. Two appendices have been added, the first being a disassembly of the iterative deepening code of Rybka 1.0 Beta (~100 ASM instructions at the end of root search), while the second draws together various related information (such as later versions of Rybka and statements of Rajlich). This is still to be considered as a "draft" version I guess, and any feedback (even concerning style, readability, or whatever) is appreciated.

I am considering the possibility of doing a similar study between the earliest Houdini, and the equivalent version of Ivanhoe. Before I start, I would like to know what work and effort has already been done in this regard. Maybe we can pool our efforts. I would rather spend the time improving my own program, but I think it's worth an investment of some time.

[Harvey Williamson]

http://www.open-chess.org/download/file.php?id=272

is worth a read. A new version updated yesterday.

The document concerning a comparison of Rybka 1.0 Beta and Fruit 2.1 has been reworked to some extent. There has been a re-shifting of sections, more links/pointers to code locations, and some additional disassembly examples. Two appendices have been added, the first being a disassembly of the iterative deepening code of Rybka 1.0 Beta (~100 ASM instructions at the end of root search), while the second draws together various related information (such as later versions of Rybka and statements of Rajlich). This is still to be considered as a "draft" version I guess, and any feedback (even concerning style, readability, or whatever) is appreciated.

I am considering the possibility of doing a similar study between the earliest Houdini, and the equivalent version of Ivanhoe. Before I start, I would like to know what work and effort has already been done in this regard. Maybe we can pool our efforts. I would rather spend the time improving my own program, but I think it's worth an investment of some time.

Hi Don,

This may be a good place to start http://www.open-chess.org/viewtopic.php?f=7&t=992

Cheers,
Harvey

[hgm]

I am considering the possibility of doing a similar study between the earliest Houdini, and the equivalent version of Ivanhoe. Before I start, I would like to know what work and effort has already been done in this regard. Maybe we can pool our efforts. I would rather spend the time improving my own program, but I think it's worth an investment of some time.

I am really curious what tools there are available to compare binary files for code similarity. For instance, are there tools that can easily recognize with which compiler the binary was made? And if so, is it possible to recognize option settings, like the optimization level? I imagine compiling a given open source the same way as a suspect binary should provide a very close likeness between binaries.

The obvious way to compare binaries seems to first identify which bytes are addresses, and which opcodes, and then restrict the comparison to the opcodes. But assignment of temporaries to registers during optimization is also quite arbitrary, so it would be better to also not pay too much attention to the register part of the modR/M byte, or first replace actual register indicators by symbolic references, and give additional points only when a given symbolic reference matches the same physical register in multiple places. Are there tools to compare binaries this way?

[Eelco de Groot]

I am considering the possibility of doing a similar study between the earliest Houdini, and the equivalent version of Ivanhoe. Before I start, I would like to know what work and effort has already been done in this regard. Maybe we can pool our efforts. I would rather spend the time improving my own program, but I think it's worth an investment of some time.

I am really curious what tools there are available to compare binary files for code similarity. For instance, are there tools that can easily recognize with which compiler the binary was made? And if so, is it possible to recognize option settings, like the optimization level? I imagine compiling a given open source the same way as a suspect binary should provide a very close likeness between binaries.

The obvious way to compare binaries seems to first identify which bytes are addresses, and which opcodes, and then restrict the comparison to the opcodes. But assignment of temporaries to registers during optimization is also quite arbitrary, so it would be better to also not pay too much attention to the register part of the modR/M byte, or first replace actual register indicators by symbolic references, and give additional points only when a given symbolic reference matches the same physical register in multiple places. Are there tools to compare binaries this way?

Okay, this initiative from Don, posts from Chris above is just turning into Houdini bashing and declaring open season on any executable you can lay your hands on because, as Fabien said, executables are the new open source. All in the spirit of computerchess. What the computer chess community needs to decide... Do you guys think any judge will bother taking up the Rybka 1.0 beta copying Fruit code case if he knows to how much of this is already being done. There is no case I'm afraid. I'm sure Vas does not even bother to read this forum anymore. I think it is quite hopeless expecting any resolution. Still computerchess can be a nice hobby but I'm taking all these computerchess tournaments with a few grains of salt. Heaven forbid, we will soon have only cloud software participants from people with twenty different identities and programs that all contain Vincent's move generator because if ever the sources get leaked again, they for sure can't read Dutch anyway. I give up