HOME
Latest news
DOWNLOADS
Downloads for all Rival flavours
CHANGE LOG
Recent changes to the engine and the GUI
MAGICS
A random piece on magic bitboards
ABOUT
About the authors and history of Rival chess
CONTACT
Give us some feedback

Change Log

Rival Android Change Log

Version 1.1.1

March 10th 2011
* 3 new sets added, default changed.
* Multiple board designs added.
* Email PGN during or after your game.
* Board highlights changed.
* Improved navigation for reviewing game history.
* Improved menu interface.
* Play move piece sound only on successful move.
* Reported temporary promotion rendering glitch fixed.

Version 1.01

February 11th 2011
Improved history view with material balance indicator
Some UI stability issues resolved
Minor engine tweaks

Version 1.0

February 8th 2011
Initial release

Engine Change Log

The change log for the engine which is pretty raw stuff and is likely only to be of interest chess programmers and those interested in the inner workings of a chess engine. And to be honest, I can imagine many of them being interested.

Don’t worry if you don’t understand this – it’s not important. I create new builds of the engine on a whim to test minor tweaks or to see if certain search or evaluation elements do or don’t work very well, so this isn’t a coherent list of improvements from 0001 upwards, it’s more like a scrap book of test results and tinkering as I try to improve the engine’s strength.

=======================
0094
=======================
Corrected hash table storage after quiescence - all scores were being marked as "exact" even if outside the alpha/beta window.

=======================
0093
=======================
Was only checking for 32 bits of hash key (matched if either the top or bottom 32 bits matched). Doesn't appear that this makes any difference at all - on tests can't find
a situation where the || matches and the && fails.
Hash probe cut off changed from low > high to low >= high

=======================
0092
=======================
public static final int GENERATE_CHECKS_UNTIL_QUIESCE_PLY = 0;
public static final boolean USE_DELTA_PRUNING = true;

=======================
0091
=======================
Recapture extension turned off
NUM_LMR_FINDS_BEFORE_EXTRA_REDUCTION set back to -1
Checks in quiescence reduced to 2 plies
Delta pruning turned off

=======================
0090
=======================
isPassedPawnPush() was very buggy - moved to EngineChessBoard and fixed
FUTILITY_MARGIN_BASE = VALUE_PAWN * 2;
Delta pruning in quiesce
Research LMR on > low rather than >= high
Simplified node counting so it's just done at the start of search() and the start of quiesce()


Correct = 299 / 299
Within 1s = 283
Within 2s = 291
Within 3s = 294
Within 4s = 294
Within 5s = 296
Within 6s = 297
Within 7s = 298
Within 8s = 298
Within 9s = 299

=======================
0089
=======================
Corrected problems with checks in quiesce()
Move isCheck call outside of move loop so check extends are now on the entry position rather than the move
Recapture extensions and threat extensions turned off

Within 1s = 286
Within 2s = 291
Within 3s = 293
Within 4s = 295
Within 5s = 297
Within 6s = 298
Within 7s = 299

=======================
0088
=======================
public static final int LMR_LEGALMOVES_BEFORE_ATTEMPT = 3;
public static final int NUM_LMR_FINDS_BEFORE_EXTRA_REDUCTION = 3;

public static final int GENERATE_CHECKS_UNTIL_QUIESCE_PLY = 3;

public static final int FRACTIONAL_EXTENSION_FULL = 8;
public static final int FRACTIONAL_EXTENSION_THREAT = 0;
public static final int FRACTIONAL_EXTENSION_CHECK = 8;
public static final int FRACTIONAL_EXTENSION_RECAPTURE = 4;
public static final int FRACTIONAL_EXTENSION_PAWN = 2;
public static final int RECAPTURE_EXTENSION_MARGIN = 50;

Corrected bug in Quiesce move generation where only pawn moves that were promotions were getting added
Change piece scores

Within 1s = 284
Within 2s = 3
Within 3s = 6
Within 4s = 1
Within 5s = 1
Within 6s = 0
Within 7s = 0
Within 8s = 0
Within 9s = 1
Within 10s = 1
Within 11s = 0
Within 12s = 0
Within 13s = 1
Within 14s = 0
Within 15s = 0
Within 16s = 0

=======================
0087
=======================
Piece values 375/575/1150
FUTILITY_MARGIN_BASE = VALUE_PAWN * 2;
Fixed a flaw in the material balance term of when LMR is allowable

public static final int GENERATE_CHECKS_UNTIL_QUIESCE_PLY = 3;

public static final int LMR_LEGALMOVES_BEFORE_ATTEMPT = 4;
public static final int NUM_LMR_FINDS_BEFORE_EXTRA_REDUCTION = -1;

Add new quiesce move generator to generate just captures and most checks (discovered checks not yet included) - this was to allow checks to be generated in the quiesce search
without having to examine the move to see whether it is a check which is too slow
public static final int FRACTIONAL_EXTENSION_FULL = 8;
public static final int FRACTIONAL_EXTENSION_THREAT = 4;
public static final int FRACTIONAL_EXTENSION_CHECK = 6;
public static final int FRACTIONAL_EXTENSION_RECAPTURE = 4;
public static final int FRACTIONAL_EXTENSION_PAWN = 4;

public static final int LAST_EXTENSION_LAYER = 4;

public static final int[] MAX_NEW_EXTENSIONS_TREE_PART =
{FRACTIONAL_EXTENSION_FULL, FRACTIONAL_EXTENSION_FULL / 4 * 3, FRACTIONAL_EXTENSION_FULL / 2, FRACTIONAL_EXTENSION_FULL / 2, 0};

=======================
0086
=======================
FUTILITY_MARGIN_BASE = VALUE_PAWN * 3;
FUTILITY_MARGIN = {FUTILITY_MARGIN_BASE, FUTILITY_MARGIN_BASE * 2, FUTILITY_MARGIN_BASE * 3};

Switch KPK bitbase on
Recapture extensions finally working correctly (well, my imagining of correct in any case)
Speed up in move ordering code
Reintroduced pawn push extensions and found bug in old code that failed to recognise black passed pawn pushes
Used passed pawn push code to stop LMR and futility pruning when a pawn push is being made
With the passed pawn security against dodgy reductions and pruning, reintroduced the code that causes the LMR reduction to be 2 plies rather than 1 after 4 LMRs have been performed already at that node - UPDATE: this created a significant number of unexpected problems in the WAC test so I have taken it out again

Perft test = (426983825/58731)*1000 = 7,270,160 nps

