Impressive Stockfish 1.4 !!

mcostalba · Post by **mcostalba** » Tue Jul 14, 2009 2:18 pm

The function definition is in material.h

/// MaterialInfo::space_weight() simply returns the weight for the space
/// evaluation for this material configuration.

inline int MaterialInfo::space_weight() const {

  return spaceWeight;
}

The variable spaceWeight is not undefined but is set to zero in the MaterialInfo c'tor through the MaterialInfo::clear() function. So it is always at zero.

It can assume a value different then zero only here:

Code: Select all

  // Compute the space weight
  if (pos.non_pawn_material(WHITE) + pos.non_pawn_material(BLACK) >=
      2*QueenValueMidgame + 4*RookValueMidgame + 2*KnightValueMidgame)
  {
      int minorPieceCount =  pos.piece_count(WHITE, KNIGHT)
                           + pos.piece_count(BLACK, KNIGHT)
                           + pos.piece_count(WHITE, BISHOP)
                           + pos.piece_count(BLACK, BISHOP);

      mi->spaceWeight = minorPieceCount * minorPieceCount;
  }

But from the if () condition you see that you need a good chunk of material to change the value of spaceWeight to something different then zero.

So if you have tested in a endgame or almost endgame position you should have not triggered this code.

If you test using starting position you will see that spaceWeight become bigger then zero.

Eelco de Groot · Post by **Eelco de Groot** » Tue Jul 14, 2009 2:39 pm

Tord Romstad wrote:
Eelco de Groot wrote:A question about the code. Because I just discovered that "Space" is not really used by both Stockfish 1.3 or Stockfish 1.4, although I have not looked at the older Stockfish versions, but that it is not working is easily verified when you make a version with Space set at 200 instead of the normal 100. It gives the same output, well I only did the check with an Ancalagon version, output is posted below, but it should be similar in Stockfish?

My question is did you have bad testresults with Space, I remember that Tord thought it really helped playing the opening phase in Glaurung with the new computations of safe squares behind own pawns. So I did not really expect this part of the code to be disabled in Stockfish And I did not check until today. There is no comment in the code about disabling the computation of space, but because
Code: Select all
ei.mi->space_weight()
is initialized in material.h by
Code: Select all
class MaterialInfo {

  friend class MaterialInfoTable;

public:
  Value mg_value() const;
  Value eg_value() const;
  ScaleFactor scale_factor(const Position& pos, Color c) const;
  int space_weight() const;
  bool specialized_eval_exists() const;
  Value evaluate(const Position& pos) const;
but not given any value in material.cpp as far as I can see,
It is. You will find these lines in MaterialInfoTable::get_material_info:
Code: Select all
  // Compute the space weight
  if (pos.non_pawn_material(WHITE) + pos.non_pawn_material(BLACK) >=
      2*QueenValueMidgame + 4*RookValueMidgame + 2*KnightValueMidgame)
  {
      int minorPieceCount =  pos.piece_count(WHITE, KNIGHT)
                           + pos.piece_count(BLACK, KNIGHT)
                           + pos.piece_count(WHITE, BISHOP)
                           + pos.piece_count(BLACK, BISHOP);

      mi->spaceWeight = minorPieceCount * minorPieceCount;
  }
then in evaluate.cpp in the following lines the function evaluate_space()
Code: Select all
    // Evaluate space for both sides
    if (ei.mi->space_weight() > 0)
    {
        evaluate_space(pos, WHITE, ei);
        evaluate_space(pos, BLACK, ei);
    }
  }
will not be executed because ei.mi->space_weight() is I think indeterminate, the value is to be decided by the compiler because undefined so it is maybe not even certain that it is zero?

Was this intentional? Is the code then left as it is because for further experimentation you might want to use 'space' again, or is it maybe a bug that it is not working now? Because I would have at least expected some comments in the code...
If it is not working, it is a bug, but I cannot reproduce it. Changing the value of the "Space" UCI parameter does have an effect on the evaluations and node counts here...

Tord

Okay, thanks Tord, I see now where I did not follow the code!

After

Code: Select all


class MaterialInfo {

