It is not as much about parameters as is the funcion (program itesef) who takes such parameters. There a lot more that making 3pawns==1knigt==1bishop parameters. It is about functions who can evaluate positions. First you need funcion and thet you assing some numerical parameters if needed. And is still much much more.

OK, here's an attempt to give you some background.

Almost every current chess program in the world basically works in the same way: You take a position, you evaluate it. Then you possibly make one or more moves from that position and evaluate the resulting position. Continue until you're happy or you decide you don't want to spend more time (for instance, because you are out of time :-) ).

Now, there are two different parts in this mechanism: How do you evaluate a position, and how do you decide to check further moves (and in that case, what moves). There are other design criteria -- for instance, how do you represent the board and the pieces in memory -- that are indeed important (and some of the decisions in the two parts I singled out naturally follow from that), but for the sake of this discussion, you can look at them as implementation details.

Both the evaluator function and the tree-generating algorithm (let's call "which moves do I try" that, in lack of a better name) are usually found in terms of solid, hard code. For instance, the simplest evaluator possible would probably be just counting the material value of the pieces on the board and summing those up. If that's your evaluator, no parameter tweaking in the world will let it play the same as a chess program whose evaluator function can also recognize that the knight is better off near the center of the board. Note that there are literally thousands of possible things an evaluator could look at, and just the weighing of the features against each other would then give you as many parameters to tune. Optimizing a parameter space this large for _anything_ is difficult -- I doubt optimizing it for "evaluates like Rybka" will be much easier than optimizing it for "plays the best possible chess", which is what you usually want. Also, you'll have to take into account that usually, there is a time budget, and the same machine will often play rather different depending on how much time it can spend on a move. (Speed versus evaluator function refinement is one of the infinite struggles of a computer chess author. I can add this neat feature here to the evaluator, but it slows it down by 5%, so I get to look at fewer positions overall and thus look a bit less deep.... is it worth it?)

However, the evaluator function is only part of the puzzle. The tree-generating algorithm is even more code and usually even less tuning. Unless you start going into genetic algorithms or something (which still would probably be in a specialized language, using a set of known AI/search/heuristic primitives), you'll have an extremely hard time just parameterizing your problem into a form where you can easily change the "personality" of an engine. There are always tweaks that can be made -- see for instance Rybka's "outlook" setting -- but again, if your algorithm cannot do feature X in the first place, no parameter tweaking in the world is going to change that.

Of course, the world is not black and white -- if you don't have feature or parameter X, perhaps Y, Z, W and Q could weigh up for it enough that the results would be largely the same. (Also, you do have a point in that there _are_ many tweakable parameters out there -- and many engine makers probably tweak them more or less automatically using some sort of game statistics.) However, at that point, I guess the question is: If you can tweak your engine that much, why tune it to imitate another engine? Wouldn't you instead want to tune it towards always making the right moves? Or: As engine maker, how many parameters would you expose to the user? Usually it's better for speed (and thus playing strength) to hard code some (or a lot of) decisions, not to mention that you expose fewer engine internals (making your product harder to black-box reverse engineer) _and_ produce a less confusing overall system to the user. After all, making this sort of tuning is usually extremely hard for someone who's not intimately familiar with the engine's working.

/* Steinar */