Total Session Time = 302.51
Nodes Per Second = 644,000
FAILED: WAC.100 b6+ 8/k1b5/P4p2/1Pp2p1p/K1P2P1P/8/3B4/8 w - -
FAILED: WAC.163 Qg2+ 5rk1/2p4p/2p4r/3P4/4p1b1/1Q2NqPp/PP3P1K/R4R2 b - -
Correct = 297 / 299
Within 1s = 279
Within 2s = 9
Within 3s = 1
Within 4s = 3
Within 5s = 0
Within 6s = 1
Within 7s = 0
Within 8s = 0
Within 9s = 0
Within 10s = 0
Within 11s = 0
Within 12s = 4

WAC.001: Rival says: Qg6 Wanted Qg6 Correct 1/1 in 0.52 NPS: 65,613
WAC.002: Rival says: Rxb2 Wanted Rxb2 Correct 2/2 in 11.75 NPS: 918,091
WAC.003: Rival says: Rg3 Wanted Rg3 Correct 3/3 in 11.75 NPS: 218,429
WAC.004: Rival says: Qxh7+ Wanted Qxh7+ Correct 4/4 in 11.76 NPS: 153,333
WAC.005: Rival says: Qc4+ Wanted Qc4+ Correct 5/5 in 11.76 NPS: 46,000

etc...

WAC.294: Rival says: Nf5 Wanted Bf8 Nf5 Qf4 Correct 291/293 in 115.11 NPS: 442,250
WAC.295: Rival says: Rxd5+ Wanted Rxd5+ Correct 292/294 in 115.12 NPS: 577,714
WAC.296: Rival says: Rf8 Wanted Rd4+ Rf8 Correct 293/295 in 115.24 NPS: 530,155
WAC.297: Rival says: Bxg2 Wanted Bxg2 Bxh2+ Correct 294/296 in 127.02 NPS: 581,196
WAC.298: Rival says: Qh8+ Wanted Qh8+ Correct 295/297 in 127.03 NPS: 278,417
WAC.299: Rival says: Nca4 Wanted Nca4 Correct 296/298 in 127.22 NPS: 588,827
WAC.300: Rival says: g6 Wanted g6 Correct 297/299 in 127.22 NPS: 350,600

=======================
0085
=======================
Return SearchPath from quiesce() rather than just score
KINGSAFETY_RIGHTWAY_DIVISOR = 4 - seeings as 0081 is currently the strongest version of the engine, I've reduced this back to where it was then.
Require depthRemaining > nullMoveReduceDepth before doing null move
Changed the way moves are selected for ordering - now in three phases, (1) hash move, (2) captures and promotions, (3) the rest - all moves still generated up front, but scores are only
applied after the search has tried all the moves in the previous phase
Internal EPD test harness created - usage

epd "filename" ContinuousPlies MaxMillisPerPosition
epd "S:\\Java\\Chess Supp\\EPD\\wacno230.epd" 3 30000

Double quotes are required around the file name

WAC 297/299 2:47m (15s max) n/s: 913.635


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
-------------------------------------------------------------------------------------
0 | 0 12 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
20 | 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
40 | 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0
60 | 0 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0
80 | 0 0 0 0 0 0 0 0 0 0 0 6 0 0 0 0 0 0 0 -
100 | 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
120 | 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
140 | 1 0 0 0 1 0 0 0 0 0 0 13 0 0 0 0 1 0 0 0
160 | 0 0 - 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0
180 | 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 1
200 | 0 0 0 0 0 0 0 0 0 0 0 0 5 0 0 0 0 0 0 0
220 | 0 0 0 0 0 0 0 1 10 0 0 0 0 0 0 3 0 0 0 3
240 | 0 0 0 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0
260 | 0 0 0 2 0 0 0 11 0 0 0 0 0 0 0 0 0 0 2 0
280 | 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 9 0 2 0

1 sec -> 273/299
2 sec -> 283/299
3 sec -> 287/299
4 sec -> 289/299
5 sec -> 289/299
6 sec -> 290/299
7 sec -> 291/299
8 sec -> 291/299
9 sec -> 291/299
10 sec -> 292/299
11 sec -> 294/299
12 sec -> 295/299
13 sec -> 296/299
14 sec -> 297/299
15 sec -> 297/299
n/s: 689.068
TotTime: 10:15m SolTime: 2:47m

=======================
0084
=======================
Reinstated Isolated D-Pawn Penalty
Narrowed slightly - FUTILITY_MARGIN = {VALUE_KNIGHT, VALUE_KNIGHT + (VALUE_KNIGHT / 2), VALUE_ROOK + VALUE_KNIGHT}
Only null move if depth remaining > 1
Slight change to quiesce() to use SEE result for sorting rather than just LVA/MVV
FRACTIONAL_EXTENSION_CHECK = 8
FRACTIONAL_EXTENSION_RECAPTURE = 8
IID_REDUCE_DEPTH = 3
IID_MIN_DEPTH = 5
KINGSAFETY_RIGHTWAY_DIVISOR = 5
Reinstated Position (H) penalty in RightWay scoring, this penalty gets outweighed by the pawn shield bonus for the pawn on h3
Force search of all moves if inCheck in quiesce() - quiesce won't be entered if in check, but a quiesce move may cause a check
WAC 296/300 3:04m (15s max) n/s: 790.372


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
-------------------------------------------------------------------------------------
0 | 0 9 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
20 | 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
40 | 0 0 0 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0
60 | 0 0 0 0 0 0 0 0 0 0 8 0 0 0 0 0 0 0 0 1
80 | 0 0 0 0 0 0 0 0 0 0 0 5 0 0 0 0 0 0 0 -
100 | 0 0 0 0 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
120 | 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
140 | 1 0 0 0 1 0 0 0 0 0 0 10 0 0 0 0 1 0 0 0
160 | 0 0 - 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0
180 | 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 1
200 | 0 0 0 0 0 0 0 0 0 0 0 0 4 0 0 0 0 0 0 0
220 | 0 0 0 0 0 0 0 1 6 - 0 0 0 0 - 0 6 0 0 0
240 | 2 0 1 0 0 0 3 0 0 0 0 0 0 0 0 0 0 0 0 0
260 | 0 0 0 0 1 0 0 0 11 0 0 0 0 0 1 0 0 0 0 0
280 | 0 0 0 0 0 0 3 0 0 0 0 0 1 0 0 0 3 0 0 0