  friend class MaterialInfoTable;

public:
  Value mg_value() const;
  Value eg_value() const;
  ScaleFactor scale_factor(const Position& pos, Color c) const;
  int space_weight() const;
  bool specialized_eval_exists() const;
  Value evaluate(const Position& pos) const;

comes

Code: Select all

private:
  void clear();

  Key key;
  int16_t mgValue;
  int16_t egValue;
  uint8_t factor[2];
  EndgameEvaluationFunctionBase* evaluationFunction;
  EndgameScalingFunctionBase* scalingFunction[2];
  int spaceWeight;
};

and I did not understand these as essentially concerning the same variables so for me space_weight seemed a different variable than spaceWeight as used in material.cpp. Then with the chosen testposition unfortunately this is so far in the middlegame/endgame you see very little difference from another spaceWeight value on the output, but the difference is still there at long timecontrols, if just a minute difference:

6k1/p2pp2p/bp4n1/q1r4R/1RP1P3/2P2B2/P2Q2P1/4K3 w - -

Engine: Stockfish 1.3.1 JA (64 MB)
by Tord Romstad, Marco Costalba

2.00 0:00 +2.43 1.Rxc5 Qxc5 2.Qxd7 Bxc4 3.Qxa7 (854) 9

3.00 0:00 +2.43 1.Rxc5 Qxc5 2.Qxd7 Bxc4 3.Qxa7 (1.247) 13

4.00 0:00 +1.96 1.Rxc5 Qxc5 2.Qxd7 Bxc4 3.Qxa7 Qe3+
4.Kd1 (2.750) 25

5.00 0:00 +1.86 1.Rxc5 Qxc5 2.Qxd7 Bxc4 3.Qd4 Qxd4
4.cxd4 Bxa2 (6.453) 58

6.00 0:00 +1.86 1.Rxc5 Qxc5 2.Qxd7 Bxc4 3.Qd4 Qxd4
4.cxd4 Bxa2 (12.891) 103

7.00 0:00 +2.05 1.Rxc5 (17.926) 143

8.00 0:00 +1.94 1.Rxc5 Qxc5 2.Qxd7 Ne5 3.Qd5+ Qxd5
4.cxd5 Nd3+ 5.Kd2 Nxb4 6.cxb4 Kf7
7.Bg4 (55.812) 296

9.00 0:00 +1.84 1.Rxc5 bxc5 2.Rb8+ Kg7 3.Be2 Qc7
4.Ra8 Qg3+ 5.Kd1 Bb7 6.Rxa7 Bxe4
7.Rxd7 Qxg2 (183.908) 490

9.00 0:00 +1.92 1.Rd5 Rxd5 2.Qxd5+ Qxd5 3.cxd5 Ne5
4.Be2 Bxe2 5.Kxe2 Kf7 6.Rb1 d6
7.Rf1+ Kg6 (247.249) 527

10.00 0:00 +1.92 1.Rd5 Rxd5 2.Qxd5+ Qxd5 3.cxd5 Ne5
4.Be2 Bxe2 5.Kxe2 Kf7 6.Rb1 d6
7.Rf1+ Kg6 (321.340) 555

11.00 0:00 +1.96 1.Rd5 Rxd5 2.Qxd5+ Qxd5 3.cxd5 Ne5
4.Be2 Bxe2 5.Kxe2 Kf7 6.Rb1 d6
7.Rf1+ Kg6 8.Ke3 (504.901) 609

12.01 0:02 +1.98 1.Rd5 Rxd5 2.exd5 Bb7 3.Bg4 Bc8
4.Kf1 Qc5 5.g3 Ne5 6.Qg5+ Ng6 7.Qf5 Ba6 (1.377.381) 662

13.01 0:04 +2.00 1.Rd5 Rxd5 2.exd5 Bc8 3.Be4 Qc5
4.Qf2 Qc7 5.Ra4 a6 6.Kd2 Bb7 7.Rb4 Ne5
8.Qg3+ Kf8 (3.093.727) 682

14.01 0:09 +2.05 1.Rd5 Rxd5 2.exd5 Bc8 3.Be4 Qc5
4.Qf2 Qc7 5.Ra4 Qe5 6.Qd4 a5 7.c5 Qg3+
8.Kd2 Qf4+ 9.Qe3 (6.525.598) 698

