lmader wrote:The point, I think, is in clarifying at what level a sequence of programming steps can be called an algorithm, vs at what point a sequence of programming steps represents using someone else's specific implementation.
So, in chess programming, we have an algorithm for evaluating a board position. The input to the algorithm is the board representation, the output is a number representing the evaluation. This algorithm necessarily needs to go through many steps - considering pawn structure, piece mobility, king safety, etc. Each of these steps can be thought of as a component in the evaluation algorithm. Each one of these individual evaluation components is itself an algorithm (i.e, an algorithm to compute how the pawns in front of the king affect its safety). And each evaluation component uses algorithms to do its work (iterate over squares, then bitmask, shift, etc).
At a certain point you could say that the entire chess program is just an algorithm for computing moves, and thus the entire thing can't be protected. Obviously there is a level of abstraction that goes too far when defining the concept of an algorithm. It is this level of abstraction for algorithm definition that must be addressed.
In private communications with Dalke, I was reduced to trying to explain evaluation features as the subtask hierarchy of the evaluation function. I don't know if that helps or not (it is closer to the vocabulary used in copyright cases, but obviously the ICGA documents shouldn't be written that way).
The evaluation of a chess position can be written an infinite number of ways, and the choices made in terms of what to consider, what is useful knowledge vs what isn't, has been an area that chess programmers all do differently, and there is no single best answer. This area is always being changed and improved. The EVAL_COMP document shows that Vas took a huge number of the same eval components as Fruit and used them in the same order.
The statements about ordering are not quite correct. As I noted to Schröder at one point, it is hard to say anything one way or the other. [The number of ways is not "infinite", but large. There is also the fact that there is a large number of
reasonable ways of writing eval, whereas this is not so true with something like move generation].
This is the crux of the issue. User923005 and others argue that Fruit's choice of eval components [...] is simply an algorithm that is not protectable. This is not true, because the level of creative art involved in arriving at these choices goes way beyond the definition of simple algorithm -> it is the heart of what makes Fruit's algorithm excellent. To say that Fruit's evaluation is just an algorithm that can be taken and used pretty much as is, is to take that level of abstraction too far.
I think Dalke argues that such algorithmic design falls under patent law, at least by the current balances struck in the laws. [He has never stated anything explicitly AFAIK, but I sense he takes US copyright/patent law as normative in his commentary].
