Fruit 2.1 vs Strelka 2.0

[Uri Blass]

I disagree about the 40-50% and it may be something like 10-20%

No similiarity in the move generator that is a significant part of strelka.
No extremely similiar code in the evaluation function that is also important part(there may be similiar ideas about evaluation but not similiar code and strelka has special code for material imbalance tables).

I do not understand how do you get at least 40-50% similiarity.

The functions that you post are clearly less than half of the code of strelka.

Uri

Hi Uri-

you have a point, i have not scientifically measured the percentage in any way shape or form, it was just my estimate. at the same time, i did not post everything. there's quite a bit more...it's clear that the total is a large and substantial amount.

move generators exist in every chess program...i don't think it is any more important in Strelka than any other program.

as I said, many of the non-similar functions are a bitboard implementation, but truly, if you follow them closely, i believe there is a close resemblance to the flow and logic of Fruit.

Norm

'

Uri seems to attach more importance to the move generator than I do. I am more interested in the search and the evaluation, as those are what makes programs different. Generating moves is a constant-in - constant-out operation, because the rules of chess moves are precisely defined. But for search and evaluation there are no "rules".

Move generator is not a constant factor and it has an effect on the search.

Order of generating moves can clearly influence the order of moves so it can have an effeect on the search.

Move generator that has tricks to generate only part of the captures also has some effect on the search.

Uri

Then let's also have a look at the order of the moves.

You could compare the order of the moves as you say you have already started to study Strelka.



// Christophe

The order is certainly not the same
For example the function of generating quiet moves in strelka starts by generating castling and later generating pawn moves.

The function of generating quiet moves in fruit starts by generating
pieces move based on piece list and only later it generates pawn moves.

Uri

[Uri Blass]

I disagree about the 40-50% and it may be something like 10-20%

No similiarity in the move generator that is a significant part of strelka.
No extremely similiar code in the evaluation function that is also important part(there may be similiar ideas about evaluation but not similiar code and strelka has special code for material imbalance tables).

I do not understand how do you get at least 40-50% similiarity.

The functions that you post are clearly less than half of the code of strelka.

Uri

Hi Uri-

you have a point, i have not scientifically measured the percentage in any way shape or form, it was just my estimate. at the same time, i did not post everything. there's quite a bit more...it's clear that the total is a large and substantial amount.

move generators exist in every chess program...i don't think it is any more important in Strelka than any other program.

as I said, many of the non-similar functions are a bitboard implementation, but truly, if you follow them closely, i believe there is a close resemblance to the flow and logic of Fruit.

Norm

'

Uri seems to attach more importance to the move generator than I do. I am more interested in the search and the evaluation, as those are what makes programs different. Generating moves is a constant-in - constant-out operation, because the rules of chess moves are precisely defined. But for search and evaluation there are no "rules".

Move generator is not a constant factor and it has an effect on the search.

Order of generating moves can clearly influence the order of moves so it can have an effeect on the search.

Move generator that has tricks to generate only part of the captures also has some effect on the search.

Uri

Hi Uri-

as far as i know, move ordering is typically done in separate functions, for ex: in Fruit they're all in sort.cpp. From what i've seen, most move generators simply generate all possible moves, and/or all possible legal moves in any given position. afterwards, move ordering helps of course...placing the most promising candidates at the top of the (to evaluate) list. but i've never seen what you're suggesting done in the move generator itself, although it does seem possible i suppose.

Best regards-
Norm

I think that the order of generating moves is also important for the move order and not only the sort function.

I know that at least in movei at some point I simply use the order that the moves were generated because sorting them is going to cost time.

It does not mean that the order is unimportant and deciding to generate pawn moves first can lead to different playing strength relative to deciding to generate knight moves first.

The question how much difference is dependent on the program but common sense tell me that there is some difference.

Uri

[Uri Blass]

I disagree about the 40-50% and it may be something like 10-20%

No similiarity in the move generator that is a significant part of strelka.
No extremely similiar code in the evaluation function that is also important part(there may be similiar ideas about evaluation but not similiar code and strelka has special code for material imbalance tables).

I do not understand how do you get at least 40-50% similiarity.

The functions that you post are clearly less than half of the code of strelka.

Uri

10-20% of similarity -- does that makes a program clone of other?

We are not at all talking about cloning.

I'm afraid this word (clone) is totally out of place in the current discussion.

We are looking at the similarities. If there are similarities then the question is: could such similarities happen in programs that have been written independently?



