On-line engine blitz tourney August

[hgm]

You write "while searching", but I assume you mean that this was the best path found during the search, and printed afterwards (the Principal Variation). I sometimes also print the path it is currently searching (to identify the node where it crashes), but that is really very dynamic, and changes a million times per second.

[flok]

You write "while searching", but I assume you mean that this was the best path found during the search, and printed afterwards (the Principal Variation). I sometimes also print the path it is currently searching (to identify the node where it crashes), but that is really very dynamic, and changes a million times per second.

Yes, the principal variation.

depth 5:

Code: Select all

1 -230 444 1594556 H7-H5 F1-B5 H8-H7 D1-F3 E7-E6

depth 6:

Code: Select all

1 -200 21991 176793738 B8-A6 F1-B5 E7-E5 D2-D3 F8-B4 C2-C3

depth 7:

Code: Select all

1 -175 231984 1319142280 G8-F6 E1-E2 D7-D6 E2-E1 F6-D5 E4-D5 C8-F5

[hgm]

Well, it doesn't seem to blunder material away, at least. But moves like Ke2 of course are very bad because they destroy your castling rights. But the engine can only know that when you actually award points in the eval for having castling rights. Do you award such points? Do you award them with the correct sign? My engine Joker once did this with black in Leiden because I had inadvertantly forgotten to flip the sign of an eval term for black that was supposed to penalize moving up its Pawn before the King. It worked only on a King that had no castling rights, to not suppress 1. e4 and such. So it ententialy moved the King up and down to destroy its castling rights, and reap the heavy bonus for the 'hole' in front of its King.

Of course another worry is that it wastes time by playing Ke2 and then Ke1, even apart from the castling rights. That could be an indication that all other moves score negative. Which is a consequence of not giving enough bonus for moving Pawns forward.

[flok]

Hi,

Well the evaluator is basic now until I'm confident that all works as it should.

Fwiw: I analyzed 2+ million games to see what mostly constants should really be.
For example for evaluation of the location of pieces.
I found this on the web (for each piece type):

Code: Select all

                final int [] bishop = {
                        -20,-10,-10,-10,-10,-10,-10,-20,
                        -10,  0,  0,  0,  0,  0,  0,-10,
                        -10,  0,  5, 10, 10,  5,  0,-10,
                        -10,  5,  5, 10, 10,  5,  5,-10,
                        -10,  0, 10, 10, 10, 10,  0,-10,
                        -10, 10, 10, 10, 10, 10, 10,-10,
                        -10,  5,  0,  0,  0,  0,  5,-10,
                        -20,-10,-10,-10,-10,-10,-10,-20 };

I think this constants are not correct, like b2 and b3 really have different values.

Anyway, the current evaluation is:

Code: Select all

(number of queens me - queens opponent) * 975
+ (number of bishops me - bishops opponent) * 325
+ (number of bishops me >= 2? 25 extra points)
- (number of bishops opponent >= 2? 25  points)
+ (number of knights me - knights opponent) * 325
+ (number of rooks me - rooks opponent) * 500
+ (number of pawns - pawns opponent) * 100
- (number of left behind pawns for me - opponent left behind pawns) * 50
- (number of isolated pawns - opponent) * 50
- (number of double pawns - opponent) * 50
+ (number of moves me - number of moves opponent) * 10

[hgm]

Well, the number of moves of Pawns in the mobility could be a problem. On the 2nd rank they have 2 moves, but once you move them, they have only one. So there is an implicit penalty of 10 points for moving Pawns. If your piece-square table is such that you won't easily earn those 10 points back, it will not see any benefit in moving Pawns. And as it might not have enough other moves to keep it busy for the full depth of the search, it might not worry too much about wasting time.

But I think all this is of secondary interest. First you should make sure that your search works correctly, and only then you should worry about evaluation. For with a defective search, there is no guarantee that it will go for the best eval anyway. And there are positions where it trivially blunders away material, which is certainly heavily penalized even with the simple eval you show here. You should first focus on those positions, and fix things so that it doesn't voluntarily give up material anymore.