15.01 0:15 +2.00 1.Rd5 Rxd5 2.exd5 Bc8 3.Be4 Qc5
4.Qf2 Qc7 5.Kd2 Ba6 6.Bd3 Qe5 7.Qf5 Qxf5
8.Bxf5 Ne5 9.Bd3 (10.587.167) 699

16.01 0:30 +2.07 1.Rd5 Rxd5 2.exd5 Bc8 3.Be4 Qc5
4.Qf2 Qc7 5.Kd2 Ba6 6.Bd3 Bb7 7.Qe3 Qh2
8.Qg5 Qe5 9.Qxe5 Nxe5 (21.137.551) 695

17.01 1:40 +2.11 1.Rd5 Bc8 2.Bd1 Rxd5 3.Qxd5+ Qxd5
4.cxd5 Ne5 5.Be2 d6 6.Kd2 Bg4 7.Bxg4 Nxg4
8.Rb1 Ne5 9.Ke3 Kf7 10.Rf1+ Kg6
11.Kd4 (69.931.756) 692

18.01 2:45 +1.92 1.Rd5 d6 (114.148.674) 691

19.01 6:33 +2.07 1.Rd5 d6 2.Bd1 Rxd5 3.Qxd5+ Qxd5
4.exd5 Ne5 5.Be2 Nd7 6.Kd2 Kf7 7.Bd3 h6
8.Rb1 Ne5 9.Rf1+ Ke8 10.Rf4 Bc8
11.Ke3 Bg4 (271.311.667) 689

best move: Rh5-d5 time: 7:39.875 min n/s: 685.686 nodes: 315.330.100

and with Space at 200 only the nodenumbers at 18 ply start to diverge:

6k1/p2pp2p/bp4n1/q1r4R/1RP1P3/2P2B2/P2Q2P1/4K3 w - -

Engine: Stockfish 1.3.1 JA Sp200 (64 MB)
by Tord Romstad, Marco Costalba

2.00 0:00 +2.43 1.Rxc5 Qxc5 2.Qxd7 Bxc4 3.Qxa7 (854) 13

3.00 0:00 +2.43 1.Rxc5 Qxc5 2.Qxd7 Bxc4 3.Qxa7 (1.247) 19

4.00 0:00 +1.96 1.Rxc5 Qxc5 2.Qxd7 Bxc4 3.Qxa7 Qe3+
4.Kd1 (2.750) 43

5.00 0:00 +1.86 1.Rxc5 Qxc5 2.Qxd7 Bxc4 3.Qd4 Qxd4
4.cxd4 Bxa2 (6.453) 81

6.00 0:00 +1.86 1.Rxc5 Qxc5 2.Qxd7 Bxc4 3.Qd4 Qxd4
4.cxd4 Bxa2 (12.891) 163

7.00 0:00 +2.05 1.Rxc5 (17.926) 190

8.00 0:00 +1.94 1.Rxc5 Qxc5 2.Qxd7 Ne5 3.Qd5+ Qxd5
4.cxd5 Nd3+ 5.Kd2 Nxb4 6.cxb4 Kf7
7.Bg4 (55.812) 395

9.00 0:00 +1.84 1.Rxc5 bxc5 2.Rb8+ Kg7 3.Be2 Qc7
4.Ra8 Qg3+ 5.Kd1 Bb7 6.Rxa7 Bxe4
7.Rxd7 Qxg2 (183.908) 558

9.00 0:00 +1.92 1.Rd5 Rxd5 2.Qxd5+ Qxd5 3.cxd5 Ne5
4.Be2 Bxe2 5.Kxe2 Kf7 6.Rb1 d6
7.Rf1+ Kg6 (247.249) 585

10.00 0:00 +1.92 1.Rd5 Rxd5 2.Qxd5+ Qxd5 3.cxd5 Ne5
4.Be2 Bxe2 5.Kxe2 Kf7 6.Rb1 d6
7.Rf1+ Kg6 (321.340) 604

11.00 0:00 +1.96 1.Rd5 Rxd5 2.Qxd5+ Qxd5 3.cxd5 Ne5
4.Be2 Bxe2 5.Kxe2 Kf7 6.Rb1 d6
7.Rf1+ Kg6 8.Ke3 (504.901) 645

