Why are the Ippo derivative stronger than Stockfish?

[benstoker]

Let's stop. Just stop. I'll go elsewhere. Nothing to see here ... just move along ...

He has been call an idiot twice just for expressing his opinion. He mentioned he was not bothered by this and is ready to let it go.

I agree with him at least on one point where this thread is going very _non-techinical_.

What do you expect with a thread started " Engine X is stronger than Engine Y while it uses all the ideas Engine Y has and has all the source code of Engine X to work with" ?

Then lets decompile (Illegal AFAIK) that super engine Z see what it does. Oh I decompiled and saw it has nothing but horizon extensions. Bravo.
Is this how technical discussion go about ? The end justifies the means ,right ?

3) you can wait for a "peer-reviewed" definition (that won't include your contribution), but in this sub-forum, your requests should start with "Excuse me", "Please" and leave with a "thank you".

This bullshit is what prompted me to post. Who are you to tell anyone how he should post ? That is what the charter is here for. He can leave without a thank you, ask without a please as long as he sticks to the charter. He can have his own ideas defend them as he will.

So who am I to tell him to say "please" but, it is ok for him to tell Marco to shut up?

Who am I? A member. I am entitled to an opinion and express it. This is not an isolated case. It is the accumulation of months of a continuous attempt to take over of the general sub-forum with trolls. This is the last corner of the general forum that has maintained on topic and I am a bit sensitive, because if the record is not set straight, we are downhill.

I find it interesting that you find my request for politeness bullshit when Ben has been taunting a GM for jealousy, and telling Marco to shut up. Do you find that acceptable and my request for politeness and gratefulness bullshit?

Of course, you do not need the actual words ("please and thank you"), it is a matter of attitude. Besides, I am requesting something that I personally try. I always try to be grateful when I ask people who know better than me, and it would not occur to me to taunt them or insult them.

Ben has been asking for help in the past, and he got it. Now, he thinks he can come to the programming subforum and start trolling. I do not think he was called idiot before his posts. Anyway, I did not call him idiot so please redirect your annoyance to the proper targets.

But, you may be right. Asking for "please" and "thank you" is too much nowadays.

Miguel

[bob]

He has been call an idiot twice just for expressing his opinion. He mentioned he was not bothered by this and is ready to let it go.

I agree with him at least on one point where this thread is going very _non-techinical_.

What do you expect with a thread started " Engine X is stronger than Engine Y while it uses all the ideas Engine Y has and has all the source code of Engine X to work with" ?

Then lets decompile (Illegal AFAIK) that super engine Z see what it does. Oh I decompiled and saw it has nothing but horizon extensions. Bravo.
Is this how technical discussion go about ? The end justifies the means ,right ?

3) you can wait for a "peer-reviewed" definition (that won't include your contribution), but in this sub-forum, your requests should start with "Excuse me", "Please" and leave with a "thank you".

This bullshit is what prompted me to post. Who are you to tell anyone how he should post ? That is what the charter is here for. He can leave without a thank you, ask without a please as long as he sticks to the charter. He can have his own ideas defend them as he will.

His point was simply "you will catch more flies with honey than with vinegar..."

[mcostalba]

I have also received some pm with very interesting material regarding horizont effect stuff.

I have asked him permission to re-post and as soon as I get I'll re-post here....

Ok, I got permission from BB+ to repost his pm:

********************************

Not sure if this is what Vida/Dailey mean, but see Phalanx, for instance:
http://code.google.com/p/phalanx-chess/ ... n111&r=111

VII 19971022 [...] New extension trick that helps in some
horizon-effect type positions, it's based on measuring difference
between current score and null move result; if current score is much
better, the side to move must be under threat and the line is
extended, similar trick is also in gnuchess.

In general, extensions were big in the DeepBlue era (and Junior
promoted them too), but then reductions became more prominent over the
last 5-10 years.

********************************************************

I might also point out that a wider class of extensions is
occasionally termed "horizon-effect" extensions, as they generically
help you avoid a horizon effect. This might (or might not) be what
Richard meant by a "new kind of 'horizon' extension." For instance, I
found this description: Pepito features Bitboard infrastructure,
Negascout search algorithm, Usual depth extensions to avoid horizon
effect (i.e. check, recapture, pawn push...), An older, and very
vague, paper is Searching to Variable Depth in Computer Chess.

********************************************************

Come to think of it, you could just call qsearch a "horizon effect"
extension. (It is a bit funny, but in some of his first CCC posts back
in 2004, Rajilch professed a desire to "get rid" of qsearch!).

Back in 2005, Tord said that Botvinnik-Markoff extensions might also
be listed as "horizon effect" in particular:
http://www.stmintz.com/ccc/index.php?id=457934

[Michel]

The following piece of code is in the GnuChess source. If I understand correctly then the search is extended when the opposing side puts an undefended piece between a checking piece and his king. It seems rather doubtful to me that this particular extension is useful given that there are already check extensions.

Code: Select all

/****************************************************************************
 *
 *  The following extension is to handle cases when the opposing side is
 *  delaying the mate by useless interposing moves.
 *
 ****************************************************************************/
   if (ply > 2 && InChk[ply-1] && cboard[t0] != king && t0 != t1 &&
         !SqAtakd (t0, xside))
   {
      HorzExtCnt++;
      depth += 1;
      extend = true;
   }

[rvida]

Extending moves on the last ply is a very old idea but since Richard was not very specific I have no way of knowing if this extension has anything to do with the horizon thing he talked about.

The idea itself is not new of course. It is about avoiding stand pat in qsearch when the side to move is under serious threat, but the static evaluation is still above scout.

Upon entering search() instead of classical

Code: Select all

int search(int depth, int scout) {
  if &#40;depth < ONE_PLY&#41; &#123;
    return qsearch&#40;0, scout&#41;;
  &#125;
  else &#123;  
     /* ... continue with normal search */
  &#125;
&#125;

do something like this

Code: Select all

int search(int depth, int scout) {
  if &#40;depth < ONE_PLY&#41; &#123;
    if &#40;ss->threat
        && (!move_is_quiet&#40;&#40;ss-1&#41;->curr_move&#41; || ss->threat > &#40;ss-1&#41;->threat&#41;
        && eval >= scout + TEMPO
        && !horizon_was_extended&#41; &#123;
          horizon_was_extended = true;
          depth = ONE_PLY;
      &#125;
      else
        return qsearch&#40;0, scout&#41;;
  &#125;
  
  /* ... continue with normal search */
&#125;

What is in ss->threat is implementation specific, in Houdini it comes from evaluate() and can be 0, 1 or 2. This is not very interesting in itself, and reimplementing this (even exactly same way as in Houdini) will probably slightly hurt ELO for most non-Ippolit engines. But in Ippolit framework there are at least 2 built-in factors affecting when this extension will _not_ trigger and this helps greatly.

1. If the position was evaluated using lazy-eval, ss->threat field is always zero. Because of this, the extension is triggered only when the material balance is close enough to scout value. (although for engines without lazy eval this condition can be coded explicitly)

2. Eval cache hit: again, ss->threat is zero. This occurs somewhat randomly, because it depends on the hash key of the position.

[mcostalba]

do something like this

Code: Select all

int search(int depth, int scout) {
  if &#40;depth < ONE_PLY&#41; &#123;
    if &#40;ss->threat
        && (!move_is_quiet&#40;&#40;ss-1&#41;->curr_move&#41; || ss->threat > &#40;ss-1&#41;->threat&#41;
        && eval >= scout + TEMPO
        && !horizon_was_extended&#41; &#123;
          horizon_was_extended = true;
          depth = ONE_PLY;
      &#125;
      else
        return qsearch&#40;0, scout&#41;;
  &#125;
  
  /* ... continue with normal search */
&#125;

This is interesting. In SF static eval is actually a pair: static evaluation of the position and margin of uncertainity of the static value (this is in theory, a "would be nice" target, in fact the margin is a much more trivial estimation of king danger of the position.)

Perhaps we can use that margin as threat: if margin is big it means king is in dangerous waters and we can extend (if static evaluation is above beta)....something to put on our test queue

[lkaufman]

The idea itself is not new of course. It is about avoiding stand pat in qsearch when the side to move is under serious threat, but the static evaluation is still above scout.

Upon entering search() instead of classical

Code: Select all

int search(int depth, int scout) {
  if &#40;depth < ONE_PLY&#41; &#123;
    return qsearch&#40;0, scout&#41;;
  &#125;
  else &#123;  
     /* ... continue with normal search */
  &#125;
&#125;

do something like this

Code: Select all

int search(int depth, int scout) {
  if &#40;depth < ONE_PLY&#41; &#123;
    if &#40;ss->threat
        && (!move_is_quiet&#40;&#40;ss-1&#41;->curr_move&#41; || ss->threat > &#40;ss-1&#41;->threat&#41;
        && eval >= scout + TEMPO
        && !horizon_was_extended&#41; &#123;
          horizon_was_extended = true;
          depth = ONE_PLY;
      &#125;
      else
        return qsearch&#40;0, scout&#41;;
  &#125;
  
  /* ... continue with normal search */
&#125;

What is in ss->threat is implementation specific, in Houdini it comes from evaluate() and can be 0, 1 or 2. This is not very interesting in itself, and reimplementing this (even exactly same way as in Houdini) will probably slightly hurt ELO for most non-Ippolit engines. But in Ippolit framework there are at least 2 built-in factors affecting when this extension will _not_ trigger and this helps greatly.

1. If the position was evaluated using lazy-eval, ss->threat field is always zero. Because of this, the extension is triggered only when the material balance is close enough to scout value. (although for engines without lazy eval this condition can be coded explicitly)

2. Eval cache hit: again, ss->threat is zero. This occurs somewhat randomly, because it depends on the hash key of the position.

As far as I know, this is an original if fairly obvious idea, I'm surprised we never tried it. Thanks for sharing, and if this is truly a good idea congrats Robert! I doubt that this is "Ippo-specific"; if it really helped Houdini it seems like it should help Komodo and others. Is it really of no value in Critter?

[mcostalba]

Perhaps we can use that margin as threat: if margin is big it means king is in dangerous waters and we can extend (if static evaluation is above beta)....something to put on our test queue

This is just a first attempt, totally untested:

Code: Select all

diff --git a/src/search.cpp b/src/search.cpp
index 0e24970..0c2414a 100644
--- a/src/search.cpp
+++ b/src/search.cpp
@@ -1182,6 +1182,13 @@ split_point_start: // At split points actual search starts from here
       // Step 11. Decide the new search depth
       ext = extension<PvNode>&#40;pos, move, captureOrPromotion, moveIsCheck, singleEvasion, mateThreat, &dangerous&#41;;
 
+      // Extend last ply if qsearch is going to stand-pat due to a big eval margin
+      if (   depth < 2 * ONE_PLY
+          && ext < ONE_PLY
+          && ss->eval < beta
+          && ss->eval + ss->evalMargin >= beta&#41;
+          ext = ONE_PLY;
+
       // Singular extension search. If all moves but one fail low on a search of &#40;alpha-s, beta-s&#41;,
       // and just one fails high on &#40;alpha, beta&#41;, then that move is singular and should be extended.
       // To verify this we do a reduced search on all the other moves but the ttMove, if result is

Note that the code is in search(), just before to call qsearch(), so colors (and signs) are reversed.

[bob]

I have also received some pm with very interesting material regarding horizont effect stuff.

I have asked him permission to re-post and as soon as I get I'll re-post here....

Ok, I got permission from BB+ to repost his pm:

********************************

Not sure if this is what Vida/Dailey mean, but see Phalanx, for instance:
http://code.google.com/p/phalanx-chess/ ... n111&r=111

VII 19971022 [...] New extension trick that helps in some
horizon-effect type positions, it's based on measuring difference
between current score and null move result; if current score is much
better, the side to move must be under threat and the line is
extended, similar trick is also in gnuchess.

In general, extensions were big in the DeepBlue era (and Junior
promoted them too), but then reductions became more prominent over the
last 5-10 years.

********************************************************

I might also point out that a wider class of extensions is
occasionally termed "horizon-effect" extensions, as they generically
help you avoid a horizon effect. This might (or might not) be what
Richard meant by a "new kind of 'horizon' extension." For instance, I
found this description: Pepito features Bitboard infrastructure,
Negascout search algorithm, Usual depth extensions to avoid horizon
effect (i.e. check, recapture, pawn push...), An older, and very
vague, paper is Searching to Variable Depth in Computer Chess.

********************************************************

Come to think of it, you could just call qsearch a "horizon effect"
extension. (It is a bit funny, but in some of his first CCC posts back
in 2004, Rajilch professed a desire to "get rid" of qsearch!).

Back in 2005, Tord said that Botvinnik-Markoff extensions might also
be listed as "horizon effect" in particular:
http://www.stmintz.com/ccc/index.php?id=457934

This sounds like a variation of the 15+ year old "null-move threat extensions." The idea is if a move fails high on a normal search, and fails low on a null-move search, then that move might be a sort of "singular" move that is holding off some serious threat. And it is often simply a delaying or horizon-effect type move. To see through the "goodness" a deeper search is used (an extension).

BTW, at one point, Junior didn't have a q-search. Not sure if that is true today or not...

[BubbaTough]

This is interesting. In SF static eval is actually a pair: static evaluation of the position and margin of uncertainity of the static value (this is in theory, a "would be nice" target, in fact the margin is a much more trivial estimation of king danger of the position.)

Perhaps we can use that margin as threat: if margin is big it means king is in dangerous waters and we can extend (if static evaluation is above beta)....something to put on our test queue

I have tried various forms of this either to adjust reductions or to extend leaf nodes as Houdini is said to. I personally have had not much luck with it but remain convinced some form of it should work well. Perhaps the secret to Houdini's success in this is the weird hash table stuff, which I admit I don't really get yet.

To me, its all related to a discussion between you and Larry maybe a year ago. Larry said most programs have unrealistic eval in that they do not reflect % win chance. The concensus was this was because it helped shape the search. The reason I have been looking at techniques like this is to try to have more realistic eval, but use the 2nd number to shape the search.

-Sam