// Christophe

Nobody claims that strelka and fruit have been written independently
Learning from other programs is certainly legal.

You can say that the similiarity is too much but it is not clear what is the limit of too much.

I use average between opening score and endgame score based on stage of the game in Movei and I learned the idea from Fruit(I did not use it before fruit)

This similiarity is not something independent of fruit and I guess that most new programs are based on some ideas that the author learned from fruit.

Uri

Fine but we are not looking at the re-use of ideas here.

We are looking at the re-use of source code.

If you believe that the similarities are limited to the use of the same ideas, then you should look at the comparisons of source code that have been posted.



// Christophe

I do not claim that the similiarity is limited to the same ideas but I understood that they are not enough for Fabien to consider Strelka as something like toga.

Uri

[tiger]

I disagree about the 40-50% and it may be something like 10-20%

No similiarity in the move generator that is a significant part of strelka.
No extremely similiar code in the evaluation function that is also important part(there may be similiar ideas about evaluation but not similiar code and strelka has special code for material imbalance tables).

I do not understand how do you get at least 40-50% similiarity.

The functions that you post are clearly less than half of the code of strelka.

Uri

Hi Uri-

you have a point, i have not scientifically measured the percentage in any way shape or form, it was just my estimate. at the same time, i did not post everything. there's quite a bit more...it's clear that the total is a large and substantial amount.

move generators exist in every chess program...i don't think it is any more important in Strelka than any other program.

as I said, many of the non-similar functions are a bitboard implementation, but truly, if you follow them closely, i believe there is a close resemblance to the flow and logic of Fruit.

Norm

'

Uri seems to attach more importance to the move generator than I do. I am more interested in the search and the evaluation, as those are what makes programs different. Generating moves is a constant-in - constant-out operation, because the rules of chess moves are precisely defined. But for search and evaluation there are no "rules".

Move generator is not a constant factor and it has an effect on the search.

Order of generating moves can clearly influence the order of moves so it can have an effeect on the search.

Move generator that has tricks to generate only part of the captures also has some effect on the search.

Uri

Then let's also have a look at the order of the moves.

You could compare the order of the moves as you say you have already started to study Strelka.



// Christophe

The order is certainly not the same
For example the function of generating quiet moves in strelka starts by generating castling and later generating pawn moves.

The function of generating quiet moves in fruit starts by generating
pieces move based on piece list and only later it generates pawn moves.

Uri

I think the order that is relevant is the order in which moves are tried during the search.

You can generate moves in any order and this order can be closely linked to the data structure you use. In general you want to generate them as fast as possible by taking advantage of tricks made possible by your data structure.

But once the moves have been generated, they are looked at in an order which is extremely important. The order in which they have been generated does not matter, but the order in which they are tried makes a great difference in the efficiency of the search.

Now, move ordering is a matter that has been discussed over and over in public places, and there is a general consensus about what the optimal order should be.

So I expect Fruit's and Rybka's move ordering to be similar, which in itself does not mean re-use of source code. What we should look for is similarities in the move ordering code in order to see if re-use of source code has happened.



// Christophe

[tiger]

I disagree about the 40-50% and it may be something like 10-20%

No similiarity in the move generator that is a significant part of strelka.
No extremely similiar code in the evaluation function that is also important part(there may be similiar ideas about evaluation but not similiar code and strelka has special code for material imbalance tables).

I do not understand how do you get at least 40-50% similiarity.

The functions that you post are clearly less than half of the code of strelka.

Uri

10-20% of similarity -- does that makes a program clone of other?

We are not at all talking about cloning.

I'm afraid this word (clone) is totally out of place in the current discussion.

We are looking at the similarities. If there are similarities then the question is: could such similarities happen in programs that have been written independently?



// Christophe

Nobody claims that strelka and fruit have been written independently
Learning from other programs is certainly legal.

You can say that the similiarity is too much but it is not clear what is the limit of too much.

I use average between opening score and endgame score based on stage of the game in Movei and I learned the idea from Fruit(I did not use it before fruit)

This similiarity is not something independent of fruit and I guess that most new programs are based on some ideas that the author learned from fruit.

Uri

Fine but we are not looking at the re-use of ideas here.

We are looking at the re-use of source code.

If you believe that the similarities are limited to the use of the same ideas, then you should look at the comparisons of source code that have been posted.



// Christophe

