The "well meaning" witch hunters have caused much

[Graham Banks]

Then feel free to set up your own forum and ignore them. But it's not your decision to make for somebody else.

Lol, it's also not Graham Banks decision to make, still the whole forum is governed by it.

When will you understand that the directive to disallow links was not made by me? As a moderator though, I will comply with it and enforce it. The other two mods were not happy to do so.

[Dann Corbit]

Hello Matthias,

Is there any chance - for non-programmers like me - that you could expand on that ratio of work required?

In non-programming language as far as possible.

That is an astonishing ratio.
Later.

I believe he is under-estimating the non-bitboard to bitboard effort. I have done this in three flavors. The first was the original crafty project coming from the previous Cray Blitz mailbox approach. Big learning curve. The second was re-numbering the bits since the bits were originally numbered to be efficient on a Cray, while the program effectively became a PC-based project over time. Just changing bit numbers is a _huge_ effort. There are all sorts of bit patterns used in evaluation. Or in move generation. And if you change the bit numbers, the patterns have to change as well. And the compiler doesn't warn you which patterns are wrong. Then I changed these patterns again to get rid of the black/white duplication, and it was a significant effort. Going from non-bitboards to bitboards is a huge project, since it affects almost every part of a program... evaluation, move generation, making/unmaking moves, SEE, check/attack detection, position setup, move ordering, etc. But none of this removes the fact that the original code was copied when making those changes...

The big learning curve may have applied to you as a bitboard pioneer in chess programming. My generation and younger get bitboards spoon-fed with no learning curve. Translating a non-bitboard infrastructure to a bitboard infrastructure is no big deal. The _amount_ of work to do may be high, but its _complexity_ is very low for people who think "in bitboards".

Matthias.

You must be able to think clearly in both formats.
In addition, the evaluation, search, hash, etc. are often tied very closely to the physical format. Simply changing the board representation by itself will definitely not work. A significant retool of the entire application will definitely be needed.
Whether it is harder or easier than some other chess conversion process cannot be determined by some simple formula.

Open up Fruit's evaluation file 'eval.cpp' and you will see that it is entirely based upon the use of arrays. There is hardly a single line of code that could stand untouched. And to correctly transform to a new fundamental underlying data structure means that one would have to understand and translate every single line correctly (assuming that a 1:1 translation is the goal).

For many of the <possibly> clone programs, we see ultra simplified skeletons. An IdaPro flowchart of any of the Rybka engines shows an extremely complicated engine. The same flowcharts of the <possibly> clone programs show very simplified flow charts. It would be possible {for instance} to understand 3% of the most important code (perhaps the majority of the search), and translate that important part, ignoring everything else, and getting a very strong engine. Is that hard? Is it easy? It depends.

Without the source code for both programs I think it is not possible to devine all the events that took place.

Others think differently.

I respect both opinions.

[Matthias Gemuh]

The big learning curve may have applied to you as a bitboard pioneer in chess programming. My generation and younger get bitboards spoon-fed with no learning curve. Translating a non-bitboard infrastructure to a bitboard infrastructure is no big deal. The _amount_ of work to do may be high, but its _complexity_ is very low for people who think "in bitboards".

Matthias.

You must be able to think clearly in both formats.
In addition, the evaluation, search, hash, etc. are often tied very closely to the physical format. Simply changing the board representation by itself will definitely not work. A significant retool of the entire application will definitely be needed.
Whether it is harder or easier than some other chess conversion process cannot be determined by some simple formula.

Open up Fruit's evaluation file 'eval.cpp' and you will see that it is entirely based upon the use of arrays. There is hardly a single line of code that could stand untouched. And to correctly transform to a new fundamental underlying data structure means that one would have to understand and translate every single line correctly (assuming that a 1:1 translation is the goal).

For many of the <possibly> clone programs, we see ultra simplified skeletons. An IdaPro flowchart of any of the Rybka engines shows an extremely complicated engine. The same flowcharts of the <possibly> clone programs show very simplified flow charts. It would be possible {for instance} to understand 3% of the most important code (perhaps the majority of the search), and translate that important part, ignoring everything else, and getting a very strong engine. Is that hard? Is it easy? It depends.

Without the source code for both programs I think it is not possible to devine all the events that took place.

Others think differently.

I respect both opinions.

I agree with what you say about converting to bitboards.
Yet the problem is that of amount of work, not complexity, if C/C++ source code is available.

Starting from C/C++ source code of Rybka3, the road to Ippo is in comparason very complex (in view the types of differences outlined by BB). When we replace Rybka source code with a Rybka binary, it makes no sense anymore trying to compare the complexity with that of merely translating Fruit source code to a bitboard Fruit.

