Very cool bug inside Minic

Discussion of chess software programming and technical issues.

Moderators: bob, hgm, Harvey Williamson

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
Post Reply
User avatar
xr_a_y
Posts: 988
Joined: Sat Nov 25, 2017 1:28 pm
Location: France

Very cool bug inside Minic

Post by xr_a_y » Sat Mar 07, 2020 8:03 pm

I've just discovered a fun bug in Minic.
As I use internal end-game heuristic for basic end-games, Minic knows that KNBK is a win and score it very high.
But it only scores KBQK the price of Q+B, KRBK as R+B and KBBK as 0 ...

So it tends to under promote to N in some circumstance, which look like some kind of "humiliation mode", but is just a bug ;)

Here is an example (move 69) :


Alayan
Posts: 198
Joined: Tue Nov 19, 2019 7:48 pm
Full name: Alayan Feh

Re: Very cool bug inside Minic

Post by Alayan » Sat Mar 07, 2020 11:37 pm

A win is a win, as some would say. I'd make it prefer KRBK and KQBK, but this is fun.

KBBK at 0... I assume this is only for same-colored bishops, right ? KBBK with one LSB and one DSB is a clear win.

User avatar
xr_a_y
Posts: 988
Joined: Sat Nov 25, 2017 1:28 pm
Location: France

Re: Very cool bug inside Minic

Post by xr_a_y » Sun Mar 08, 2020 8:11 am

Alayan wrote:
Sat Mar 07, 2020 11:37 pm
KBBK at 0... I assume this is only for same-colored bishops, right ? KBBK with one LSB and one DSB is a clear win.
of course KLL and KDD are draws but KLD has it's own end game heuristic.

User avatar
hgm
Posts: 24132
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: Very cool bug inside Minic

Post by hgm » Sun Mar 08, 2020 8:33 am

The bug is arguably that you award a special score to KBNK in the first place. Its naive evaluation would already be +6, and if +6 doesn't mean 'certain win', what will? (Of course KNNK does deserve special treatment, as it is a certain draw, but that is another story.)

I usually treat end-games against a bare King only as 'special' by the fact that unlike all other end-games where the strong side is pawnless I do not discount the naive evaluation by 50%. And of course the dead draws KBKx and KNKx and KNNK are recognized as such.

In Pawn endings it can be justified to multiply the naive score by a factor 1.5 to 2.

Perhaps the following set of rules has some general validity:
* strong side Pawnless? score *= 0.5
* weak side bare? score *= 2
* weak side only Pawns? score *= 1.5
* strong side lacks mating potential? score *= 0.1

User avatar
xr_a_y
Posts: 988
Joined: Sat Nov 25, 2017 1:28 pm
Location: France

Re: Very cool bug inside Minic

Post by xr_a_y » Sun Mar 08, 2020 8:39 am

In fact, I think this "winning bonus" comes from the same idea :

I have an enum, this way, to "sort" end game

Code: Select all

enum Terminaison : unsigned char { 
   Ter_Unknown = 0, 
   Ter_WhiteWinWithHelper,        // for KRK, or KPK, or KBNK, ...
   Ter_WhiteWin,                  // for KRR, or KQR, or ...
   Ter_BlackWinWithHelper, 
   Ter_BlackWin, 
   Ter_Draw,                      // 3reps, pat, 50 moves
   Ter_MaterialDraw,              // KBK, KNK, KNNK
   Ter_LikelyDraw,                // for things like KRKB or KDLKN
   Ter_HardToWin };               // for KQKR or KRNKN, ...
And I apply those factor, also taking 50 moves rule into account.

Code: Select all

       // end game knowledge (helper or scaling)
       if ( safeMatEvaluator && (p.mat[Co_White][M_t]+p.mat[Co_Black][M_t]<6) ){
          const Color winningSideEG = score[sc_Mat][EG]>0?Co_White:Co_Black;
          if      ( MEntry.t == MaterialHash::Ter_WhiteWinWithHelper || MEntry.t == MaterialHash::Ter_BlackWinWithHelper ) return (white2Play?+1:-1)*(MaterialHash::helperTable[matHash](p,winningSideEG,score[sc_Mat][EG]));
          else if ( MEntry.t == MaterialHash::Ter_Draw)         { if (!isAttacked(p, kingSquare(p))) return context.drawScore(); }
          else if ( MEntry.t == MaterialHash::Ter_MaterialDraw) { if (!isAttacked(p, kingSquare(p))) return context.drawScore(); }
          else if ( MEntry.t == MaterialHash::Ter_WhiteWin || MEntry.t == MaterialHash::Ter_BlackWin) score.scalingFactor = 5 - 5*p.fifty/100.f;
          else if ( MEntry.t == MaterialHash::Ter_HardToWin)  score.scalingFactor = 0.5f - 0.5f*(p.fifty/100.f);
          else if ( MEntry.t == MaterialHash::Ter_LikelyDraw) score.scalingFactor = 0.3f - 0.3f*(p.fifty/100.f);
       }

User avatar
hgm
Posts: 24132
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: Very cool bug inside Minic

Post by hgm » Sun Mar 08, 2020 11:00 am

But what I described was not really a bonus for the mere fact that it should be a win. It would be applied to any position, also these that are not sure wins (e.g. not every KBNK position is won, even with white to move). The factor just corrects for the fact that in Pawn endings a much smaller naive advantage is on average decisive, and it is also awarded when there is no verified win. And that defending is much harder without any pieces.

The problem you mentioned is caused by artificially messing with the score for 'verified wins', as the almost unavoidable incompleteness of the list of those will then cause pathologic behavior. Usually end-games that would qualify as verified wins have high-enough score by themselves, and artificially upping the score by a large amount serves no purpose.

bob
Posts: 20795
Joined: Mon Feb 27, 2006 6:30 pm
Location: Birmingham, AL

Re: Very cool bug inside Minic

Post by bob » Sun Mar 08, 2020 8:46 pm

I had one of those "moment" years ago. Was playing GM Dzhindi in a 4 computer vs 4 human round-robin tournament. Crafty had gotten into an easily won ending, and suddenly made two odd piece sacrifices to end up in a won KNN vs KP ending. Fortunately the Nalimov tables were active, which is what led to that set of moves. Looked ugly.

Post Reply