"It must be a clone of some sort..."

[chrisw]

So, my question: does that mean that these engines lack integrity?

Let's start with all of those methods being well known for years, and nobody owns them.
So my answer is this:
If you achieved any of those goals while violating the license agreement of any code then you lack integrity.
If you read the code written by others, understood it, and wrote your own version, there is nothing wrong with that[*]

[*] though others would beg to differ. I have found that chess programmers are very jealous about their evaluation function, despite the fact that each and every term in their program was learned from chess books, chess experts, and chess programming articles.

Well that’s not universally true. Some chess programmers (few only maybe) are chess “experts” in their own right.

Personally, I do not see using ideas as wrong at all, but I suppose that at some point if you are just echoing the work of others it seems to lack creativity to me.

[Dann Corbit]

Well that’s not universally true. Some chess programmers (few only maybe) are chess “experts” in their own right

Quite right, and clearly you and Miguel are in that category. We also have the Komodo team with a GM helping to design the eval function (and I would call him the father of the material imbalance idea in eval, or at least the one who made the idea famous with his paper on the topic). But even then, for the most part, the experts just don't have to use a book because the information is already in their heads. But almost every evaluation construct is already very well known.

[mvanthoor]

...the experts just don't have to use a book because the information is already in their heads. But almost every evaluation construct is already very well known.

Well, I don't know a lot about the evaluation function, but I'm a reasonable chess player. My OTB ELO rating was about 1850 in my teens, with peaks up to 2000; the reason for not reaching higher ratings is because I'm too lazy to study, and I'm really bad at both opening and endgame theory

Still, I do know most best practices and so-called proverbs, and I'm certain I can design a reasonable evaluation function using that information. I also have the inclination to play very tactical chess, so I'm sure something like that will come through in the evaluation in my engine.

[OliverBr]

Well, I don't know a lot about the evaluation function, but I'm a reasonable chess player. My OTB ELO rating was about 1850 in my teens, with peaks up to 2000; the reason for not reaching higher ratings is because I'm too lazy to study, and I'm really bad at both opening and endgame theory

Oh, this is much, much better than me.

If you're honest, what is *your* reaction to a new engine that gets onto the scene and starts out at 3000+ ELO?

It's another clone.

I am fighting for over 20 years to improve my engine and it's 2700, optimistically. It will never ever get 3000 (unless I start cloning), I am very happy to beat Fruit and Glaurung on a regular base.
They are no clones.

[chrisw]

Well that’s not universally true. Some chess programmers (few only maybe) are chess “experts” in their own right

Quite right, and clearly you and Miguel are in that category. We also have the Komodo team with a GM helping to design the eval function (and I would call him the father of the material imbalance idea in eval, or at least the one who made the idea famous with his paper on the topic). But even then, for the most part, the experts just don't have to use a book because the information is already in their heads. But almost every evaluation construct is already very well known.

An awful lot of tosh is talked about “material imbalance”, like this is some kind of major breakthrough discovery. That we ascribe relative values to each piece type isn’t a breakthrough. Nor that relative values change depending. Nor that bishop pair etc. Nor knights on edge, Général PSQT and bla bla. Realising that QRB cooperate well, better than QRN, but that QN works better together than QB in king attack is maybe a little deeper, and relative values of minor pieces depending structure and holes, but really all/most of these factors have been accounted in polynomial eval functions since whenever. Only now you don’t even have to bother, a texel tuner plus game phase will discover all these relative values for you, all you need do is identify them as features in the code, tuner does the rest. There is some quadratic material code in SF but nobody I’ve read knows how it works, and several people have tried to get it to work elsewhere and failed. Result is other open sources I searched doesn’t even include it. Does the SF one actually do anything? Good question.
Basically “material imbalance” is a fancy term for a feature than isnt directly designed and coded, it just emerges out of all the various positional tweaks that all hand crafted evals have. Well, I’ld like it to be proved otherwise, but, comp chess wiki woffle on the topic notwithstanding, not seen it yet.

[Dann Corbit]

Well, I don't know a lot about the evaluation function, but I'm a reasonable chess player. My OTB ELO rating was about 1850 in my teens, with peaks up to 2000; the reason for not reaching higher ratings is because I'm too lazy to study, and I'm really bad at both opening and endgame theory

Oh, this is much, much better than me.

If you're honest, what is *your* reaction to a new engine that gets onto the scene and starts out at 3000+ ELO?

It's another clone.

I am fighting for over 20 years to improve my engine and it's 2700, optimistically. It will never ever get 3000 (unless I start cloning), I am very happy to beat Fruit and Glaurung on a regular base.
They are no clones.