Matthias.

[bob]

Hello Matthias,

Is there any chance - for non-programmers like me - that you could expand on that ratio of work required?

In non-programming language as far as possible.

That is an astonishing ratio.
Later.

I believe he is under-estimating the non-bitboard to bitboard effort. I have done this in three flavors. The first was the original crafty project coming from the previous Cray Blitz mailbox approach. Big learning curve. The second was re-numbering the bits since the bits were originally numbered to be efficient on a Cray, while the program effectively became a PC-based project over time. Just changing bit numbers is a _huge_ effort. There are all sorts of bit patterns used in evaluation. Or in move generation. And if you change the bit numbers, the patterns have to change as well. And the compiler doesn't warn you which patterns are wrong. Then I changed these patterns again to get rid of the black/white duplication, and it was a significant effort. Going from non-bitboards to bitboards is a huge project, since it affects almost every part of a program... evaluation, move generation, making/unmaking moves, SEE, check/attack detection, position setup, move ordering, etc. But none of this removes the fact that the original code was copied when making those changes...

The big learning curve may have applied to you as a bitboard pioneer in chess programming. My generation and younger get bitboards spoon-fed with no learning curve. Translating a non-bitboard infrastructure to a bitboard infrastructure is no big deal. The _amount_ of work to do may be high, but its _complexity_ is very low for people who think "in bitboards".

Matthias.

I do not believe people "think bitboards" until they have been immersed in them for a while. I personally don't consider writing a chess program to be a "big deal". But it is a ton of work, as is converting to/from bitboards.

[Peter Berger]

Life ( and my parents) have taught me: whenever there are various explanations of things, the most simple one is most likely to be true.

I have tried reading this document not being a programmer ( lol, certainly a sick way to spend leasure time), and it even sounds impressive if you don't understand major parts .

Isn't it just common sense to conclude that at one point in time the Rybka and the Ippolit author(s) looked at the *very* same piece of *source code* and went from there in different directions?

If one were able to make *that* kind of meaningful changes to a strange decompiled source he didn't write for himself, he were a genius IMHO, and why would he not spend his time in a much more sensible way just (re?)-starting from scratch using his own wording and logic ?!

I write this as I think this is the *obvious* conclusion every non-programmer with some basic intelligence will reach, so if this is bullshit, maybe one you programmer guys might enlighten us ( no joke).

Peter

[Michael Sherwin]

Life ( and my parents) have taught me: whenever there are various explanations of things, the most simple one is most likely to be true.

I have tried reading this document not being a programmer ( lol, certainly a sick way to spend leasure time), and it even sounds impressive if you don't understand major parts .

Isn't it just common sense to conclude that at one point in time the Rybka and the Ippolit author(s) looked at the *very* same piece of *source code* and went from there in different directions?

If one were able to make *that* kind of meaningful changes to a strange decompiled source he didn't write for himself, he were a genius IMHO, and why would he not spend his time in a much more sensible way just (re?)-starting from scratch using his own wording and logic ?!

I write this as I think this is the *obvious* conclusion every non-programmer with some basic intelligence will reach, so if this is bullshit, maybe one you programmer guys might enlighten us ( no joke).

Peter

From a logical perspective the logic that you use is no different than the logic that was used by those that were/are sure that Ippolit is some kind of ripoff of Rybka 3. The basis for your logic is that the author is obviously very intelligent while the logic of the accusers is that Ippolit was very intelligent. One bias finds for the author of Ippolit while the other bias finds against him.

[govert]

There's no question using the ideas is legal.

Reconstructing the program, or parts of it, when looking at the original can be legally problematic though. You can look up "clean room reverse engineering". And then you understand what the story about the "b code" is for

You mean that the "b code" is a specification language?

[govert]

Its possible that at least one of the authors used to be on the Rybka programming team -- the engine by itself is legal but the author might have signed some agreement preventing him from using the same ideas in another program independently. In that case Vas can sue him if he reveals himself.

So far, this i the only theory I've seen which explains the anonymity in a satisfying manner.

[govert]

The final sentence of your final paragraph is another crude distortion and the final sentence of your penultimate paragraph is totally lacking in meaning.

Wow! And I thought _I_ was good with words...

Taken out of context, this is a pretty good synthesis of the essence of Web 2.0

[Christopher Conkie]

Its possible that at least one of the authors used to be on the Rybka programming team -- the engine by itself is legal but the author might have signed some agreement preventing him from using the same ideas in another program independently. In that case Vas can sue him if he reveals himself.

So far, this i the only theory I've seen which explains the anonymity in a satisfying manner.

Now we are getting somewhere at last.



Chris