1 sec -> 270/300
2 sec -> 282/300
3 sec -> 284/300
4 sec -> 288/300
5 sec -> 289/300
6 sec -> 290/300
7 sec -> 292/300
8 sec -> 292/300
9 sec -> 293/300
10 sec -> 294/300
11 sec -> 295/300
12 sec -> 296/300
13 sec -> 296/300
14 sec -> 296/300
15 sec -> 296/300
n/s: 790.372
TotTime: 10:51m SolTime: 3:04m

=======================
0083
=======================
FRACTIONAL_EXTENSION_RECAPTURE = 0 (accident)
Increased margins used for razoring and futility pruning
Removed penalty scores from Right Way scoring so that it doesn't try to avoid the penalty by seeking out an even worse position
Increased Right Way divisor to 6
WAC 295/300 3:36m (15s max) n/s: 913.635


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
-------------------------------------------------------------------------------------
0 | 0 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
20 | 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
40 | 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
60 | 0 0 0 0 0 0 0 0 0 0 2 0 0 0 0 0 0 0 0 0
80 | 0 0 0 0 0 0 0 0 0 0 1 11 0 0 0 0 0 0 0 -
100 | 0 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0
120 | 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
140 | 7 0 0 0 1 0 0 0 0 0 0 5 0 0 0 0 1 0 0 0
160 | 0 0 - 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
180 | 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 0 0 0 1
200 | 0 0 0 0 0 0 0 0 0 0 0 0 5 0 0 0 0 0 0 0
220 | 4 0 0 0 0 0 0 1 - - 0 0 0 0 - 0 5 0 0 0
240 | 1 0 1 0 0 0 0 0 0 2 0 0 0 0 0 9 0 0 0 0
260 | 0 0 0 1 0 0 0 0 13 0 0 0 0 0 0 0 0 0 0 0
280 | 0 0 0 0 0 0 0 0 0 0 0 0 9 0 0 0 8 0 0 0

1 sec -> 272/300
2 sec -> 280/300
3 sec -> 283/300
4 sec -> 284/300
5 sec -> 285/300
6 sec -> 288/300
7 sec -> 288/300
8 sec -> 289/300
9 sec -> 290/300
10 sec -> 292/300
11 sec -> 293/300
12 sec -> 294/300
13 sec -> 294/300
14 sec -> 295/300
15 sec -> 295/300
n/s: 913.635
TotTime: 11:29m SolTime: 3:36m

=======================
0082 - 2011/02/25
=======================
Some optimisation for speed

=======================
0081
=======================
Added squareContents[64] - updated in makemove/unmakemove, makes getPieceType much quicker and speeds up makemove/unmakemove themselves
WAC 294/300 3:37m (15s max)

=======================
0080
=======================
Set isOnNullMove to false in makemove otherwise only one null move is allowed in the whole search branch

=======================
0079
=======================
Identical I think, but this is the version I sent to Russ for 1.04 Android release and IS_ANDROID_VERSION = true, so doesn't use KPK bitbase

=======================
0078
=======================
FRACTIONAL_EXTENSION_RECAPTURE = 16

=======================
0077
=======================
Overhaul of unmakemove - removed all backup arrays and now use logic to undo the move. This seems to be a lot faster and paves the way for some more speed-ups.

=======================
0076
=======================
Put strict recaptures back in following positive tournament results but left FRACTIONAL_EXTENSION_RECAPTURE = 8

=======================
0075
=======================
Slackened recaptures and reduced to FRACTIONAL_EXTENSION_RECAPTURE = 8

=======================
0074
=======================
Strict recaptures using static evaluation to estimate if the recapture is a sensible move worth extending

=======================
0073
=======================
IS_ANDROID_VERSION = false
Recapture extensions reintroduced for first time in ages. Just mucking about to begin with, with FRACTIONAL_EXTENSION_RECAPTURE = 16

=======================
0072
=======================
Reduced king attack unit from 5 to 4 - no real reason.
Internal opening library now considers move frequency when selecting a move
Piece values changed to 350/550/1100
Experiment with LMR_LEGALMOVES_BEFORE_ATTEMPT = 4
IS_ANDROID_VERSION = true still, whoops

=======================
0071
=======================
Removed KQKP evaluation

=======================
0070
=======================
Increased king attack unit from 3 to 5

=======================
0069
=======================
Tinkered with piece square tables
Created KPK bitbase
Moved MoveRef and MoveState to the model.board package in order to make a smaller jar
Change piece values 325/500/1000

=======================
0068
=======================
Experiment with futility pruning

1: Rival-0068 332.5/525
2: Rival-0066 304.5/525
3: Rival-0067 295.0/525
4: Clueless 118.0/525

-----------------Clueless-----------------
Clueless - Rival-0066 : 40.5/175 33-127-15
Clueless - Rival-0067 : 41.0/175 30-123-22
Clueless - Rival-0068 : 36.5/175 28-130-17
-----------------Rival-0066-----------------
Rival-0066 - Clueless : 134.5/175 127-33-15
Rival-0066 - Rival-0067 : 86.5/175 62-64-49
Rival-0066 - Rival-0068 : 83.5/175 58-66-51
-----------------Rival-0067-----------------
Rival-0067 - Clueless : 134.0/175 123-30-22
Rival-0067 - Rival-0066 : 88.5/175 64-62-49
Rival-0067 - Rival-0068 : 72.5/175 47-77-51
-----------------Rival-0068-----------------
Rival-0068 - Clueless : 138.5/175 130-28-17
Rival-0068 - Rival-0066 : 91.5/175 66-58-51
Rival-0068 - Rival-0067 : 102.5/175 77-47-51

=======================
0067
=======================
A few minor tweaks for speed
Added knight outpost penalties for landing posts attacked by enemy pawns or occupied by friendly pawns
Mixed in the Right Way scores to the current king safety evaluation

=======================
0066
=======================
01: Ruffian 1.0.5 273.0/300
02: Cuckoo108 257.5/300
03: Nejmet 3.07 229.5/300
04: Dragon 4.6 202.0/300
05: Rival-0066 161.5/300
06: Rival-0065 143.5/300
07: Rival-0064 143.0/300
08: Rival-0055 124.5/300
09: Rival-0057 123.5/300
10: Rival-0056 122.5/300
11: Rival-0058 120.0/300
12: Rival-0063 118.0/300
13: Rival-0060 113.0/300
14: Rival-0062 104.5/300
15: Rival-0061 101.5/300
16: RivalUCI-1.18 62.5/300

