I tried to quantify the ELO gain from singular extensions in IvanHoe. My code perusal implies that there are 4 places these come into play, twice in cut_node.c, and twice in pv_node.c. I eliminated 3 of these, both the SINGULAR computations for CUT nodes (both in-check and not), and the not in-check one at PV nodes. The only SINGULAR extensions still left seem to be those from forced moves when in check at a PV node (the main reason these were left in is simply that I was simply sloppy in doing this). However, there are still "extensions" based upon passed pawns and other features.
Results: a bit over 5000 games head-to-head games at 15s plus 0.25s increment on 1 cpu. The no-SINGULAR version searched an average of 3/4 ply deeper, but performed a tad over 20 ELO worse (around 5-6 sigma).
SINGULAR in IvanHoe
Re: SINGULAR in IvanHoe
I should make it more clear: I put an "#if 0" around all the code used in computing the SINGULAR condition.
Re: SINGULAR in IvanHoe
That result seems to be close to what Hyatt's tests are showing on the other forum.BB+ wrote:I tried to quantify the ELO gain from singular extensions in IvanHoe. My code perusal implies that there are 4 places these come into play, twice in cut_node.c, and twice in pv_node.c. I eliminated 3 of these, both the SINGULAR computations for CUT nodes (both in-check and not), and the not in-check one at PV nodes. The only SINGULAR extensions still left seem to be those from forced moves when in check at a PV node (the main reason these were left in is simply that I was simply sloppy in doing this). However, there are still "extensions" based upon passed pawns and other features.
Results: a bit over 5000 games head-to-head games at 15s plus 0.25s increment on 1 cpu. The no-SINGULAR version searched an average of 3/4 ply deeper, but performed a tad over 20 ELO worse (around 5-6 sigma).
Do you mind posting a diff?
Re: SINGULAR in IvanHoe
The computer is at home (with no Internet access) and I am at work. I think the changes are: eliminate lines 146-167 and 379-400 of cut_node.c; and lines 205-229 of pv_node.cDo you mind posting a diff?
Code: Select all
if (depth >= 16 && trans_move && MyOK (POSITION, trans_move)) // cut_node.c:146
{
v = MyExclude (POSITION, VALUE - VALUE_RED1, depth - DEPTH_RED,
trans_move & 0x7fff);
CHECK_HALT ();
if (v < VALUE - VALUE_RED1)
{
SINGULAR++;
height = HEIGHT (POSITION);
if (height * 4 <= depth)
SINGULAR++;
v = MyExclude (POSITION, VALUE - VALUE_RED2,
depth - DEPTH_RED, trans_move & 0x7fff);
CHECK_HALT ();
if (v < VALUE - VALUE_RED2)
{
SINGULAR++;
if (height * 8 <= depth)
SINGULAR++;
}
}
}
Code: Select all
if (depth >= 16 && trans_move) // line 379 of cut_node.c
{
v = MyExcludeCheck (POSITION, VALUE - depth,
depth - MIN (12, depth / 2), trans_move & 0x7fff);
CHECK_HALT ();
if (v < VALUE - depth)
{
SINGULAR++;
height = HEIGHT (POSITION);
if (height * 4 <= depth)
SINGULAR++;
v = MyExcludeCheck (POSITION, VALUE - 2 * depth,
depth - MIN (12, depth / 2), trans_move & 0x7fff)\
;
CHECK_HALT ();
if (v < VALUE - 2 * depth)
{
SINGULAR++;
if (height * 8 <= depth)
SINGULAR++;
}
}
}
Code: Select all
if (depth >= 16 && NextMove->trans_move && SINGULAR < 2 // pv_node.c:205
&& MyOK (POSITION, NextMove->trans_move))
{
move = NextMove->trans_move;
if (check)
v = MyExcludeCheck (POSITION, ALPHA - VALUE_RED1,
depth - DEPTH_RED, move & 0x7fff);
else
v = MyExclude (POSITION, ALPHA - VALUE_RED1,
depth - DEPTH_RED, move & 0x7fff);
CHECK_HALT ();
if (v < ALPHA - VALUE_RED1)
{
SINGULAR = 1;
if (check)
v = MyExcludeCheck (POSITION, ALPHA - VALUE_RED2,
depth - DEPTH_RED, move & 0x7fff);
else
v = MyExclude (POSITION, ALPHA - VALUE_RED2,
depth - DEPTH_RED, move & 0x7fff);
CHECK_HALT ();
if (v < ALPHA - VALUE_RED2)
SINGULAR = 2;
}
}
Re: SINGULAR in IvanHoe
20 ELO is not insignificant, but can one conclude from this that SE in ivan is NOT its holy grail? Kaufman said somewhere, I think, that ivan's unique SE is similar to rybka's and is the source of its strength.BB+ wrote:I tried to quantify the ELO gain from singular extensions in IvanHoe. My code perusal implies that there are 4 places these come into play, twice in cut_node.c, and twice in pv_node.c. I eliminated 3 of these, both the SINGULAR computations for CUT nodes (both in-check and not), and the not in-check one at PV nodes. The only SINGULAR extensions still left seem to be those from forced moves when in check at a PV node (the main reason these were left in is simply that I was simply sloppy in doing this). However, there are still "extensions" based upon passed pawns and other features.
Results: a bit over 5000 games head-to-head games at 15s plus 0.25s increment on 1 cpu. The no-SINGULAR version searched an average of 3/4 ply deeper, but performed a tad over 20 ELO worse (around 5-6 sigma).