Progress on Rustic

[mvanthoor]

Weiss scores the position -550 or so at those depths with c5 as best move so the output looks reasonable. QSearch will probably fix the odd/even jumps.

It seems my personal, didn't-look-anywhere-else material values and PSQT's do a reasonable job then

I hope QSearch will also fix the engine starting to play more defensively as depth goes up. It started out with lines such as "1. d2d4 d7d5 2.c2c4 e7e5" when playing black, and it played things like Sicilian variations against e4. With white it often played e4 and did everything it could to push d4. With the same PSQT on higher depths, it's dropping back to crap like the French opening, and then things such as d6, b6, g6, and with white it opens with e3 and d3. I've "fixed" this by giving moves with the center pawns a massive bonus.

I assume / hope that the engine is just 'afraid' of getting pieces captured because it can't see that it can capture back due to missing QSearch, and that I can use more normal PSQT's again after I add this.

For UCI you print eval relative to the side you search for.

Thanks. But still, which one is correct? (I'm just not sure...)

If I'm not mistaken, the evaluation function HAS to report evaluation from the side that is to move next, hasn't it?

For example, the starting position with a rook missing... when I set up this position, and type "e", the engine prints the evaluation score as it comes from the evaluation function. (See below.) As it prints 500 if white is to move, and -500 if black is to move, I assume this is correct (because the evaluation is correct for each viewpoint). During during the search, the evaluation will thus alternate between 500 and -500 (if there weren't any other factors beside this missing rook). But still, if the engine is playing black, -500 should be sent to the GUI at any depth, right?

White to move:

Code: Select all

================================================

8   . n b q k b n r
7   i i i i i i i i
6   . . . . . . . .
5   . . . . . . . .
4   . . . . . . . .
3   . . . . . . . .
2   I I I I I I I I
1   R N B Q K B N R

    A B C D E F G H

Zobrist key:        6379f48865fa79a8
Active Color:       White
Castling:           KQk
En Passant:         -
Half-move clock:    0
Full-move number:   1

Rustic > e
Evaluation: 500
Rustic >

Black to move:

Code: Select all

================================================

8   . n b q k b n r
7   i i i i i i i i
6   . . . . . . . .
5   . . . . . . . .
4   . . . . . . . .
3   . . . . . . . .
2   I I I I I I I I
1   R N B Q K B N R

    A B C D E F G H

Zobrist key:        7f5330d54a3b4b0e
Active Color:       Black
Castling:           KQk
En Passant:         -
Half-move clock:    0
Full-move number:   1

Rustic > e
Evaluation: -500
Rustic >

Nice progress

Thanks Now that the implementation of communication between threads has settled down, it's mostly just busy-work like packing/unpacking/parsing information and sending it where it needs to go. It won't be too long now before the engine can actually be connected to a GUI.

The only thing left to do now is dotting i's and crossing t's, and debating how much functionality I will add before I start play-testing it and then releasing it. It'll probably will be released with QSearch, a TT, and a PV, and I'll do additional sorting later in a version 1.1.

[mvanthoor]

This sending of evaluation is harder than writing the actual magic bitboards

If BLACK is a ROOK DOWN, the GUI will show +5.00 for WHITE.

Sending evaluations from the engine's point of view means it needs to send -500 if it is playing black (all the time, at every depth), and +500 if it is playing white (all the time, at every depth). Is that correct? If so, then I'd need to flip the evaluation "right way up" at each depth, because the eval function will return +500 if it's white's move, and -500 if it's black's move as it goes through the depths.

[mvanthoor]

Sometimes I forget or ignore things I don't like. In this case, it's chess GUI's. I use Chessbase/Fritz, because I consider it the most usable and polished (but far from perfect). However I just remembered that Arena does have a log window, so I downloaded the portable version and looked at the incoming engine messages.

If I set up a position with a black rook missing, and white to move, the incoming messages all have an eval of 592 (advantage engine/white).
If I set up the same position but with black to move, all incoming messages have an evaluation of -592 (disadvantage for engine/black).

If I reverse this and set up with white having a rook less, with white to move and then having the engine analyse, it sends -609 (disadvantage engine/white).

So it looks like I just have to keep sending the evaluation from the POV of the engine, and thus turn it "right way up" first if the evaluation function delivers the eval for the other color.

[Henk]

"Board" handles the board and makes/unmakes moves onto it.

Board of my engine is not replaceable. Tried once to repair that but got crazy of the errors.
So best is to start with a non-bitboard implementation. And if one wants to use bitboards later then one must not change it's interface.
Bitboards makes it more difficult to debug. So if you want an easy life better not use them.

[Joost Buijs]

If I set up a position with a black rook missing, and white to move, the incoming messages all have an eval of 592 (advantage engine/white).
If I set up the same position but with black to move, all incoming messages have an evaluation of -592 (disadvantage for engine/black).

If I reverse this and set up with white having a rook less, with white to move and then having the engine analyse, it sends -609 (disadvantage engine/white).

So it looks like I just have to keep sending the evaluation from the POV of the engine, and thus turn it "right way up" first if the evaluation function delivers the eval for the other color.

There is no rule about how you should show the evaluation, some engines show it from a White POV, most others show it from the engines POV. Just do what you think is the most convenient.

[mvanthoor]

Board of my engine is not replaceable. Tried once to repair that but got crazy of the errors.
So best is to start with a non-bitboard implementation. And if one wants to use bitboards later then one must not change it's interface.
Bitboards makes it more difficult to debug. So if you want an easy life better not use them.

I don't understand. Bitboards aren't harder to use (for me) than array-based representations. The only hard thing was finding out how the magics work and are generated.

I could have built an interface for the board struct/object (and for the move generator as well), but I didn't see the point. I don't see myself completely changing the board representation in an engine from one type to the other by writing a different representation to the same interface.

My engine started out with an array-based representation, and then I decided I wanted to go for magic bitboards, when the array-based representation and move generator was 75^% done already. What I did was to start writing a new board representation, alongside the old one, and keep them both updated. Then I started switching functions from using one board to another. At some point, the engine was doing its move generation for some pieces using the array-based board, and for other pieces it was using the bitboards. When all functions used the bitboards only, I deleted the array-based board, and then did some variable renaming.

That way I switched from one representation to the other without much problems, but it was quite some work, obviously.

This way of phasing out older code is actually a well-known way of evolving an application; I did it many times before, in non-chess programs.

[Joost Buijs]

"Board" handles the board and makes/unmakes moves onto it.

Board of my engine is not replaceable. Tried once to repair that but got crazy of the errors.
So best is to start with a non-bitboard implementation. And if one wants to use bitboards later then one must not change it's interface.
Bitboards makes it more difficult to debug. So if you want an easy life better not use them.

In the very past I always used mailbox representation, never used 0x88 though, since the last 20 years or so I solely use bit-board representation and I will never go back. Debugging bit-boards is not difficult at all, on the contrary, it also makes evaluation a lot faster and easier.

[Henk]

I mean if you get a 64 bits integer telling which squares are attacked you can't see if it is correct.
But when you get a list of coordinates you can.

[Joost Buijs]

I mean if you get a 64 bits integer telling which squares are attacked you can't see if it is correct.
But when you get a list of coordinates you can.

Really? It's very simple to display a bit-board in a text window with a normal board representation.

something like this:

Code: Select all

constexpr bb_t Bit(int x) { return 1ULL << x; }
inline int  Sq(int x, int y) { return x + (y << 3); }

// show a bitboard on the console
void show_bb(bb_t_t bb)
{
	for (int y = 7; y >= 0; y--)
	{
		for (int x = 0; x <= 7; x++)
		{
			if (bb & Bit(Sq(x, y))) printf(" 1");
			else printf(" .");
		}
		printf("\n");
	}
	printf("\n");
}

It's just as easy to translate it to a list of coordinates.

[Henk]

No not easy. If I step in the source code using a debugger and have to open an extra window to inspect a bitboard. Not easy enough.
Usually when I have stepped through hundreds of lines of source code to find the bug everything is already too much.
Sometimes you press accidentally a wrong button and you have to repeat the whole procedure for you skipped the right move on the right depth.

Debugging is terrible. Debugging bitboards even more terrible.