+31 ELO !!!!lech wrote:after 300 games sfx vs sf: +113 -86 =101
next session tomorow
Well, it seems a bit too much probably tomorrow we won't be so lucky.
Moderators: hgm, Rebel, chrisw
+31 ELO !!!!lech wrote:after 300 games sfx vs sf: +113 -86 =101
next session tomorow
Of course the result of 3rd 100 games seems to be strange. Unfortunately, there are the strings of wins. Sf is able to win 6 (5,4) games one by one. Sfx rather not. I start each 100 games after reset. I don't use this comp.mcostalba wrote:+31 ELO !!!!lech wrote:after 300 games sfx vs sf: +113 -86 =101
next session tomorow
Well, it seems a bit too much probably tomorrow we won't be so lucky.
after 400 games: sfx vs sf: +149 -114 =137mcostalba wrote: +31 ELO !!!!
Well, it seems a bit too much probably tomorrow we won't be so lucky.
Marco, you wrote that now (version 1.8) it is possible.mcostalba wrote: +31 ELO !!!!
Well, it seems a bit too much probably tomorrow we won't be so lucky.
I tested another my idea (seemed to be logical). Unfortunatelly, it is very hard to get any good result.lech wrote:
sfx vs sf: +193 -141 =166 it is too much, why ??????
Hi Justin, I am using only this patch:Justin Sherron wrote: Hi Marek, could you please clarify the cumulative patching you used when testing? With the discussion between you and Marco, it wasn't clear to me what patchwork you finally decided to use when you got these results. I would like to give it a try myself and see what happens
Thanks,
-Justin
Code: Select all
// Test for backward pawn
//
// If the pawn is passed, isolated, or member of a pawn chain
// it cannot be backward. If can capture an enemy pawn or if
// there are friendly pawns behind on neighboring files it cannot
// be backward either.
if ( (passed | isolated | chain)
|| (ourPawns & attack_span_mask(opposite_color(Us), s))
|| (pos.attacks_from<PAWN>(s, Us) & theirPawns))
backward = false;
else
{
// We now know that there are no friendly pawns beside or behind this
// pawn on neighboring files. We now check whether the pawn is
// backward by looking in the forward direction on the neighboring
// files, and seeing whether we meet a friendly or an enemy pawn first.
b = this_and_neighboring_files_bb(f) & rank_bb(Us == WHITE ? r+1 : r-1);
// Note that we are sure to find something because pawn is not passed
// nor isolated, so loop is potentially infinite, but it isn't.
while (!(b & (ourPawns | theirPawns)))
Us == WHITE ? b <<= 8 : b >>= 8;
if (b & file_bb(f) & theirPawns)
backward = !(neighboring_files_bb(f) & theirPawns);
// The friendly pawn needs to be at least two ranks closer than the enemy
// pawn in order to help the potentially backward pawn advance.
else backward = (b | (Us == WHITE ? b << 8 : b >> 8)) & theirPawns;
}
I found the reason.lech wrote: +241 - 170 = 204
It is a huge advantage.
I need a help to check it.
These things happen. I've tried your code change with 1 sec games, but SF default was clearly better, therefore I have abandoned to look deeper into it.lech wrote:I found the reason.lech wrote: +241 - 170 = 204
It is a huge advantage.
I need a help to check it.
MS VC++ can compile the same code in other way (after null_move ). The SF.exe was wrong (2k too big).
Sorry, but probably, all the patch can't increase ELO.
Still it is not good play for me. I can't catch RYBKA.
Thanks Ralph, I have a new idea ......Ralph Stoesser wrote: Don't give up. Pawn eval is very interesting and important for playing strength.