Всех приветствую. Это первая тема, созданная мной на таком сервере. Немного умею программировать, имею также поверхностные знания в области исследования операций с оптимизацией в настоящий момент с предложением доработки программного обеспечения и запуском сервера, который позволит эксплуатировать 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)