evaluation idea

[Harald]

I don't hink you can do that with hash keys. After the opening in the midgame there are far too many of them. You can't store your favourite line and hope that will be used in the game. Remember, there is an opponent on the other side of the board with his own ideas. And even if you could give a specific position with all its details a manipulated evaluation value then the engine would just try to reach exactly that, even going backwards and repeating itself.

You have to reduce your position recognition to very few basic patterns only. But that is nearly the same as having some special evaluation terms. You could look at the typical games you like your engine to play: first achieve this then that and finally another goal during the game stages. Then identify patterns and evaluation terms that represent these positional goals and give them high values. Avoid phases where the engine does not know what to do. Let it improve the position instead of shuffling pieces around aimlessly. That is complicated and if you try to follow a narrow path your opponent will find a way to take you to other unexplored grounds where you are lost.

Again I think the best you can do is descibed in the first link to the "Pawn CenterTypes" text I gave you in my first post or something similar. Some people manipulate the piece square tables at the root of the search. But as you wrote, you know that.

[maksimKorzh]

I don't hink you can do that with hash keys. After the opening in the midgame there are far too many of them. You can't store your favourite line and hope that will be used in the game. Remember, there is an opponent on the other side of the board with his own ideas. And even if you could give a specific position with all its details a manipulated evaluation value then the engine would just try to reach exactly that, even going backwards and repeating itself.

You have to reduce your position recognition to very few basic patterns only. But that is nearly the same as having some special evaluation terms. You could look at the typical games you like your engine to play: first achieve this then that and finally another goal during the game stages. Then identify patterns and evaluation terms that represent these positional goals and give them high values. Avoid phases where the engine does not know what to do. Let it improve the position instead of shuffling pieces around aimlessly. That is complicated and if you try to follow a narrow path your opponent will find a way to take you to other unexplored grounds where you are lost.

Again I think the best you can do is descibed in the first link to the "Pawn CenterTypes" text I gave you in my first post or something similar. Some people manipulate the piece square tables at the root of the search. But as you wrote, you know that.

Thank you Harald. I'll drop this idea and go for traditional evaluation implementation.
At the moment I've added double, passed and isolated pawns detection but engine is playing worse compared to the version that had no idea of these pawn... this is weird and I feel depressed...
https://github.com/maksimKorzh/chess_pr ... awns/bbc.c

[mvanthoor]

Thank you Harald. I'll drop this idea and go for traditional evaluation implementation.
At the moment I've added double, passed and isolated pawns detection but engine is playing worse compared to the version that had no idea of these pawn... this is weird and I feel depressed...
https://github.com/maksimKorzh/chess_pr ... awns/bbc.c

You are possibly adding too many functions too soon and not testing enough. (As opposite to me: I'm adding new functions too slowly and testing/experimenting too much )

It would be best if you have an engine that has a certain known base level, with as few functions as possible; only a/b-search, quiescence search, and move ordering. Test this engine extensively against other engines, so you'll know where it approximately falls in the CCRL / CEGT list. Then create a tournament with 5 engines below yours, and 5 above it, and have the engine run a gauntlet. (A gauntlet is a series of games where your engine plays every other engine, but the other engines don't play one another.) Make this gauntlet a thousand games or so, by having your engine play any other engine 10 times. Then you'll have your base rating within that pack.

Then you can add ONE evaluation function, or ONE search improvement, and then you'll have to test again, against the same pack. If your addition improved the engine, your rating should be higher.

Rinse... repeat... for 10 years... dream about catching up to Stockfish, and get depressed because you probably can't... (Then get very happy after you see where your engine is at that point, as opposed to where it started.)

At least, this is exactly what I intend to do.

Don't add multiple evaluation parameters or search improvements at once, because if you make a mistake somewhere, you won't be able to tell where it actually is. If you do this one function at a time, you will always know where the mistake is after the engine gets to play worse (or if you're really unlucky... not at all).

[towforce]

A player might think, "I play well in position type X, and my opponent tends to be weak in that type of position, so I'll play for that type of position."

I you want a computer to play for position type X, then I would think that the obvious thing to do would be to change the evaluation function to prefer that type of position. Include a method in the EF to assess how much like position type X the position being evaluated is.

That was the first thing I tried but within EF it affects the overall eval so eventually the position would over evaluated, while if match it within search it gives a "normal score", e.g. for position representing Ruy Lopez let's say we have a hash key "0x432343453" so in case of match it would return the score of -30 assuming that bishop is on b5 and it's black turn to move, while without this Ruy Lopez would score -20 with the same position if walk through static eval.

If we start with the idea that chess is a draw (which it probably is), then to win, we need to get our opponent to make a mistake. Having an EF that prefers positions where we believe our opponent to be weak would lead to our program making weaker moves than it probably otherwise would: however, if this results in positions in which the opponent is more likely to make a fatal mistake, then this would be a worthwhile sacrifice.

With regard to human players, we like to say that they have a plan - but they don't really. A plan is a list of tasks (which would be "moves" in chess) which you intend to carry out in sequence. You usually don't know what your opponent is going to do, so a detailed plan is impossible. The best you can do is to hope that your moves guide the game towards a position of type X. So really, a human with a plan is ACTUALLY doing something similar to having an EF with a preference for position type X.

Needless to say, when certain criteria are met in the game, the program should stop preferring position type X.