Development of Shen Yu

[Tearth]

I finally fixed it. It turns out that because I was setting beta and alpha to be the max value for i16 and min value for i16 respectively at the search initialization, there were some integer overflow/underflow errors. Alpha is thus -32768 and beta is 32767, so when I negated alpha to place as beta it actually overflowed because there is no representation of 32768 in 16 bit integer, it overflows back down to -32768 (I think).

Oh yeah, I feel like it's a pretty common bug, very easy to make by accident - I remember I had exactly the same issue with overflowing initial alpha/beta values, glad you finally found it.

[Ras]

there were some integer overflow/underflow errors.

I would have expected that Rust panics in debug mode (not in release mode). Did you try the debug mode?

[AAce3]

there were some integer overflow/underflow errors.

I would have expected that Rust panics in debug mode (not in release mode). Did you try the debug mode?

I disabled overflow checks in my cargo.toml so that I could use magic bitboards without having to use wrapping_mul etc.

[AAce3]

I haven't had the time to make any major changes to Shen Yu in the past week because of schoolwork. However, I've implemented alpha-beta, with no bugs so far. I've yet to implement UCI or a search routine, but I put a simple iterative deepening loop to test search based solely on depth. It is fast enough for me, running at roughly 5-6 Mnps, and completing depth 10 from startpos in around 5.5-6 seconds. I'm planning to experiment with staged move generation and SEE move ordering/pruning, but it is good enough for now.

I want to move to making progress on MCTS for my next step, before making any releases. My current ideas are as follows:

Monte Carlo nodes will be stored in a large array, with linked-list style structure.

Code: Select all

struct MCNode{
	prev_move: Move,
	first_child: u32, // indexes into the array of nodes
	next_sibling: u32,
	score: f16, // doesn't exist in native rust but there is a library for it
	visitcount: u32
	childcount: u8,
}

Iterating over the node's children just means continuously following "next_sibling."

Since these nodes are so small (less than 20 bytes) I think that it is feasible to, in the expansion phase, calculate out "policy" (i.e. alpha beta value from that given move) and store those in child nodes, so that way the tree search algorithm knows which ones to pick. The issue with this is that there will be a lot of useless nodes. I'm going to experiment with both retrieving 'policy' scores from transposition table and doing a re-search if it fails, (i.e. re-generating all of the moves, then playing them out) as well as just storing it in child nodes.

The other idea that I had in mind was to vary the exploration constant C based on the scores of the children. If one node seems to be very clearly better than another it isn't necessary to have exploration be as high, we are already confident that one move is better, whereas in a position with many good moves C should be higher, to explore more possibilities.

I don't expect to have time to implement either of these in the near future. Perhaps I will make Shen Yu release as an alpha-beta engine at first.

[likeawizard]

I finally fixed it. It turns out that because I was setting beta and alpha to be the max value for i16 and min value for i16 respectively at the search initialization, there were some integer overflow/underflow errors. Alpha is thus -32768 and beta is 32767, so when I negated alpha to place as beta it actually overflowed because there is no representation of 32768 in 16 bit integer, it overflows back down to -32768 (I think).

Oh I had the exact same bug in my GoLang code. I ended up setting alpha to maxInt and beta to -maxInt instead of minInt. Seems so obvious when you think about it, yet so natural to make that mistake. Took me a few hours to notice that weird there was a strange flip in the evaluations at odd/even depths.

[AAce3]

Hi everyone,
I'm almost ready to release the first version of Shen Yu. It is an alpha-beta engine as of now, with PVS, IID, TT move ordering and cutoffs, killers, MVV-LVA, and history heuristic. I've appropriated PESTO's piece square tables, but plan to tune my own once I end up adding more evaluation features. It's working with uci though.
One question though, and this is the last thing I need to do - and this is a question for all rust developers out there - I can't figure out how to cross compile my code for multiple platforms. I'm running on a windows computer, and was wondering if any of you guys might be able to help?

Thanks!

[Tearth]

One question though, and this is the last thing I need to do - and this is a question for all rust developers out there - I can't figure out how to cross compile my code for multiple platforms. I'm running on a windows computer, and was wondering if any of you guys might be able to help?

Thanks!

I'm using https://github.com/cross-rs/cross when compiling Inanis for various platforms - it's very easy and works pretty much perfectly.

[AAce3]

