En Croissant - a new chess GUI

[fransal]

Forced en passant is an option that I haven't seen before

It's a meme from reddit's AnarchyChess. It's a stupid subreddit (IMHO) that pops up in your reddit feed if you do anything remotely chess-related. Often people get caught off-guard and some newcomers to chess actually think that some of the crap they post are actual chess rules until someone points out to them that AnarchyChess is a meme subreddit.

It's definitely silly, but they do have some good memes sometimes, when it isn't just another repost of the same joke for the 50th time. I'm a big fan of the Anti-Queen for example.

[mvanthoor]

[*]Move encoding. I had a version where I was using the same 2-byte encoding used by Banksia, but I ended changing to the 1-byte encoding I described earlier. Banksia allows for 3 different types of move encoding, and I'm not sure that's a good idea for a standard. I believe it should just have 1 encoding, optimized for performance and size.

How did you encode the moves in one byte? If you go by "from" and "to" square, you have 4 bits for each square, which is not enough because you can only go up to 15. You'd need 12 bits for one move. Is there a database schema somewhere, or do I have to just go and create a database, open it, and then look through the code?

PS: Even though its tongue in cheek, I love the "En Croissant" name and the fact that you actually have a website for it.

[fransal]

[*]Move encoding. I had a version where I was using the same 2-byte encoding used by Banksia, but I ended changing to the 1-byte encoding I described earlier. Banksia allows for 3 different types of move encoding, and I'm not sure that's a good idea for a standard. I believe it should just have 1 encoding, optimized for performance and size.

How did you encode the moves in one byte? If you go by "from" and "to" square, you have 4 bits for each square, which is not enough because you can only go up to 15. You'd need 12 bits for one move. Is there a database schema somewhere, or do I have to just go and create a database, open it, and then look through the code?

PS: Even though its tongue in cheek, I love the "En Croissant" name and the fact that you actually have a website for it.

I'm not using a "from-to" type of encoding. The byte is a number that represents the index of the encoded move in the list of legal moves in that position.

https://www.chessprogramming.org/Encodi ... Move_Index

In fact, the encoding code is so simply I'll just put it here

Code: Select all

use shakmaty::Chess;

pub fn encode_move(m: &Move, chess: &Chess) -> Result<u8, String> {
    let moves = chess.legal_moves();
    Ok(moves.iter().position(|x| x == m).unwrap() as u8)
}

fn decode_move(byte: u8, chess: &Chess) -> Option<Move> {
    let legal_moves = chess.legal_moves();
    legal_moves.get(byte as usize).cloned()
}

I still don't have documentation, but it's one of the things I wish to do before a 1.0 release.

[mvanthoor]

I'm not using a "from-to" type of encoding. The byte is a number that represents the index of the encoded move in the list of legal moves in that position.

https://www.chessprogramming.org/Encodi ... Move_Index

In that case, don't you have to play through every game to find the actual move, when you export it from the database to a PGN for example? I imagine you'd also need to store all the positions you ever encountered, because otherwise you'd need to play through all the games in the database if you want to find the ones with a certain position.

[fransal]

I'm not using a "from-to" type of encoding. The byte is a number that represents the index of the encoded move in the list of legal moves in that position.

https://www.chessprogramming.org/Encodi ... Move_Index

In that case, don't you have to play through every game to find the actual move, when you export it from the database to a PGN for example? I imagine you'd also need to store all the positions you ever encountered, because otherwise you'd need to play through all the games in the database if you want to find the ones with a certain position.

Storing all the positions separately would take way too much space. The search does works by playing every game, and I think that's how other chess databases work as well.

In reality, it's not as bad as playing every move from every game. For example, if you're searching for the position after e4, then when looking through the games it will skip to the next game when finding a pawn move other than e3 or e4. Or if you're searching for an endgame position, it will skip games that didn't reach a material count as low as the one you're searching for.

It ends ups being quite fast to search any position in a database with a few million games (a few hundred milliseconds on my computer).

[mvanthoor]

Storing all the positions separately would take way too much space. The search does works by playing every game, and I think that's how other chess databases work as well.

In reality, it's not as bad as playing every move from every game. For example, if you're searching for the position after e4, then when looking through the games it will skip to the next game when finding a pawn move other than e3 or e4. Or if you're searching for an endgame position, it will skip games that didn't reach a material count as low as the one you're searching for.

It ends ups being quite fast to search any position in a database with a few million games (a few hundred milliseconds on my computer).

I also thought that storing all Zobrist hashes would take too much space. But, you can't just skip games the way you do because you'll miss lots of transpositions. If you skip a game if it starts with d4, it can still turn out to be a game after e4 too.

[fransal]

Storing all the positions separately would take way too much space. The search does works by playing every game, and I think that's how other chess databases work as well.

In reality, it's not as bad as playing every move from every game. For example, if you're searching for the position after e4, then when looking through the games it will skip to the next game when finding a pawn move other than e3 or e4. Or if you're searching for an endgame position, it will skip games that didn't reach a material count as low as the one you're searching for.

It ends ups being quite fast to search any position in a database with a few million games (a few hundred milliseconds on my computer).

I also thought that storing all Zobrist hashes would take too much space. But, you can't just skip games the way you do because you'll miss lots of transpositions. If you skip a game if it starts with d4, it can still turn out to be a game after e4 too.

I meant that you can skip if you're searching for the position after the move 1. e4, meaning this position:

[fen]rnbqkbnr/pppppppp/8/8/4P3/8/PPPP1PPP/RNBQKBNR b KQkq - 0 1[/fen]

You can always skip the game if you move a pawn that wasn't moved in the target position.

[mvanthoor]

I meant that you can skip if you're searching for the position after the move 1. e4, meaning this position:

[fen]rnbqkbnr/pppppppp/8/8/4P3/8/PPPP1PPP/RNBQKBNR b KQkq - 0 1[/fen]

You can always skip the game if you move a pawn that wasn't moved in the target position.

Oh, yeah. If you are searching for specifically that position and someone plays d4 then this position can never occur again indeed. I misunderstood your previous post.

[fransal]

I've just released version 0.3.0! I've added a lot improvements to the game report feature.

Here's how the report looks like for the game from today's round of the World Championship.

[jshriver]

This is very impressive! Bookmarked it so I can keep tabs on update. Very clean, nice options. Even like how it can autodownload various databases and the analysis window.