I do not claim that the similiarity is limited to the same ideas but I understood that they are not enough for Fabien to consider Strelka as something like toga.

Uri

Do you mean that comparing Fruit and Rybka is useless because of Fabien's statement?

Is your point of view that nobody else than Fabien has been harmed if (and I say IF) open source code protected by the GPL has been used illegally in a proprietary program?

And what if we are just curious to know if it happened or not?



// Christophe

[kranium]

I disagree about the 40-50% and it may be something like 10-20%

No similiarity in the move generator that is a significant part of strelka.
No extremely similiar code in the evaluation function that is also important part(there may be similiar ideas about evaluation but not similiar code and strelka has special code for material imbalance tables).

I do not understand how do you get at least 40-50% similiarity.

The functions that you post are clearly less than half of the code of strelka.

Uri

10-20% of similarity -- does that makes a program clone of other?

We are not at all talking about cloning.

I'm afraid this word (clone) is totally out of place in the current discussion.

We are looking at the similarities. If there are similarities then the question is: could such similarities happen in programs that have been written independently?



// Christophe

Nobody claims that strelka and fruit have been written independently
Learning from other programs is certainly legal.

You can say that the similiarity is too much but it is not clear what is the limit of too much.

I use average between opening score and endgame score based on stage of the game in Movei and I learned the idea from Fruit(I did not use it before fruit)

This similiarity is not something independent of fruit and I guess that most new programs are based on some ideas that the author learned from fruit.

Uri

Fine but we are not looking at the re-use of ideas here.

We are looking at the re-use of source code.

If you believe that the similarities are limited to the use of the same ideas, then you should look at the comparisons of source code that have been posted.



// Christophe

I do not claim that the similiarity is limited to the same ideas but I understood that they are not enough for Fabien to consider Strelka as something like toga.

Uri

Hi Uri-

I distinctly remember that a few days ago, Dann Corbit posted Fabiens email response after Fabien reviewed Strelka source code...unfortunately, it was in the 'washed' thread, so it can't be referenced here, but in essence, Fabien's reply was something to the effect of: 'oh well, it's been re-written', and 'i cannot say yes or no' ...

clearly, this is not approval, he's caught between a big rock and hard place.

Norm

[Zach Wegner]

So I expect Fruit's and Rybka's move ordering to be similar, which in itself does not mean re-use of source code. What we should look for is similarities in the move ordering code in order to see if re-use of source code has happened.

Although they look different on the surface, on closer inspection they are quite similar. I'll look deeper into later, and also see how Strelka matches up with Rybka here. The main difference that I can see is that Strelka uses SEE rather than simple mvvlva, but quite strangely, it does not value the moves based on this, only sees whether they are losing or not--consistent with the capture_is_good() function in Fruit being a bool. I don't know of any other program with a SEE that returns bool, but it must be rare if not unique.

[Uri Blass]

I disagree about the 40-50% and it may be something like 10-20%

No similiarity in the move generator that is a significant part of strelka.
No extremely similiar code in the evaluation function that is also important part(there may be similiar ideas about evaluation but not similiar code and strelka has special code for material imbalance tables).

I do not understand how do you get at least 40-50% similiarity.

The functions that you post are clearly less than half of the code of strelka.

Uri

Hi Uri-

you have a point, i have not scientifically measured the percentage in any way shape or form, it was just my estimate. at the same time, i did not post everything. there's quite a bit more...it's clear that the total is a large and substantial amount.

move generators exist in every chess program...i don't think it is any more important in Strelka than any other program.

as I said, many of the non-similar functions are a bitboard implementation, but truly, if you follow them closely, i believe there is a close resemblance to the flow and logic of Fruit.

Norm

'

Uri seems to attach more importance to the move generator than I do. I am more interested in the search and the evaluation, as those are what makes programs different. Generating moves is a constant-in - constant-out operation, because the rules of chess moves are precisely defined. But for search and evaluation there are no "rules".

Move generator is not a constant factor and it has an effect on the search.

Order of generating moves can clearly influence the order of moves so it can have an effeect on the search.

Move generator that has tricks to generate only part of the captures also has some effect on the search.

Uri

Then let's also have a look at the order of the moves.

You could compare the order of the moves as you say you have already started to study Strelka.



// Christophe

The order is certainly not the same
For example the function of generating quiet moves in strelka starts by generating castling and later generating pawn moves.

The function of generating quiet moves in fruit starts by generating
pieces move based on piece list and only later it generates pawn moves.