Fixed a couple of bugs in SEE - pawn promotion and capturing kings.
Move ordering change to incorporate new SEE function. All bad captures are penalised at the end of scoring depending on the badness of the capture.
WAC 290/300 4:53m (15s max)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
-------------------------------------------------------------------------------------
0 | 0 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
20 | 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
40 | 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0
60 | 0 0 0 0 0 0 0 0 0 0 8 0 0 0 0 0 0 0 0 1
80 | 0 0 0 0 0 0 0 0 0 0 1 13 0 0 0 0 0 0 0 -
100 | 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
120 | 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0
140 | - 0 0 0 4 0 0 0 0 0 0 - 0 0 2 0 8 0 0 0
160 | 0 0 - 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
180 | 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 0 0 0 2
200 | 0 0 0 0 0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0
220 | 0 0 0 0 0 0 0 1 5 - 0 0 0 0 7 0 3 0 0 0
240 | 2 0 3 0 0 0 0 0 0 1 0 0 0 0 0 - 0 0 0 0
260 | 0 0 0 1 2 0 0 0 10 0 0 0 0 0 0 0 0 0 - 0
280 | 0 0 1 0 0 0 8 0 0 0 1 0 - 0 0 0 - 0 0 0

1 sec -> 263/300
2 sec -> 275/300
3 sec -> 279/300
4 sec -> 281/300
5 sec -> 282/300
6 sec -> 283/300
7 sec -> 283/300
8 sec -> 284/300
9 sec -> 288/300
10 sec -> 288/300
11 sec -> 289/300
12 sec -> 289/300
13 sec -> 289/300
14 sec -> 290/300
15 sec -> 290/300
n/s: 585.247
TotTime: 16:00m SolTime: 4:53m
Ply: 0 Positions:148 Avg Nodes: 0 Branching = 0.00
Ply: 2 Positions: 1 Avg Nodes: 289 Branching = 0.00
Ply: 3 Positions: 4 Avg Nodes: 1467 Branching = 5.08
Ply: 4 Positions: 21 Avg Nodes: 5492 Branching = 3.74
Ply: 5 Positions: 47 Avg Nodes: 13884 Branching = 2.53
Ply: 6 Positions: 46 Avg Nodes: 42592 Branching = 3.07
Ply: 7 Positions: 50 Avg Nodes: 94509 Branching = 2.22
Ply: 8 Positions: 31 Avg Nodes: 228968 Branching = 2.42
Ply: 9 Positions: 26 Avg Nodes: 600382 Branching = 2.62
Ply:10 Positions: 15 Avg Nodes: 1738421 Branching = 2.90
Ply:11 Positions: 10 Avg Nodes: 1063028 Branching = 0.61
Ply:12 Positions: 7 Avg Nodes: 2593061 Branching = 2.44
Ply:13 Positions: 4 Avg Nodes: 912728 Branching = 0.35
Ply:14 Positions: 3 Avg Nodes: 2148855 Branching = 2.35
Ply:15 Positions: 2 Avg Nodes: 3339373 Branching = 1.55
Ply:16 Positions: 2 Avg Nodes: 6888655 Branching = 2.06
Ply:17 Positions: 1 Avg Nodes: 1724237 Branching = 0.25
Ply:18 Positions: 1 Avg Nodes: 4336790 Branching = 2.52
Ply:19 Positions: 1 Avg Nodes: 8756941 Branching = 2.02

=======================
0065
=======================
Introduced SEE and restricted Quiescence search to consider only winning captures
Piece values returned to bigger values

=======================
0064
=======================
Bug in order moves where capturePiece was not being set to -1 after each move, and where capture piece was always assigned as a pawn for a pawn capture
Capture piece now added at move generation time and extracted within orderMoves
Fixed "var" command which was only allowing integer values to be displayed

=======================
0063
=======================
NUM_LMR_FINDS_BEFORE_EXTRA_REDUCTION = -1. This should've been in 0062 but it was accidentally left as four.

=======================
0062
=======================
Adaptive null move reduce depth. If depth remaining > 6 then 3 otherwise 2
CanMakeNullMove now includes a check that at least one pawn is on the board for the moving side
Distant threat extensions were incorrectly being extended one ply, now they extend half a ply with only immediate threat extensions extended a full ply
Modified piece values to 350/350/550/1100
Added FENFlip verification of evaluation function when running internal test suites - it inverts the fen and ensures that the evaluation function returns the same
score when viewed from the other side's perspective
As a result of the above, changed castling bonus to make sure that black and white are always evaluated the same - previously was just using black material to determine how important castling was
Removed knight tropism scores
Reduced rook on same file scores
Storing movePiece in the move int at point of creation for easy access within orderMoves, at which point it gets overwritten with the score

=======================
0061
=======================
NUM_LMR_FINDS_BEFORE_EXTRA_REDUCTION = 4
Modified "vars" command - now "var" can use as follows to get the value of any member of RivalConstants

var LMR_LEGALMOVES_BEFORE_ATTEMPT

results in...

Class: com.netadapt.rivalchess.engine.core.RivalConstants
LMR_LEGALMOVES_BEFORE_ATTEMPT = 7

=======================
0060
=======================
NUM_LMR_FINDS_BEFORE_EXTRA_REDUCTION = -1

=======================
0059
=======================
Probe hash table before quiesce, store quiesce score at depth 0 in hash table
A few very minor speed optimisations to evaluate(). Every little helps.

=======================
0058
=======================
Speed up to canMakeNullMove calculation using new material balance variables
Moved an isCheck call for the current position out of the move loop which was crazy, but no speed up!
Put back knight tropism and rooks on same file terms
Allow LMR to reduce by an extra ply after the three LMR reductions at the same node
This version included the N/B v pawn endgame adjustments to ensure that the N/B side always has a negative score to encourage a draw
Not certain that the above first appeared in 0058 or whether it was introduced in 0057

=======================
0057
=======================
Changed the way the height is stored in the hash table - calculate remaining depth at stop of search() and use that value for the probe and the store
WAC 283/300 7:14m

=======================
0056
=======================
Upgraded to new eval code
WAC 283/300 7:42m

=======================
0055
=======================
Hoho - looks like the bishop bonuses weren't even being included in the eval
Removed straggling eval code

=======================
0054
=======================
Enhanced end game evaluation - all evaluation terms now fully updated as planned

=======================
0053
=======================
Put back in kingpawn ending and loneking evals from old code

=======================
0052
=======================
Removed old eval terms:
Queen Tropism
Queen out early
Old King Safefy + Right Way Positions
Undeveloped minors
I think this was the version I removed the old ending code as well

=======================
0051
=======================
King safety

=======================
0050
=======================
Threat bonus

=======================
0049
=======================
Rooks
Bishops
Piece square errors sorted

=======================
0048
=======================
Android = TRUE was switched on, D'oh!
New castling code

