Mini Rodent asks for code review

[PK]

https://github.com/nescitus/Rodent_II

I decided to share a developement snapshot of something that will eventually become Rodent 2.0. The code I am linking to is pretty basic, and intentionally so. First of all, it may serve as a starting point of somebody else's work, just as Sungorus 1.4 by Pablo Vazquez has been my starting point. Secondly, I have already discarded two attempts at adding new features too fast, and that convinced me about the merits of establishing a solid base.

- strength is likely to exceed 2500 CCRL
- known bugs of Sungorus 1.4 are dealt with (problem with time losses, lack of a draw by 50 moves rule, castling code causing spurious MSVC range warning)
- in the process, Timer class has been created
- functions for making and unmaking moves are now part of POS (board) class
- late move reductions and late move pruning are added. the former can be easily improved, but I decided leave it for the later version.
- hashing algorithm differentiates between pv and non-pv nodes
- history table is incremented by depth * depth and there is a piece of code keeping the score within reasonable limits
- two null moves in a row are now explicitly forbidden
- there is a basic eval featuring midgame/endgame scaling, piece/square tables (basically form Toga Log User Manual), mobility, king safety, passed, backward and isolated pawns, king's pawn shield and pawn storms.

I don't want this mini engine to enter the rating lists. however, I would be very grateful for code reviews and suggestions of changes, especially those improving readability.

[jdart]

Couple of comments:

1. Try to avoid goto in the search module.

2. Unless I missed something it does not seem you have implemented futility pruning in the quiescence search (i.e. pruning moves that cannot generate a score > alpha).

--Jon

[PK]

ad 1: OK, this will be done

ad 2: Mini Rodent inherits some things from Sungorus. One of them is slightly bizzare implementation of delta/futility pruning in quiescence search: it is done on the move generator level via BadCapture() function, which is a wrapper for SEE (not called on low x high). It is a bit confusing, so I'll change that.

[jdart]

As far as I can tell, BadCapture does not compare against alpha. It only tests for non-gaining captures. You can have a capture that gains a pawn, but if you are 3 pawns below alpha that will not help.

--Jon

[Dann Corbit]

That code is C++ and not C.
I would rename the code to have an extension of:
.cpp
OR
.cc
OR
.C {note capitalized}

[velmarin]

Thanks, all these initiatives seem to magnificent. ´

How amateur and apprentice find it lacking in "comments or learning", too many formulas that do not help the learning "without more explanation".

How a new writing of code (little innovative) that does not start with magic bitboards, not seems difficult to do so. Rodent could be "much Rodent".Very thanks !!.

[Ferdy]

(1) Perhaps it is better to separate piece_values from pst's, in the spirit of readability and future eval parameter value auto-tuning.

(2) Might add an assert as well, to make sure history has good data.

Code: Select all

assert(p->pc[Fsq(move)] != NO_PC);  // To detect no_pc
assert&#40;p->pc&#91;Fsq&#40;move&#41;&#93; <= NO_PC&#41;;  // To detect beyond no_pc for deeper examination
history&#91;p->pc&#91;Fsq&#40;move&#41;&#93;&#93;&#91;Tsq&#40;move&#41;&#93; += depth * depth;

Considering history is,
int history[12][64];
and NO_PC is 12.

(3) From eval too.

Code: Select all

if (sd == WC) bbZone |= ShiftSouth(bbZone);
if (sd == BC) bbZone |= ShiftNorth(bbZone);

Suggestion.

Code: Select all

assert(sd == WC || sd == BC);
if (sd == WC) bbZone |= ShiftSouth(bbZone);
else bbZone |= ShiftNorth(bbZone);

(4)

Code: Select all

printf("info depth %d time %d nodes %d nps %d\n", root_depth, elapsed, nodes, nps);

For U64 nodes and nps, you might use %I64d.

(5) Perhaps in the eval create multiple pair of score.
From,

Code: Select all

int mg[2];
int eg[2];

To something like.

Code: Select all

mg_pst[2];
eg_pst[2];

mg_pvalue[2];
eg_pvalue[2];

mg_pos[2];
eg_pos[2];

mg_mobility[2];
eg_mobility[2];
and others

So that later eval can be easily isolated for debugging perhaps.

[PK]

Thank You for all Your suggestions!

Within evaluation function I will probably prefer using a table like

Code: Select all

eval_factors[side][phase][factor]

and extending Add() function to

Code: Select all

void Add(int sd, int factor, int mg, int eg)

Asserts will be added ant checked after the completion of today's testing run.

[Ferdy]

Thank You for all Your suggestions!

Within evaluation function I will probably prefer using a table like

Code: Select all

eval_factors[side][phase][factor]

and extending Add() function to

Code: Select all

void Add(int sd, int factor, int mg, int eg)

Asserts will be added ant checked after the completion of today's testing run.

Regarding tables, I limit it to 2d, I try to avoid tables beyond that size.

[PK]

it seems that I reached my goal a bit earlier than expected and this 2400 lines of code can already hold its own against good old Fruit 2.1. so here comes Mini Rodent 0.2, still not ready for the rating lists, but probably 2650+ Elo on CCRL scale:

https://github.com/nescitus/Rodent_II

the code might have been even shorter, were it not for debugging infrastructure. however, in the next 100 lines You will see more of it - perft, detailed evaluation output and some console mode enhancements are missing.