Uri Blass wrote: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
The percentage may be under Norman's estimate, but if you compare two programs that have been written independantly, what are the chances to find so many similarities? And by similarities I mean all these lines that are all exactly the same, in the same order, with the exception of a few change/insertion here and there.
That's the point. There are similarities that go as far as line by line match and they are spread all over the program.
The question that arises from these observations is: how did it happen?
Uri Blass wrote: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?
Uri Blass wrote: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".
Uri Blass wrote: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?
Uri Blass wrote: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 Blass wrote: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.
Uri Blass wrote: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.
bob wrote: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".
Indeed. IMO the move generator is insignificant, because it is the easiest part to change without affecting the playing strength. It also a sure way to make the program much different looking on a source level. The thought is, "Of course Rybka can't be a Fruit derivative, because it has bitboards".
My question to Uri: Look at the evidence that I posted in the other thread about the search function. Do you think that is just a coincidence?
Uri Blass wrote: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
Last edited by kranium on Mon Aug 18, 2008 8:38 pm, edited 3 times in total.
Uri Blass wrote: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.