=======================
0047
=======================
Pawn scoring overhauled
1: Cuckoo107 233.0/240
2: Rival-0047 102.5/240
3: RivalUCI-1.18 101.5/240
4: Rival-0043 83.0/240
5: Clueless 80.0/240


=======================
0046
=======================
Piece values changed
Trade bonus updated
Piece square values tweaked again
Rival-0046 - Clueless : 302.5/500 271-166-63

=======================
0045
=======================
Overhall of piece/square tables
Introduced sliding values towards the end game - new linearScale function allows all evaluation terms to be weighted depending on pieces and pawns on board
Fixed a bug in bishop mobility scoring for black

=======================
0043
=======================
Toned down king safety scores and various other evaluation terms
Removed pawn-support term - I think this did more harm than good
Rival-0043 - Clueless : 167.5/300 141-106-53
WAC 284/300 7:15m

=======================
0042, February 8th 2011
=======================
Turned off heavy king attack code for comparison - early indications are that it harms the engine even more than just slowing the existing code down 20%!

-----------------Rival-0042-----------------
Rival-0042 - Clueless : 181.5/300 161-98-41

Name of the tournament: Arena 3.0 - W7-73
Site/ Country: PC-W7-1, United Kingdom
Level: 1 Second
Hardware: Intel(R) Core(TM) i7 CPU 860 @ 2.80GHz with 4.0 GB Memory
Operating system: Windows 7 Professional Professional (Build 7600) 64 bit

=======================
0041, February 7th 2011
=======================
Added "perft" command to display results of the perft test and to allow me to compare the speed on different machines and JREs very easily.
Switched simple internal opening book on. The opening book is created from the games played on RedHotPawn.com
Fresh on the back of discovering Long.numberOfTrailingZeros, I realise there is a Long.bitCount - I could've sworn I scoured the Java APIs from top to bottom and failed to find these darn functions
when I started this. I thought I had the fastest way of doing it with "for (; x != 0; count ++) x &= x - 1;" - but no, I was wrong by almost a factor of around 20 (on my JRE.) I am certainly assuming here that
my 64-bit JRE is making use of some hardware instructions when using Long.bitCount(). Now, if anyone would like to tell me that Java has built in functions for generation magic move databases, I'll
just go and sit quietly in the corner.
Added the trade bonus code to the evaluation function
Reduced bonus given to connected passed pawns
Added rook bonus for open files and half-open files (previously only half-open files were being considered)
Removed some redunant code in battery attack calculation
Turned the heavy king attack/defence code back on which reduces search times by around 20% - so this could be a short-lived reprieve for this code if I can demonstrate that it is not worth the speed loss

=======================
0040, February 6th 2011
=======================
Merged black and white pawn hash values as I was never using them separately
Some optimisations to make/unmake move - for example, I was still storing the side to move as part of the board history so that it could be accessed
in the same way as other historical board state variables for easy unmakes. This was originally for neatness, but was still lingering in the code -
now we just flip the side of course on unmakemove. Also the way castling privileges were being stored was very inefficient.
Removed ALLWHITE and ALLBLACK bitboards - these were never used - only ever used FRIENDLY and ENEMY bitboards
After all this time, there was a bug lurking in the move generation code - when a castle is available on both the king and the queen side,
only the kingside castle was being generated due to an unfortunate "else" - even after verifying that all was well with the perft test I used
another position from http://chessprogramming.wikispaces.com/Perft+Results and found the error
Bug in the scoreRightWayPositions (my hacky King safety evaluation) - when evaluating the black position, a check for a rook on h8 was accessing
the wrong bitboard, which, as it happens, meant that it assumed there was never a rook on h8.
Speed up after realising that Long.numberOfTrailingZeroes is around 25% faster than my previous getFirstBit code..

Instead of grabbing the first bit into "sq" and clearing it in the bitboard like this...
while (bitboard != 0)
{
bitboard ^= (1L << (sq = Bitboards.index64[(int)(((bitboard & -bitboard) * 0x07EDD5E59A4E28C2L) >>> 58)])); // index64[] is hard-coded
// we know that square "sq" was set in "bitboard" and has now been cleared
}

It is faster to do it like this...
while (bitboard != 0)
{
bitboard ^= (1L << (sq = Long.numberOfTrailingZeros(bitboard)));
}

Which, in my tests, is faster than...
while (bitboard != 0)
{
sq = Long.numberOfTrailingZeros(bitboard);
bitboard &= bitboard-1;
}

It's not that suprising, but I didn't realise there was such a Java method. I'm not an expert on these things but it's possible that my JRE
is making use of processor instructions that will not always be available, but if not, it's clear that it is highly optimised and
the code is neater in any case.

Perft test results...
Perft Value for 8/2p5/3p4/KP5r/1R3p1k/8/4P1P1/8 w - - at depth 7 = 178633661
Perft Value for rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1 at depth 5 = 4865609
Perft Value for 8/3K4/2p5/p2b2r1/5k2/8/8/1q6 b - 1 67 at depth 2 = 279
Perft Value for rnbqkb1r/ppppp1pp/7n/4Pp2/8/8/PPPP1PPP/RNBQKBNR w KQkq f6 0 3 at depth 5 = 11139762
Perft Value for 8/7p/p5pb/4k3/P1pPn3/8/P5PP/1rB2RK1 b - d3 0 28 at depth 6 = 38633283
Perft Value for r3k2r/p1ppqpb1/bn2pnp1/3PN3/1p2P3/2N2Q1p/PPPBBPPP/R3K2R w KQkq - at depth 5 = 193690690

(426963284/73184)*1000 = 5,834,106 nps (before numberOfTrailingZeros change)
(426963284/62921)*1000 = 6,785,704 nps (after the change)

1: Rival-0040 62.5/100
2: Clueless 37.5/100

100 games played / Tournament is finished
Name of the tournament: Arena 3.0 - W7-70
Site/ Country: PC-W7-1, United Kingdom
Level: 1 Second
Hardware: Intel(R) Core(TM) i7 CPU 860 @ 2.80GHz with 4.0 GB Memory
Operating system: Windows 7 Professional Professional (Build 7600) 64 bit
PGN-File: C:\Program Files (x86)\Arena\Tournaments\Arena 3.0 - W7-70.pgn