Uri

I think the order that is relevant is the order in which moves are tried during the search.

You can generate moves in any order and this order can be closely linked to the data structure you use. In general you want to generate them as fast as possible by taking advantage of tricks made possible by your data structure.

But once the moves have been generated, they are looked at in an order which is extremely important. The order in which they have been generated does not matter, but the order in which they are tried makes a great difference in the efficiency of the search.

Now, move ordering is a matter that has been discussed over and over in public places, and there is a general consensus about what the optimal order should be.

So I expect Fruit's and Rybka's move ordering to be similar, which in itself does not mean re-use of source code. What we should look for is similarities in the move ordering code in order to see if re-use of source code has happened.



// Christophe

I agree that the order that moves are tried is important but the order that they are tried is usually function of the order that they are generated.

What programs do when there is no hash no killer and no captures
They can use history but what if there is no history in the first search
and different first searchs can lead to different killers that again lead to different order of moves later.


Uri

[geots]

I disagree about the 40-50% and it may be something like 10-20%

No similiarity in the move generator that is a significant part of strelka.
No extremely similiar code in the evaluation function that is also important part(there may be similiar ideas about evaluation but not similiar code and strelka has special code for material imbalance tables).

I do not understand how do you get at least 40-50% similiarity.

The functions that you post are clearly less than half of the code of strelka.

Uri

10-20% of similarity -- does that makes a program clone of other?

We are not at all talking about cloning.

I'm afraid this word (clone) is totally out of place in the current discussion.

We are looking at the similarities. If there are similarities then the question is: could such similarities happen in programs that have been written independently?



// Christophe

Nobody claims that strelka and fruit have been written independently
Learning from other programs is certainly legal.

You can say that the similiarity is too much but it is not clear what is the limit of too much.

I use average between opening score and endgame score based on stage of the game in Movei and I learned the idea from Fruit(I did not use it before fruit)

This similiarity is not something independent of fruit and I guess that most new programs are based on some ideas that the author learned from fruit.

Uri

Fine but we are not looking at the re-use of ideas here.

We are looking at the re-use of source code.

If you believe that the similarities are limited to the use of the same ideas, then you should look at the comparisons of source code that have been posted.



// Christophe

I do not claim that the similiarity is limited to the same ideas but I understood that they are not enough for Fabien to consider Strelka as something like toga.

Uri

Hi Uri-

I distinctly remember that a few days ago, Dann Corbit posted Fabiens email response after Fabien reviewed Strelka source code...unfortunately, it was in the 'washed' thread, so it can't be referenced here, but in essence, Fabien's reply was something to the effect of: 'oh well, it's been re-written', and 'i cannot say yes or no' ...

clearly, this is not approval, he's caught between a big rock and hard place.

Norm

I disagree very, very much. Clone is not "out of place" in this discussion. Simply because for me, all this technical stuff is no doubt way over my head. Im just a tester, and you guys lose me with the first sentence in these threads. What IS IMPORTANT for me would be fi Bob, Ingo, Uri, Theron, etc. would tell me where we exactly stand now with the Strelka-Fruit- Rybka issue. IOW, is it still more or less agreed the Strelka is a clone- and i guess im asking "illegal" clone of something- to the point where CCRL should still not be testing it- as we did stop?

Best,

[Rolf]

I disagree very, very much. Clone is not "out of place" in this discussion. Simply because for me, all this technical stuff is no doubt way over my head. Im just a tester, and you guys lose me with the first sentence in these threads. What IS IMPORTANT for me would be fi Bob, Ingo, Uri, Theron, etc. would tell me where we exactly stand now with the Strelka-Fruit- Rybka issue. IOW, is it still more or less agreed the Strelka is a clone- and i guess im asking "illegal" clone of something- to the point where CCRL should still not be testing it- as we did stop?

Best,

Agree 100%. IMO the whole campaign is exactly made for the purpose to trick lays like us. The real expertsw like Bob already know for 100 or 99% what is going on in all programs. At least they could find out if they wanted. But seeing here suddenly test result with Str__2.0 looks like a shame to me. It's as if suddenly the experts wanted to tell us the message: as long as Vas doesnt give in the blackmail continues.

However all people will continue to enjoy the best and that's still the program Vas has brought out legally.

To observers from Mars this here is looking like the earthlings goe mad in the moment someone appears who does it better than all before. They must crucify him. It's against --- well what after all. Therefore the thread with the word envy says it all.