SMP would add a ton, and lazySMP is pretty simple. I guess on my AMD 3790x, it would be 170 Elo stronger if SMP. That would put it at 2870, and I think you could add 30 more.
S0 3000 Elo is just around the corner. Not for one thread, but everyone is on the LazySMP bandwagon today. I thank Dan Homan for that. He may not be the inventor, but he definitely got the ball rolling on actual usage.

[OliverBr]

SMP would add a ton, and lazySMP is pretty simple. I guess on my AMD 3790x, it would be 170 Elo stronger if SMP. That would put it at 2870.

It's a good idea.
Unfortunately it's not that easy, because I am testing against other engines. And if OlIThink gets 4 Threads, other get them, too and there is the same result as before.
Furthermore test results need more time, because there will be less concurrent games and I am not a very patient person

There may be some potential in here: http://talkchess.com/forum3/viewtopic.p ... 09#p861809

[JohnWoe]

I think most programmers are just copy editors. I don't have any fucking clue of how Stockfish works. It could as well be written by GPT-3. I could fizzle some numbers/add some log(sqrt(... to gain +0.1 ELO. To drop in NNUE to your engine you need to basically copy-paste everything. As it updates those input weights on the fly. You need to give Position as a parameter etc. It needs Color enums etc... I don't have make()/unmake() functions nor class Position.

Speaking about NN. Feed forward is pretty "straightforward". It's just f(f(f(f(... But back propagation is another story. As you need derivation for each and every weight (w1/w2...) to minimize error.

[mvanthoor]

An awful lot of tosh is talked about “material imbalance”, like this is some kind of major breakthrough discovery.

The reason why many people like materially imbalanced games (3 pawns against a knight, a queen against a rook, knight and pawn, a queen against three minor pieces) is the fact that this often makes games more interesting. Grandmasters sometimes create such an imbalance on intuition; in a chess engine, it's hard to do this because material has such a great weight. A pawn is worth 100 cp, for example. If an engine has settings like:

queen 925
rook 500
bishop 300
knight 280
pawn 100

Then a rook + knight + pawn = 880. The difference therefore is 45 cp advantage for the queen. Very often, positional factors only weigh in form 5, 10, or 20 cp, so you will need many (possibly even 5) positional advantage to overcome this. An evaluation function has to be almost created on purpose with lots of positional knowledge (and carefully chosen piece weights) to be able to create these imbalances. One engine that can do this is HIARCS.

[jorose]

It would not be to difficult to add a lot of ideas from Stockfish and add NNUE evaluation to pimp it up 100 or 200 Elo, but I simply don't want to do this because it would give me the feeling that it is not my own engine anymore.

There is a word for this. I believe it is called "integrity."

This is an interesting answer Dann but I have a question: if we take a look at the sources of the top open source engines from CCRL or CEGT rating lists, we will see that the search function of every one of them is basically taken from Stockfish with some params tuning. We have, in the same order: Razoring, Reverse Futility Pruning, Null Move Pruning with Verification, ProbCut. Inside the moves loop: Late Move Pruning, Futility Pruning, SEE Pruning, Singular Extension, Late Move Reduction and so on. All with more or less the same implementation details, also for ProbCut for which papers have been published several years ago but everyone does it the Stockfish way. If we had a similarity tester for the search function, I believe we would have a similarity much higher than 70%.

So, my question: does that mean that these engines lack integrity?