=======================
0039, February 6th 2011
=======================
Adding LMR back in appears to have weakened the engine somewhat, although the tournament result against Clueless is not conclusive.
Have modified LMR to require a certain number of legal moves (7, just a guess) before a reduction can be considered.
Added a perft tester to the test class to satisfy myself that all was well with move generation, but more importantly because I switch between loop
generation and magic bitboard generation (for handheld devices I prefer loops to save memory) and don't want nasty suprises lurking when I've been
testing with one method and then switch to the other without the same level of testing.
The standalone UCI code was being compiled with loop move generation - have switched back to magic bitboards for the jar version.
Added a "vars" option which will cause the engine to display a list of internal variables which would have been useful to find out in which version
I introduced the problem above.

------------------------------------------------------------------------------
Name of the tournament: Arena 3.0 - W7-68
Site/ Country: PC-W7-1, United Kingdom
Level: 1 Second
Hardware: Intel(R) Core(TM) i7 CPU 860 @ 2.80GHz with 4.0 GB Memory
Operating system: Windows 7 Professional Professional (Build 7600) 64 bit
Rival-0039 - Clueless : 170.0/300 147-107-46
------------------------------------------------------------------------------

=======================
0038, February 5th 2011
=======================
Late move reductions switched back on to compare strength. Slight victory for LMR over 0037, will test further in a 300 game match tonight.

400 games played / Tournament is finished
Name of the tournament: Arena 3.0 - W7-66
Site/ Country: PC-W7-1, United Kingdom
Level: 1 Second
Hardware: Intel(R) Core(TM) i7 CPU 860 @ 2.80GHz with 4.0 GB Memory
Rival-0037 - Clueless : 52.5/100 48-43-9
Rival-0037 - Cuckoo107 : 7.0/100 4-90-6
Rival-0037 - Rival-0038 : 48.5/100 33-36-31
Rival-0037 - RivalUCI-1.18 : 43.5/100 37-50-13

------------------------------------------------------------------------------
300 games played / Tournament is finished
Name of the tournament: Arena 3.0 - W7-67
Site/ Country: PC-W7-1, United Kingdom
Level: 1 Second
Hardware: Intel(R) Core(TM) i7 CPU 860 @ 2.80GHz with 4.0 GB Memory
Operating system: Windows 7 Professional Professional (Build 7600) 64 bit
Rival-0038 - Clueless : 150.0/300 130-130-40
------------------------------------------------------------------------------

=======================
0037, February 5th 2011
=======================
* Turned off a debug flag that was performing a super-verification on hash retrievals by comparing the exact state of the board. BTW - this has
never found a clash against the 64-bit lock key despite my always believing it is the source of all engine errors.
* Reduced to three the maximum number of real-life game moves for which a position will be considered usable from the hash table.
* This is a milestone for Java Rival - since I started work on the Java engine in November 2010, I've been using the Clueless engine as a testing ground
for Rival's strength - it made little sense to use one of the stronger engines, as winning so few games it's difficult to judge fine changes in
strength.

Version 0037 is the first build to beat Clueless over a decent run of games at one second per move, although it was close (Rival won 52% of the tournament points.)

--------------------------------------------
Name of the tournament: Arena 3.0 - W7-65
Site/ Country: PC-W7-1, United Kingdom
Level: 1 Second
Hardware: Intel(R) Core(TM) i7 CPU 860 @ 2.80GHz with 4.0 GB Memory
Operating system: Windows 7 Professional Professional (Build 7600) 64 bit
--------------------------------------------
Rival-0037 - Clueless : 261.5/500 233-210-57
--------------------------------------------

The versions before build 0001, before I began logging changes to the code were achieving around 20% and not long before that I was having to
give Rival a 10x thinking time advantage just to get a score that would allow comparisons with previous versions!

Before I go on to screw up the next few versions, let me review here where Rival is at in terms of how it searches...

-------------
Search Basics
-------------
* Standard negascout PVS search
* Null move with R=2 so long as one friendly piece remains
* Two equal-sized hash tables, always replace and height replace, with a 64-bit lock
* Captures and pawn promotions only in quiescence search
* Internal iterative deepening, mate killer, killer moves, history tables, piece square tables, captures and hanging pieces considered for move ordering
* Clunky but functional 3-fold and 50-move draw handling. I am still amazed at how tricky it is to cover all the bases on this sometimes - I mean how hard should it be really?
* Late move reductions are currently disabled. It feels as if they hurt the engine, but I haven't demonstrated this beyond doubt.
* Null move verification is currently disable. Same reason as LMR, and same lack of proof.
* Iterative deepening with aspiriation window of 40 centipawns.
* Fractional extensions (check = 3/4 ply, immediate mate threat = 1 ply, more distance mate threat = 1/2 ply)

-------------------
Optimisation things
-------------------
* Bitboard/Magic Bitboard move generation. Magic move generation is switched to loop generation in Android version to save memory.
* Ninjafied bit twiddling routines, as far as I think you can in Java
* Running under a 64-bit JRE makes a very big difference to speed
* Pawn hash in evaluation, including remembering previous pawn score for super-fast access to the score which happens a lot and gave the program
as huge boost when implemented.
* Averaging around 1,100kNps on my set of a few dozen test positions on an Intel i7 CPU 860 @ 2.80GHz

----------
Evaluation (clearly loads of work to be done here)
----------
* Material balance
* Special consideration for king and pawn endings and lone king v pieces endings
* Opening development
* End game changes, such as king becoming more active
* Piece square tables
* King tropism
* King safety (almost all taken from The Right Way to Play Chess by David Brine Pritchard)
* Pawn structure, neighbour support, isolated, doubled, and passed pawn evaluations
* Bishop pair bonus
* Rooks on open files, rooks supporting rooks
* Bishop mobility

------------
Other things
------------
* The UCI version sets three threads running
(1) A UCI Controller monitoring user input and sending commands to the engine.
(2) A timer kicked off by the engine class that caches the system time every 50ms for fast access by the engine, and writing to stdout when the engine has something to say
(3) The main engine - currently it doesn't ponder, if it asked to. There is a slight hack in here - when the search completes, the engine immediately writes the best move to stdout to avoid potentially waiting 49ms for the next timer heartbeat.

====
0036
====
Russ has finished work on the first release candidate for the Android GUI
Some changes to the engine to distinguish between UCI or Android mode (the Android GUI uses a Java wrapper around the engine rather than using
UCI)
Corrected slight bug in SearchPath which was leaving one move off some paths
Added scores for bishop mobility and rooks on open files
Reduction to rook pair and knight pair penalties
Big reduction to king-king opposition bonus for endgame positions
Removed pawn push extensions completely for the time-being
Added breaks on the number of fractional extensions that can be awarded at any one node. This number reduces as certain ply boundaries are reached.
Distinguished between immediate threat extensions (mate in 1) and longer mating threats
Removed verification on null move to see how we get on over the next few versions
R=2
Removed all the min depth calculation stiff from null move
There seems to have been a marked improvement in strength starting with version 0033, and the tournament currently running with a 0036 build indiciates that
this should continue with this version. I think a lot of this can be attributed to some nice recent speed increases.

