Ok, in looking at the fix_depth issue you raised, I found a problem which probably still exists in your latest development version. If you set fix depth search for anything above 5, Numpty will move instantly and not search to the required depth.
To correct this, in addition to the change you mentioned (ie deleting fix_depth = 0 condition for the timer (this needs to be done twice to ensure that the time is still recorded correctly). In the ab_search function - need to insert 'if fix_depth = 0....'
Code: Select all
if fix_depth = 0 and search_depth > 5 and (orig_root < 5 or (Move_Control - conv_clock_move_no) < 4) then 'sd criteria added to make sure move from last ply is available to play (21/6/10); added fix_depth criteria (Apr 2014)
break = timer
if (((break - start_time) * 100) > think_time) or (((break - start_time) * 100) > = (0.4 * time_left)) then '(changed from 0.3 - 4/7/10)
timed_out = 1
exit function 'return 0'evaluate(side)
end if
end if
Also need minor change to code to ensure that if fix_depth = 0 that the time control conditions are not engaged
I've also fixed the rep draw claim code and implemented the winboard 'draw' feature, though I just need to test this properly - essentially this involves offering a draw if rep_pos = 3 rather than announcing the game is over with 'send result' command
I have run a tournament with Nomega (GCC compiled) against Numpty_DD. Needless to say the Numpty_DD lost most of the time
Great!, not a surprise, do you have the results, so we have an idea of the current strength difference?
Starting with the last lines ((B(36) + B(37)) <> 2 , 1 + 1 = 2 also 0 + 2 = 2 or 2 + 0 = 2 or even 4 + (-2) = 2
If one of the pawn was moved and an other piece was placed on free square then that would also provide protection. You need to think about it. Also at the top you add two squares don't think that is wise.
I tested these evaluation terms in quite some detail and there wasn't much difference including/excluding them. I was aware of the ((B(36) + B(37)) issue and potential risk, but to be honest I judged this as unlikely to happen in practice (I've never observed it) particularly given that:
- these evaluation terms are only used prior to the endgame (after which they are not relevant)
- the pawn pst's encourage the pawns to stay where they are in front of the king with the size of relevant bonus.
Of course you are welcome to test this and prove me wrong! :)
(the reason I only included two criteria (pawns) here was that I wanted to make sure that the king wouldn't be subject to back rank mates that were beyond its search depth (this did use to happen rather too frequently). Arguably, it is riskier to ignore the 'h' file here but I reasoned that the pawn psts would encourage pawn to h3 which still provides a strong protection (ie f2, g2 & h3))
also at the top you add two squares don't think that is wise.
Is this the test for blocked rook ie - If B(26) = 7 and (B(27) + B(28) = 4) THEN Pos_Eval = Pos_Eval - 25 'trapped white king rook
In this case, I thought this was quicker than the equivalent 'OR' - perhaps not but I guess it isn't material
On the trapped piece, I think you are right, re-looking at this, when B(81) = 3 I think it should be when B(74) and B(83) which should be tested not the current B(74) and B(72). Again, I found the trapped code didn't make much difference in practice but of course it should still be corrected.