12.01 0:02 +1.98 1.Rd5 Rxd5 2.exd5 Bb7 3.Bg4 Bc8
4.Kf1 Qc5 5.g3 Ne5 6.Qg5+ Ng6 7.Qf5 Ba6 (1.377.381) 683

13.01 0:04 +2.00 1.Rd5 Rxd5 2.exd5 Bc8 3.Be4 Qc5
4.Qf2 Qc7 5.Ra4 a6 6.Kd2 Bb7 7.Rb4 Ne5
8.Qg3+ Kf8 (3.093.727) 692

14.01 0:09 +2.05 1.Rd5 Rxd5 2.exd5 Bc8 3.Be4 Qc5
4.Qf2 Qc7 5.Ra4 Qe5 6.Qd4 a5 7.c5 Qg3+
8.Kd2 Qf4+ 9.Qe3 (6.525.598) 705

15.01 0:15 +2.00 1.Rd5 Rxd5 2.exd5 Bc8 3.Be4 Qc5
4.Qf2 Qc7 5.Kd2 Ba6 6.Bd3 Qe5 7.Qf5 Qxf5
8.Bxf5 Ne5 9.Bd3 (10.587.167) 704

16.01 0:30 +2.07 1.Rd5 Rxd5 2.exd5 Bc8 3.Be4 Qc5
4.Qf2 Qc7 5.Kd2 Ba6 6.Bd3 Bb7 7.Qe3 Qh2
8.Qg5 Qe5 9.Qxe5 Nxe5 (21.137.551) 700

17.01 1:40 +2.11 1.Rd5 Bc8 2.Bd1 Rxd5 3.Qxd5+ Qxd5
4.cxd5 Ne5 5.Be2 d6 6.Kd2 Bg4 7.Bxg4 Nxg4
8.Rb1 Ne5 9.Ke3 Kf7 10.Rf1+ Kg6
11.Kd4 (69.931.756) 698

18.01 2:43 +1.92 1.Rd5 d6 (114.148.460) 697

19.01 6:33 +2.07 1.Rd5 d6 2.Bd1 Rxd5 3.Qxd5+ Qxd5
4.exd5 Ne5 5.Be2 Nd7 6.Kd2 Kf7 7.Bd3 h6
8.Rb1 Ne5 9.Rf1+ Ke8 10.Rf4 Bc8
11.Ke3 Bg4 (271.311.447) 689

20.01 10:38 +2.07 1.Rd5 d6 2.Bd1 Rxd5 3.Qxd5+ Qxd5
4.exd5 Ne5 5.Be2 Nd7 6.Kd2 Kf7 7.Bd3 h6
8.Rb1 Ne5 9.Rf1+ Ke8 10.Rf4 Bc8
11.Ke3 Bg4 12.Kd4 (438.509.002) 687

21.01 20:52 +2.01 1.Rd5 d6 2.Bd1 Rxd5 3.Qxd5+ Qxd5
4.exd5 Ne5 5.Be2 Bc8 6.Rb3 Kf7 7.Ra3 a5
8.Rb3 Ba6 9.Rxb6 Bxc4 10.Bxc4 Nxc4
11.Rb5 Kf6 12.Ke2 Ke5 (858.738.829) 685

Thanks for clearing that up Tord! I am building a function that is doing about the same as evaluate_space but not just behind the own pawns in the opening or middle game, it is supposed to say something about control over squares, hopefully it should say something useful, more at the transition from middlegame to endgame. But then I thought my "template" for the code, evaluate_space did not really work at all anymore

But it really does work

New function is not finished yet, I'll post it later, probably it should be called evaluate_board_control or something like that.

I was thinking about also using see(), for calculating 'control' over squares that are attacked by both sides, but I always fear that this is a much too costly function to use for many squares. I am surprised see() can be used for passed pawns for instance without becoming a major burden on the computing times. Just will have to try somethings

and stop when I think Glaurung's code is broken again beyond my ability to repair!

Regards, Eelco

Impressive Stockfish 1.4 !!

Re: Impressive Stockfish 1.4 !!

Re: Impressive Stockfish 1.4 !!