====
0035
====
Code was very keen to create friendly isolated pawns and, moreso, isolated D pawns (for white, and E pawns for black - even though they should be
D for black as well). Basically, the code was being added instead of substracted for white and vice versa for black.
Rival-0035 - Clueless : 52.0/100 47-43-10
Rival-0035 - Cuckoo107 : 4.0/100 2-94-4
Rival-0035 - Rival-0010 : 61.0/100 51-29-20
Rival-0035 - RivalUCI-1.18 : 47.0/100 36-42-22

====
0034
====
Fixed path bug where height was not getting set correctly and also slightly sped up some path-setting functions.
Set allowed hash history to zero to compare with 0033 after some weird behaviour in game 77 of XP-19
Removed SetHeight() in path which caused problems with extra moves in path after change in 0033
I think this also has super verify on hash in it

====
0033
====
Was not considering reductions when determining current distance from leaf when deciding whether to perform a PVS search.
Big change to the SearchPath class so that it never creates new int[] arrays. This means it needs to allocate excess memory up front but avoids
garbage collection.
Speeded up IID and removed need to create a new SearchPath() on IID searches by simply reseting the bestPath variable after an IID search
Started counting nodes on makemove pairs rather than just in evaluate
Reduced threat extension to 1/4 ply

1: Clueless 154.0/300
2: Rival-0033 146.0/300
Name of the tournament: Arena 3.0 - W7-60

Surely not long now until Rival finally beats its life-long sparring partner...

====
0032
====
Null move reduce depth reinstated.
First build with repackaged classes and merge with com.netadapt - much smaller jar size down from nearly 3mb to just over 400k

1: Clueless 114.5/213
2: Rival-0032 98.5/213

====
0031
====
Null move reduce depth turned off just for comparison with 0030

--------------------------------------------
Tournament W7-58
--------------------------------------------
Rival-0031 - Clueless : 36.0/100 29-57-14
--------------------------------------------

====
0030
====
DR > 1 in PVS reversed from 0028 after finding it made a difference in 5r2/p2Pk1p1/1p2B2p/3P4/1R3P2/5r2/1P5P/6K1 w - - for some reason yet to be understood.
FEN = 5r2/p2Pk1p1/1p2B2p/3P4/1R3P2/5r2/1P5P/6K1 w - -
Single Depth: 12 Time: 5.48 Score: 1.85 Nodes: 3,964,857 NPS: 724,174 Height: 11 Path: f4f5 f3f5 e6f5 f8f5 d7d8Q e7d8 b4d4 d8d7 d4d3 d7d6 d3d1
Scaled down passed pawn values and some other pawn values/penalties
Late move reductions turned off due to them seeming to be the problem with the position above
Null move adjust min depth switched back on because it doesn't seem to be the problem and saves a feck load of search time
W7-57
Clueless - Rival-0030 : 163.0/300 148-122-30
Rival-0030 - Clueless : 137.0/300 122-148-30

====
0029
====
Removed bonus for any passed pawn on the same file as another passed pawn
Turned off the auto-reduce depth when depth remaining < R

====
0028
====
Slight saving in nodes by making sure that depth remaining > 1 for a PVS research so that it's not just going to go and call the
quiesce search again. In other words, the value of newPath can be trusted here - no research necessary.
Removed check in quiesce() to see if move was capture or promotion because these are filtered out in orderQuiesceMoves()
Restored hanging piece captures above others in move ordering
Added mate killer - I think it may be a slight improvement
1: Clueless 173.0/300
2: Rival-0028 127.0/300
Name of the tournament: Arena 3.0 - W7-55

====
0027
====
I think I've fixed a bug in threefold repetition where it would play a move thinking it was a definte draw if the opponent had the option to make
the final move in a 3x draw situation. Very bad if you are up in material and make a move that allows a capture which, which of course the opponent will
make instead of taking the draw option (note that the position that allows that capture will surely be the first time that position has occured, but
the opponent has a legal move that will create a position which will have appeared three times.)

1: Rival-0027 93.5/100
2: Clueless 6.5/100
Name of the tournament: XP-15
Clueless playing at 2% strenght, Rival playing at 2000%

Game50/100 from XP-15
In the analysis below, it seems to take the leaf node (8/p5p1/1p1k3p/3P1r2/8/8/1P5P/3R2K1 b - -) at face value (1.85) even
though a quiesce search gives -1.53.
FEN = 5r2/p2Pk1p1/1p2B2p/3P4/1R3P2/5r2/1P5P/6K1 w - -
Depth: 12 Time: 5.48 Score: 1.85 Nodes: 3,964,857 NPS: 724,174 Height: 11 Path: f4f5 f3f5 e6f5 f8f5 d7d8Q e7d8 b4d4 d8d7 d4d3 d7d6 d3d1

Eval = -185
Quiesce = 153
FEN = 8/p5p1/1p1k3p/3P1r2/8/8/1P5P/3R2K1 b - -
Depth: 12 Time: 1.10 Score: 1.68 Nodes: 837,084 NPS: 760,985 Height: 11 Path: f5d5 d1f1 d5a5 f1f2 a5a2 g1f1 b6b5 b2b4 a2a1 f1g2 a7a6

W7-54
1: Clueless 177.0/300
2: Rival-0027 123.0/300

W7-52
1: Clueless 105.0/200
2: Rival-0027 98.0/200
3: Rival-0026 97.0/200

====
0026
====
King safety positions from The Right Way To Play Chess are referenced after this weak king position put White in a horrific position

r3n1k1/1bqr1pp1/1p2p1p1/p1b1P3/1NP3Q1/2B3P1/P2N1P1P/1R3RK1 w - a6 0 26

====
0025
====
Allow verified null move but only when fewer than three friendly pieces

-----------------Clueless-----------------
Clueless - Rival-0025 : 62.0/100 57-33-10
-----------------Rival-0025-----------------
Rival-0025 - Clueless : 38.0/100 33-57-10

01: RivalUCI-1.18 92.5/154
02: Clueless 88.0/160
03: Rival-0025 86.0/154
04: Rival-0017 85.0/160
05: Rival-0023 80.0/154
06: Rival-0022 78.5/154
07: Rival-0021 76.5/161
08: Rival-0024 76.0/154
09: Rival-0018 72.0/160
10: Rival-0009 71.0/154
11: Rival-0019 68.5/159
12: Rival-0016 68.0/160

