https://forumupload.ru/uploads/0014/11/ca/611/t477575.png
Всех приветствую. Это первая тема, созданная мной на таком сервере. Немного умею программировать, имею также поверхностные знания в области исследования операций с оптимизацией в настоящий момент с предложением доработки программного обеспечения и запуском сервера, который позволит эксплуатировать stockfish v.15.1 на полную катушку, возможно, даже с выводом некоторых закономерностей игры: игра всё-таки имеет и поле, и движение фигур, и в какой-то степени представима в виде графа (направленный или же ненаправленный - это уже отдельный вопрос), и соответственно, каждое поле можно оценивать с позиции количества фигур, нацеленных на него с целью получения наилучшего размена.
Да, действительно в настоящий момент stockfish и другие подобные программы прекрасно справляются со своей работой, но... Вопрос связан с каждым полуходом, а именно: насколько каждый последующий полуход ожидаем. И прочими вопросами.
И цель предложения - совместная доработка stockfish для автоматизации поиска наилучших решений по темпам, с учётом особенностей оценки и позиции, и материала шахматистом.
Предполагаю, что большинству всё же известен либо английский, либо же немецкий язык и в состоянии перевести текст во вложении.
Вопрос! Товарищи шахматисты, вам интересна тема доработки программного обеспечения и последующего его применения? Кто готов к сотрудничеству?
Если желаете инкогнито, то адрес моей электронной почты - excel8@ya.ru.
Мой интерес - это bona fide и получение удовольствия от решения оптимизационных задач, к коим относятся, по моему разумению, и шахматы.

------
Или же ещё выдержка из кода. Просто посмотрите на текст.
namespace Stockfish::Material {

/// Material::Entry contains various information about a material configuration.
/// It contains a material imbalance evaluation, a function pointer to a special
/// endgame evaluation function (which in most cases is NULL, meaning that the
/// standard evaluation function will be used), and scale factors.
///
/// The scale factors are used to scale the evaluation score up or down. For
/// instance, in KRB vs KR endgames, the score is scaled down by a factor of 4,
/// which will result in scores of absolute value less than one pawn.

struct Entry {

  Score imbalance() const { return score; }
  Phase game_phase() const { return (Phase)gamePhase; }
  bool specialized_eval_exists() const { return evaluationFunction != nullptr; }
  Value evaluate(const Position& pos) const { return (*evaluationFunction)(pos); }

  // scale_factor() takes a position and a color as input and returns a scale factor
  // for the given color. We have to provide the position in addition to the color
  // because the scale factor may also be a function which should be applied to
  // the position. For instance, in KBP vs K endgames, the scaling function looks
  // for rook pawns and wrong-colored bishops.
  ScaleFactor scale_factor(const Position& pos, Color c) const {
    ScaleFactor sf = scalingFunction[c] ? (*scalingFunction[c])(pos)
                                        :  SCALE_FACTOR_NONE;
    return sf != SCALE_FACTOR_NONE ? sf : ScaleFactor(factor[c]);
  }

  Key key;
  const EndgameBase<Value>* evaluationFunction;
  const EndgameBase<ScaleFactor>* scalingFunction[COLOR_NB]; // Could be one for each
                                                             // side (e.g. KPKP, KBPsK)
  Score score;
  int16_t gamePhase;
  uint8_t factor[COLOR_NB];
};

typedef HashTable<Entry, 8192> Table;

Entry* probe(const Position& pos);

Отредактировано Спартак (2023-02-06 00:18:18)