// Test for backward pawn
if ( (passed | isolated | chain)
|| (ourPawns & attack_span_mask(opposite_color(Us), s))
|| (pos.attacks_from<PAWN>(s, Us) & theirPawns))
backward = false;
else
{
b = this_and_neighboring_files_bb(f) & rank_bb(Us == WHITE ? r+1 : r-1);
while (!(b & (ourPawns | theirPawns)))
Us == WHITE ? b <<= 8 : b >>= 8;
if (b & file_bb(f) & theirPawns)
backward = true;
else backward = (b | (Us == WHITE ? b << 8 : b >> 8)) & theirPawns;
}
The short match (100 games; 1 min/game) won the second patch +39 -32 =29.
Marco was right.
It seems that the second patch should be tested against original SF, not the first.
(I tried it ..... )
// Test for backward pawn
if ( (passed | isolated | chain)
|| (ourPawns & attack_span_mask(opposite_color(Us), s))
|| (pos.attacks_from<PAWN>(s, Us) & theirPawns))
backward = false;
else
{
b = this_and_neighboring_files_bb(f) & rank_bb(Us == WHITE ? r+1 : r-1);
while (!(b & (ourPawns | theirPawns)))
Us == WHITE ? b <<= 8 : b >>= 8;
if (b & file_bb(f) & theirPawns)
backward = true;
else backward = (b | (Us == WHITE ? b << 8 : b >> 8)) & theirPawns;
}
The short match (100 games; 1 min/game) won the second patch +39 -32 =29.
Marco was right.
It seems that the second patch should be tested against original SF, not the first.
(I tried it ..... )
The major problem above is the number of games. The error bar will be larger than the difference in ratings, which makes any conclusion nothing more than a guess...
This is the perfect way to take two steps backward for every one step forward...
Have you continued to test this second patch? I've played (only) 300 90-second games, but this patch scored an impressive ~55% against my compile of the original code (55, 53.5, and 56% in 3 separate 100 game matches). Much better results than the first patch I tried
Have you continued to test this second patch? I've played (only) 300 90-second games, but this patch scored an impressive ~55% against my compile of the original code (55, 53.5, and 56% in 3 separate 100 game matches). Much better results than the first patch I tried
Justin, I will test the second version but with one modification. I guess it can work even better. I found two bugs in SF code. But it is another story.
Just a quick update - I made it to 500 games (I'll probably quit at that, since I was just doing it out of curiosity). The patch scored 50% and 54% in the 4th and 5th set of 100 games, for a cumulative score of 53.7% after 500 games. Of course, I'm a testing newbie and exceptionally non-talented with computers, which should be taken into consideration when reading my numbers . But in any case, I hope it's helpful.
Justin Sherron wrote:Just a quick update - I made it to 500 games (I'll probably quit at that, since I was just doing it out of curiosity). The patch scored 50% and 54% in the 4th and 5th set of 100 games, for a cumulative score of 53.7% after 500 games. Of course, I'm a testing newbie and exceptionally non-talented with computers, which should be taken into consideration when reading my numbers . But in any case, I hope it's helpful.
C++
general
debug information format - disabled
optimization
optimization - maximize speed
favor size or speed - favor fast code
code generation
basics runtime checks - default
sfx size: 469 504
sf size: 468 992
Now it seems to be ok.
After 100 games: sfx vs sf: +33 -22 =45
I will continue test tomorow.
A try to improve this patch doesn't work.