Few months ago, I opened a thread asking what we were allowed to learn/take from open source engines (basically Stockfish since it's the strongest one) and I used the Singular Extension as example since that was the algorithm I was toying with at the time. In the end, I decided not to use it because I couldn't find an implementation different enough from SF's one that wasn't significantly weaker. If I had implemented SE the Stockfish way just to gain ELO points, then probably I would have went on taking things here and there and my engine wouldn't have been mine anymore. So, I prefer it to be relatively weak and to try new things. If my search was like everyone's else, I think the probability to find something new that works would be much lower.

I suppose Winter might not be considered a top engine, but I think its an interesting experiment.

Razoring: Not in Winter

Reverse Futility Pruning:
SF:

Code: Select all

    // Step 8. Futility pruning: child node (~50 Elo)
    if (   !PvNode
        &&  depth < 8
        &&  eval - futility_margin(depth, improving) >= beta
        &&  eval < VALUE_KNOWN_WIN) // Do not return unproven wins
        return eval;

Winter:

Code: Select all

    //Static Null Move Pruning
    if (node_type == NodeType::kNW && depth <= 5) {
      NScore margin = (kSNMPMargin - 60 * !strict_worsening) * depth;
      if (settings::kUseScoreBasedPruning && static_eval.value() > beta.value() + margin
          && t.board.get_phase() > 1 * piece_phases[kQueen]) {
        return beta;
      }
    }

In case you are wondering about the value() function, this is because Winter's scores are WDL scores, so we need to transform them into a scalar in order to be able to use margins more nicely.

Null Move Pruning with Verification: Winter does not do Null Move Verification. SF also has a ton of weird stats related restrictions that I haven't analyzed. Winter's implementation is very straightforward.

SF: https://github.com/official-stockfish/S ... h.cpp#L818
Winter:

Code: Select all

    //Null Move Pruning
    if (static_eval >= beta && is_null_move_allowed(t.board, depth)) {
      t.set_move(kNullMove);
      t.board.Make(kNullMove);
      const Depth R = 3 + depth / 5;
      Score score = -AlphaBeta<NodeType::kNW, Mode>(t, -beta, -alpha,
                                    depth - R, !expected_cut_node);
      t.board.UnMake();
      if (score >= beta) {
        return score;
      }
    }

ProbCut: Not in Winter

Late Move Reduction, Late Move Pruning, Futility Pruning: Winter has all of these.

SF LMR and LMP:

Code: Select all

          // Skip quiet moves if movecount exceeds our FutilityMoveCount threshold
          moveCountPruning = moveCount >= futility_move_count(improving, depth);

          // Reduced depth of the next LMR search
          int lmrDepth = std::max(newDepth - reduction(improving, depth, moveCount), 0);

SF Futility:

Code: Select all

              // Futility pruning: parent node (~5 Elo)
              if (   lmrDepth < 7
                  && !ss->inCheck
                  && ss->staticEval + 283 + 170 * lmrDepth <= alpha
                  &&  (*contHist[0])[movedPiece][to_sq(move)]
                    + (*contHist[1])[movedPiece][to_sq(move)]
                    + (*contHist[3])[movedPiece][to_sq(move)]
                    + (*contHist[5])[movedPiece][to_sq(move)] / 2 < 27376)
                  continue;

Winter:

Code: Select all

    if (i && !in_check && !(checking_squares[GetPieceType(t.board.get_piece(GetMoveSource(move)))]
                              & GetSquareBitBoard(GetMoveDestination(move)))) {
      //Late Move Pruning
      assert(depth > 0);
      if ((size_t)depth < kLMP[0].size() && (i >= (size_t)kLMP[node_type == NodeType::kPV][depth])
          && GetMoveType(move) < kEnPassant) {
        continue;
      }

      //Late Move Reduction factor
      reduction = get_lmr_reduction<node_type>(depth, i, GetMoveType(move) > kDoublePawnMove);
      assert(reduction < depth);

      //Futility Pruning
      if (node_type == NodeType::kNW && settings::kUseScoreBasedPruning
          && depth - reduction <= 3
          && static_eval.value() < (alpha.value() - get_futility_margin(depth - reduction, !strict_worsening))
          && GetMoveType(move) < kEnPassant) {
        continue;
      }
    }

Note the GetMoveType(move) > kDoublePawnMove checks returns whether a move is forcing.

SEE Pruning: Not in Winter's AB search. I do SEE pruning in QSearch though.
Singular Extension: Winter does Singular extension.
SF: https://github.com/official-stockfish/S ... .cpp#L1069
Winter:

Code: Select all

    Depth e = 0;// Extensions
    if (i == 0 && depth >= settings::kSingularExtensionDepth && valid_entry
        && entry.depth >= depth - 3 && !(node_type == NodeType::kPV && moves.size() == 1)
        && entry.get_bound() != kUpperBound && entry.get_score(t.board).is_static_eval()
        && get_singular_beta(entry.get_score(t.board), depth) > kMinStaticEval) {
      SortMovesML(moves, t, tt_entry);
      moves_sorted = true;
      auto is_singular = move_is_singular(t, depth, moves, entry, expected_cut_node);
      if (is_singular.first) {
        e = 1;
      }
      else if (expected_cut_node && is_singular.second >= beta) {
        return is_singular.second;
      }
    }

I could go into more detail, but honestly this post took long enough due to having to find where things are located in SF. Both programs are open source and I can gladly direct you through Winter's code if there is anything you want to see.

While I think there are definitely a lot of similarities in Winter and SF, I do think there are also a lot of differences. I'll let you make up your own mind if you feel Winter search is original. I also haven't really compared with any of the other engines around that level, so I couldn't tell you how similar they are or how different.