Progress on Rustic

[Pio]

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.

Just override the tostring() method for the board class and you won’t have to see its ugly representation . I have a much more ugly representation than bitboard or any other representation but when I watch my struct it looks like a beautiful 8x8 char array with new lines and everything. The only thing that looks a little bit different in my tostring() method is that rooks that haven’t lost their castle potential are represented by a different char than normal rooks and if an enpassant pawn is present it is also represented by another char. I also don’t print if it is white or blacks turn because I don’t care, since everything is from the side to move point of view.

If you want to repeat debugging just put a conditional breakpoint with the same board number as before.

[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.

Just override the tostring() method for the board class and you won’t have to see its ugly representation . I have a much more ugly representation than bitboard or any other representation but when I watch my struct it looks like a beautiful 8x8 char array with new lines and everything. The only thing that looks a little bit different in my tostring() method is that rooks that haven’t lost their castle potential are represented by a different char than normal rooks and if an enpassant pawn is present it is also represented by another char. I also don’t print if it is white or blacks turn because I don’t care, since everything is from the side to move point of view.

If you want to repeat debugging just put a conditional breakpoint with the same board number as before.

Yes that may work for the board class but not for an ulong/UInt64. Don't know how to override ulong.ToString(). There are also ulong's who have nothing to do with bitboards. Probably already too late in my code to make a class for a ulong which represents a bitboard.

[Pio]

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.

Just override the tostring() method for the board class and you won’t have to see its ugly representation . I have a much more ugly representation than bitboard or any other representation but when I watch my struct it looks like a beautiful 8x8 char array with new lines and everything. The only thing that looks a little bit different in my tostring() method is that rooks that haven’t lost their castle potential are represented by a different char than normal rooks and if an enpassant pawn is present it is also represented by another char. I also don’t print if it is white or blacks turn because I don’t care, since everything is from the side to move point of view.

If you want to repeat debugging just put a conditional breakpoint with the same board number as before.

Yes that may work for the board class but not for an ulong/UInt64. Don't know how to override ulong.ToString(). There are also ulong's who have nothing to do with bitboards. Probably already too late in my code to make a class for a ulong which represents a bitboard.

Why would you want to do a class for each bitboard? Why not show them together in a 8x8 fashion just like you watch the board?

[Pio]

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.

Just override the tostring() method for the board class and you won’t have to see its ugly representation . I have a much more ugly representation than bitboard or any other representation but when I watch my struct it looks like a beautiful 8x8 char array with new lines and everything. The only thing that looks a little bit different in my tostring() method is that rooks that haven’t lost their castle potential are represented by a different char than normal rooks and if an enpassant pawn is present it is also represented by another char. I also don’t print if it is white or blacks turn because I don’t care, since everything is from the side to move point of view.

If you want to repeat debugging just put a conditional breakpoint with the same board number as before.

Yes that may work for the board class but not for an ulong/UInt64. Don't know how to override ulong.ToString(). There are also ulong's who have nothing to do with bitboards. Probably already too late in my code to make a class for a ulong which represents a bitboard.

Why would you want to do a class for each bitboard? Why not show them together in a 8x8 fashion just like you watch the board?

If you really want to see another representation of your ulong just write an extension method (see https://docs.microsoft.com/en-us/dotne ... on-methods)

[mvanthoor]

Well...

Maybe I'm just REALLY old fashioned, but while I was writing my move generator, I just printed my bitboards to the screen in the console, in an 8x8 representation, with the relevant square in purple (because that was the easiest color, besides white, to see against my console's background). I checked all the generated bitboards (piece movements on an empty board, and slider array bitboards) visually.

Proceeding very slowly, testing each new function extensively, I basically only hit one bug: the one where I forgot to remove castling rights if a rook was captured in its starting position. (I have never encountered this in an over the board game.)

The key with regard to low level code is to go slowly and keep it as simple as possible.

I haven't encountered any problems writing this chess engine, except for gaps in my knowledge regarding some of the concepts; but those have either been filled in already, or are getting better.

[Terje]

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.

There is for UCI - engine POV only

[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.

Just override the tostring() method for the board class and you won’t have to see its ugly representation . I have a much more ugly representation than bitboard or any other representation but when I watch my struct it looks like a beautiful 8x8 char array with new lines and everything. The only thing that looks a little bit different in my tostring() method is that rooks that haven’t lost their castle potential are represented by a different char than normal rooks and if an enpassant pawn is present it is also represented by another char. I also don’t print if it is white or blacks turn because I don’t care, since everything is from the side to move point of view.

If you want to repeat debugging just put a conditional breakpoint with the same board number as before.

Yes that may work for the board class but not for an ulong/UInt64. Don't know how to override ulong.ToString(). There are also ulong's who have nothing to do with bitboards. Probably already too late in my code to make a class for a ulong which represents a bitboard.

Why would you want to do a class for each bitboard? Why not show them together in a 8x8 fashion just like you watch the board?

If you really want to see another representation of your ulong just write an extension method (see https://docs.microsoft.com/en-us/dotne ... on-methods)

For methods like GetPassers or AttackedSquares returning an ulong. Maybe best to return an BitBoard because for node counting I use ulong as well.

[Henk]

No name should be ISquareSet or IFieldSet. Bitboard is an implementation detail like a database and should be hidden.

Fact that I can't replace Board means that it is not modular. So violating rules of good design.

Result of some stupid optimizations I did some years ago.

[mvanthoor]

Well, almost there before the engine can play its first (preliminary) game in a GUI. (Before testing, I still want to implement at least QSearch, PV, and a TT.)

The UCI protocol is coming along nicely:

Incoming
- uci
- isready
- ucinewgame (does this anything else but resetting the board and clearing the TT ? The spec doesn't say a lot about it, apart from the fact that GUI's often don't send it but should if a new game starts.)
- position fen <fen_string> [moves ...]
- position startpos [moves ...]
- quit

Outgoing:
- id name, id author
- uciok
- readyok

Things such as copyprotection and register are going to be skipped. Some commands will be implemented as I add functionality to the engine that require them. (Such as "setoption", obviously). Next will be "go" in all its infinite combinations (pun intended), "stop" (that'll be easy ) and "info", so I can actually see something in the GUI. And at that point, Rustic can actually play... even though it doesn't send any PV to the GUI yet.

Oh; in the process, I nuked the custom console. I used all of its code except for the commands as boilerplate for the UCI module. After version 1.0, version 1.1 will probably be implementation of XBoard / Winboard. And I actually do have to test this thing in Linux and on a Raspberry.

[Terje]

ucinewgame should reset TT and any other stuff you keep from turn to turn during a single game - could be things like previous turns final search depth, whether you saved time last move and want to spend more the coming turn etc. In Weiss this is still just clearing TT and resetting number of failed queries to chessdb.cn if using NoobBook.

It doesn't have to reset the board (though it doesn't hurt); a position command must be sent before each go command. Setting up the board on startup is nice for humans doing a quick manual test, but manually playing a full game and starting a new one ucing UCI in a terminal seems unlikely.

Getting close, keep at it