Hi guys,
First release of shenyu is out. It's an alpha-beta engine, no pruning, PeSTO eval. Currently plays at around 2100 based on my testing. I have not compiled binaries. Here is the github repo: https://github.com/AAce3/ShenYu.

I'm not sure how long I'll continue working on this. I've been reading a lot into NN+MCTS based engines and I kind of want to try my hand at coding one of those. Regardless, I will have very little time in the coming year to do either, because of college applications.

[Ras]

There have been weird crashes with banksia gui when undo-ing and setting up positions,

Looking at https://github.com/AAce3/ShenYu/blob/master/src/uci.rs, I can see that you expect position startpos moves ... from line 212, but for position fen ... from line 203, there is no corresponding evaluation of moves. By consequence, this will only work with GUIs that transfer the game from the starting position followed by all game moves. If a GUI instead transfers the position after the last non-reversible move plus the move list from there, that will not work:

[d]7r/3p1n2/5k2/R7/1P2B3/2P5/3K4/8 w - - 0 1

This works:

Code: Select all

position fen 7r/3p1n2/5k2/R7/1P2B3/2P5/3K4/8 w - - 0 1
go depth 2
info depth 1 score cp 159 nodes 39 nps 0 time 0 pv a5a7
info depth 2 score cp 116 nodes 113 nps 0 time 0 pv d2d3 h8h2
bestmove d2d3

This fails, the engine tries to move White's king although it's Black's turn:

Code: Select all

position fen 7r/3p1n2/5k2/R7/1P2B3/2P5/3K4/8 w - - 0 1 moves d2d3
go depth 2
info depth 1 score cp 159 nodes 39 nps 0 time 0 pv a5a7
info depth 2 score cp 116 nodes 79 nps 0 time 0 pv d2d3
bestmove d2d3

Also, the FEN parser does not always evaluate who is to move (and hence maybe not the following castling rights / ep square, either - should be verified):

[d]7r/3p1n2/5k2/R7/1P2B3/2P5/3K4/8 b - - 0 1

Code: Select all

position fen 7r/3p1n2/5k2/R7/1P2B3/2P5/3K4/8 b - - 0 1
go depth 2
info depth 1 score cp 159 nodes 41 nps 41000 time 1 pv a5a7
info depth 2 score cp 166 nodes 244 nps 244000 time 1 pv a5f5 f6e6 b4b5

[AAce3]

There have been weird crashes with banksia gui when undo-ing and setting up positions,

Looking at https://github.com/AAce3/ShenYu/blob/master/src/uci.rs, I can see that you expect position startpos moves ... from line 212, but for position fen ... from line 203, there is no corresponding evaluation of moves. By consequence, this will only work with GUIs that transfer the game from the starting position followed by all game moves. If a GUI instead transfers the position after the last non-reversible move plus the move list from there, that will not work:

[d]7r/3p1n2/5k2/R7/1P2B3/2P5/3K4/8 w - - 0 1

This works:

Code: Select all

position fen 7r/3p1n2/5k2/R7/1P2B3/2P5/3K4/8 w - - 0 1
go depth 2
info depth 1 score cp 159 nodes 39 nps 0 time 0 pv a5a7
info depth 2 score cp 116 nodes 113 nps 0 time 0 pv d2d3 h8h2
bestmove d2d3

This fails, the engine tries to move White's king although it's Black's turn:

Code: Select all

position fen 7r/3p1n2/5k2/R7/1P2B3/2P5/3K4/8 w - - 0 1 moves d2d3
go depth 2
info depth 1 score cp 159 nodes 39 nps 0 time 0 pv a5a7
info depth 2 score cp 116 nodes 79 nps 0 time 0 pv d2d3
bestmove d2d3

Also, the FEN parser does not always evaluate who is to move (and hence maybe not the following castling rights / ep square, either - should be verified):

[d]7r/3p1n2/5k2/R7/1P2B3/2P5/3K4/8 b - - 0 1

Code: Select all

position fen 7r/3p1n2/5k2/R7/1P2B3/2P5/3K4/8 b - - 0 1
go depth 2
info depth 1 score cp 159 nodes 41 nps 41000 time 1 pv a5a7
info depth 2 score cp 166 nodes 244 nps 244000 time 1 pv a5f5 f6e6 b4b5

Thanks! I'll put out a patch today.