====
0024
====
Connected passed pawn bonus reduced to +50
Possibly a slight speed up in isolated pawn calculation and other parts of evaluation function where tenary operation ended with ": 0"
Speedup in makemove by checking the ALL bitboard to see if it's worth determining the captured piece

====
0023
====
Large bonus (+125) for passed pawn if it is next to the previous found passed pawn
Reduced mate and pawn extensions to 1/2 ply
Reduced check extension to 3/4 ply (skip one, extend three, skip one, extend three, etc...)

====
0022
====
Null move pieces back to zero
Reduced penalties for rook and knight pairs, slight reduction to bishop pair bonus
Rewrote king safety pawn shield and minor shield code - bit simpler, perhaps more effective

====
0021
====
Slight optimisation on battery attack counting
Removed hanging squares around king from evaluation
Verified null move back in again

====
0020
====
Added hanging squares around King evaluation

====
0019
====
Scaled down Queen value to 1000
Added penalties for rook and knight pairs
Reintroduced LMR
Don't add the position to both the height and always replace hash tables at the same time
Move the height entry into the always replace when overwritten, so long as it is not from a previous search
Big speedup to xray attackers by using bitboards and removing the blocker from ALL and BISHOPS/ROOKS after each attack found
Swapped around the move ordering of capturing hanging pieces and low pieces capturing higher value pieces
Mucked around with King Safety

====
0018
====
Speed optimisations to attack and check functions (merged queen/rook and queen/bishop bitboards)
Replaced some &7 and >>>3 with %8 /8 - there's nothing in it and it is much easier to read
Turned off Late Move Reductions

====
0017
====
Removed verified null move
Put null move pieces back to 1
-----------------Clueless-----------------
Clueless - Rival-0017 : 90.0/149 85-54-10
-----------------Rival-0017-----------------
Rival-0017 - Clueless : 59.0/149 54-85-10

====
0016
====
Adjustable null move depth towards leaf nodes switched back on
Verified null move switched back on
Nullmove pieces = 0
Move node counting to after each makemove call
Modification to passed pawn multiplier to multiply by ratio of starting pieces / remaining pieces
Modified pawn support bonus to include pawns adjacent on the same rank
W7-44
1: Clueless 185.0/300
2: Rival-0016 115.0/300

W7-43
01: Rival-0016 35.0/50 .....
02: Rival-0006 2.5/5 001=1
03: Rival-0012 2.0/5 01001
03: Rival-0010 2.0/5 00=1=
03: Rival-0009 2.0/5 10010
03: Rival-0008 2.0/5 00110
03: Rival-0014 2.0/5 00110
08: Rival-0013 1.0/5 01000
08: Rival-0011 1.0/5 00100
10: Rival-0005 0.5/5 =0000
11: Rival-0015 0.0/5 00000

====
0015
====
added do{}while(false) optimization to isSquareAttacked(...)
moved isNonMoverInCheck out of search to makeMove and makeNullMove
slight optimisation to calculateSupplemtaryBitboards(...)
Added passed pawn score to pawn hash and multiplier for passed pawn bonus based on material left on board
W7-42
01: Rival-0015 17.5/45 .....
02: Rival-0011 4.5/5 11=11
03: Rival-0014 4.0/5 11110
04: Rival-0006 3.5/5 011=1
05: Rival-0005 3.0/5 11010
05: Rival-0008 3.0/5 10011
07: Rival-0009 2.5/5 0101=
07: Rival-0013 2.5/5 01=01
07: Rival-0010 2.5/5 =0101
10: Rival-0012 2.0/5 01010

====
0014
====
Simplified null move - removed NULLMOVE_MINIMUM_DISTANCE_FROM_LEAF - this is now calculated as being NULLMOVE_MAXIMUM_REDUCE_DEPTH + 2

====
0013
====
NULLMOVE_MINIMUM_DISTANCE_FROM_LEAF = 2->3;

====
0012
====
NULLMOVE_MAXIMUM_REDUCE_DEPTH = 3->2;
NULLMOVE_MINIMUM_DISTANCE_FROM_LEAF = 3->2;
Checked that reduceDepth > 0 before embarking on null move
Moved calculation of pawnHashIndex in getPawnScore so that it only gets calculated once

====
0011
====
Removed verified null move
W7-37 (not that Rival-0011 was running as the development code so could have been modified accidentally during the tournament)
1: Rival-0011 126.5/400
2: Cuckoo107 97.5/100
3: RivalUCI-1.18 70.0/100
4: Clueless 60.0/100
5: Rival-0010 46.0/100

====
0010
====
Quick pawn hash return if hash index is same as previous index

====
0009
====
Added research when LMR and score >= beta
Increased mate and pawn threat fractional extension to 6
130.5/300 v Clueless at 1s per move (W7-34)

====
0008
====
Added the "ply" argument to count from zero upwards with each ply. This makes some things much easier than trying to calculate our position in
the tree based on depth, extensions & reductions.
Added Internal Iterative Deepening - I think
Increased connected rooks bonus
39.5/97 v Clueless at this point
Opposition bonus was wrong way round!
Added Fractional Extensions
RivalTester was only looking at Quiesce moves at the root!
122.5/300 v Clueless at 1s per move

====
0007
====
In fail low/high situations folling initial aspiration search, it was searching with a low/high bound extended to -inf/+inf but because it was
just passing the infinity value into the new search and not updating AspirationLow and AspirationHigh, it meant that after the re-search it
still thought it was outside the AspirationLow/High bounds and so did another search with a full window!
101/300 v Clueless at 1s per move

====
0006
====
Increased isolated pawn penalties
Increased doubled pawn penalty
Increased pawn support bonus
Added rule of the square for pawn end games
Added opposition knowledge for pawn games

====
0005
====
Cached currentTimeMillis for quick access by engine to save it having to work out when to call the system clock
Verified null move didn't re-search (!)
Tweaks in orderedMoves[] handling
More changes to UCI controller
Forced info and bestmove to be written by engine immediately after go() finishes


====
0004
====
Return null move to R=3
Play null move while at least one friendly piece left
Clear hash on ucinewgame command
Various changes to UCI controller to resolve threading issues

====
0003
====
Added pawn push to 6th rank extension
Modified history heuristic to use an increment/decrement system rather than just increment
PV distance from leaf check added
Late move reductions added
Null Move Reduce Depth = 4

====
0002
====
Pawn push to 7th rank extension
Mate threat extensions
Promotions now searched in Quiesce()