Набежали спамеры, неврозможно провести семинар. Сейчас в моменте не успеваю разобраться как включить модерацию. Переносим на неделю.

#мысль
Декларативное против императивного.

Поймал тут одну важную мысль.
Языки описания мат моделей для ЦЛП по сути своей декларативные. Это очень крутая, но контринтуитивная штука.
С одной стороны тебе надо просто задать "что" ты хочешь получить, а не "как". И это очень здорово так как алгоритм на базе ЛП более гибкий, Если ты сделал алгоритм/эвристику с конкретным "как" делать, то как только у заказчика изменится обстановка, алгоритм придется переделывать. Скажем высокий сезон прошел и пошел низкий. Конкретный алгоритм так же плохо обобщается. А в ЛП с этим всем красота и благодать.

Но при этом люди не отделяют "что" от "как". Постоянно в ТЗ заказчики занимаются прямым руко-водстмом. Объясняют как делать ту или иную штуку.
Заказчики ладно, им можно. А вот исполнитель хороший, который работает с солверами, должен уметь разделять.

Если неверно сформулировать что ты хочешь, то солвер и начинает вести себя как джинн из анекдотов, или как ленивый школьник, который формально сделал задачу, а по существу нет.

Более менее измеримых вещей которые можно сделать я тут вижу две:

1. Думать и осознавать что написание целевой функции для солвера это важная часть работы, чуть ли не главная. Все остальное это просто формальная корректность или оптимизация скорости.
2. Чтобы понять правильно ли сформулирована ЦФ, надо подумать какое солвер может найти максимально бесполезное решение с заданной ЦФ.


Еще небольшое упражнение на различения декларативного и императивного стиля работы.
Какая из этих фраз в каком стиле сформулирована:

1. Копай отсюда и до обеда.
2. Я хочу чтобы все унитазы к вечеру блестели.

Приехал в Екатеринбург общаться с коллегами/партнерами. Очень полезно общаться в живую. Уже доволен результатами. Осталось только получить клиента с живыми деньгами

Вчера в NoML был отличный доклад Виталия Черненко из Амальгамы про оптимизацию молочного завода.
Он не использовал ЦЛП, а вместо этого просто делал перебор.
А в остальном его подход прямо совпадает с моим.
Отмечу ряд фишек на которые я обратил внимание и полностью поддерживаю:

1. На этапе прототипа надо рассматривать самое сложное а не простое. Я это называю принципом Ильи Муромца, позже напишу пост.
2. Язык описания данных не должен просачиваться в модель. Между ними надо делать переходник и дальше делать с моделью, что тебе удобно. В одном проекте не стал так делать, и до сих пор огребаю.
3. Если по какой-то установке не надо принимать решения, то она выкидывается из модели. Например труба. Даже если решение есть, например что качать некоторым насосом, то чуть чуть загрубив задачу мы от этого можем избавиться, то это надо смело выкидывать из модели.
4. Заказчику надо делать визуализацию в его формате, а уже потом переходить на правильный. Они уже привыкли и сходу в своем формате все видят. И он может оказаться в чем то и правильней.
5. Абсолютно правильные рассуждения против комбинаторного взрыва. Надо понимать какие решения ключевые и выбирать сначала их варианты а потом все выстраивать вокруг.
6. Тесты

Насчет ЦЛП против перебора. Главное, что победителей не судят. Я видел аналогичные проекты, которые делались подобным подходом и проваливались.
Здесь перебора хватило и прекрасно. CP кажется здесь лучше должен подходить прямого перебора и ЦЛП.

Кажется, что докладчик местами переизобрел велосипед и мог бы воспользоваться готовыми библиотеками, чтобы скажем организовать перебор. Но это просто экономия 10-20% времени проекта, а не рисков. И главное, что проект сделан. И здесь вопрос просто в том, к чему человек привык.

Я бы его все равно бы стал делать при помощи ЦЛП, скорее всего мне было бы легче с перебором, но было бы сложнее с интервалами времени.
Но сложность задачи на глаз такая, что я тоже скорее всего сделал бы. Прямо сейчас сдаем ЦЛП алгоритм для завода с большим числом SKU с более разнообразными заморочками. Правда у нас со временем попроще.

Самое главное, что многие, кто решают задачу тем или иным методом не смотрят в суть, а тут человек именно, что смотрел в суть задачи.
Главный водораздел на мой взгляд именно в этом, а не в том, каким методом решалась задача.

Запись семинара

Виталий Черненко (Амальгама), Практическое применение комбинаторной оптимизации на примере задачи планирования молочного завода. YouTube | Дзен | RuTube (~1 час 25 минут).

Пробуем провести доклад, который сорвался на прошлой неделе.
Доклад будет сегодня 28.11.2025 в 16.00 по Москве.

Ссылка на подключение
https://telemost.360.yandex.ru/j/3763851219

Будет комната ожидания для защиты от спама. Пишите пожалуйста полные имена при подключении и отметьтесь в комментариях.


🎓 Метод Branch and Cut: в теории и на практике

Метод ветвей и границ не является панацеей при решении задач дискретной оптимизации.
Современным солверам приходится пользоваться миксом из различными подходов, чтобы быть эффективными.
В ходе доклада мы разберём метод Cutting Plane, который часто применяют вместе с методом ветвей и границ. Эту связку и называют Branch and Cut.

🔹 Мы напомним всю необходимую информацию из предыдущих докладов про LP и Branch and Bound
🔹 Разберем основу метода Cutting Plane, а именно добавление новых ограничений, которые упрощают решение задачи
🔹 Рассмотрим различные способы как генерировать эти ограничения (каты), а также управлять ими
🔹 Приоткроем завесу черного ящика, а именно воспользуемся API солвера SCIP, чтобы собственными глазами посмотреть на добавляемые каты

Начинаем через 4 минуты. https://telemost.360.yandex.ru/j/3763851219

#текучка
Искал телеграм-каналы порекламироваться. Один канал отказался рекламу давать, в результате познакомился с интегратором, у них есть в целом свой отдел математиков оптимизаторов, но знакомство все равно не помешает.
Забавный вариант достучаться :) лучше чем через linkedin.

Еще нанял пиарщиков, чтобы системно заниматься продвижением. Посмотрим, что получится.

Проводил касдев с потенциальным заказчиком по одному потенциальном продукту и возникла дилемма. Делать пилот бесплатно или за деньги.
И то и другое имеет минусы.

С одной стороны люди плохо фильтруют настоящие и не настоящие проблемы. Настоящие это только те, за которые люди готовы платить денег.
Это даже в моей истории было, мы обсуждаем очень важную фичу. После вопроса - сколько вы за нее готовы заплатить, заказчик сливался. Даже 10к в месяц был не готов ))

Так что очень важно брать денег за фичу. По этой же причине котят продают хотя бы за 1 рубль, а не дарят.

С другой стороны, назвав цену ты ее фиксируешь и переходишь в формат товарно -денежных отношений.
Дальше продукт будут улучшаться, а цену поднимать будет сложнее, она уже застрянет в головах.

Была история с одним садиком, где ввели штрафы за опоздание родителей. После чего родители стали опаздывать даже чаще.
Моральное неудобство было дороже родителям чем деньги.

#мысль

Принцип Ильи Муромца.

Илья Муромец, когда стоял у камня выбрал дорогу ведущую к смерти. Опасный путь, зато решает проблему.

Сложные проекты начинаются с прототипа. Прототип должен быть упрощенной версией основной задачи, и написание прототипа должно отвечать на вопрос:
Можно ли сделать этим методом задачу или нет?

Как правильно выбрать какие фичи писать в прототипе, а какие нет? А вот про принципу Ильи Муромца.
Надо выбирать самые сложные фичи, а простые и рутинные игнорировать.

Видел как один проект умер из-за того, что было сделано планирование отдельного предприятия, но застряли при планировании одновременной работы нескольких предприятий. Если бы в прототипе была сразу заложена эта функциональность, проект можно было и сделать.

Вообще смысл прототипа - если проект провалится, то лучше именно на этапе прототипа.

P.S. У японцев есть подходящий и более звучный термин бусидо. Но хочется стащить идею у японцев, как в свое время стащили идею матрешки.

Никто еще не начал делать русский роблокс ?

#семинар
Сделали запись доклада про Branch&Cut от 28 ноября.
Рутюб/Ютюб

В древние времена научные знания было сильно сложнее применять, но тоже было можно, и иногда получалось очень эффектно.
У меня собралась забавная подборка (честно скажу, что все пункты, кроме первого - мои спекуляции).


1. (астрономия) Христофор Колумб и затмение на Ямайке (1504 г.)

- Во время четвёртого путешествия Колумб оказался на Ямайке, где его команда страдала от нехватки продовольствия и конфликтов с местными племенами.

- Колумб знал из астрономических таблиц, что будет лунное затмение 29 февраля 1504 года.

- Он сказал местным жителям, что его Бог разгневан и «скроет Луну», если они не будут снабжать его людей пищей.

- Когда Луна начала исчезать, туземцы в панике согласились помогать, а Колумб «вернул» Луну, когда затмение закончилось

2. (химия) Есть эффектный химический эксперимент под названием фараонова змея. Когда при поджоге определенного вещества из огня начинают вылазить змеи. Очень легко представить, что жрецы фараона устраивали такие же представления что и Колумб.


3. (биология) Перед одной битвой римлян с галлами обе армии выставили по одному воину. Согласно легенде на шлем Римского воина Марка Валерия уселся ворон, который клевал и царапал лицо галла пока Марк его не убил.
Это оказало психологическое воздействие и римляне победили, Марк Валерий Корвинус стал шестикратным консулом Древнего Рима и одним из величайших правителей Рима, наряду с Камиллом Фурием, Сципионами 1 и 3, ну и Цезарем.

4. (физика). Камни как и все тела при нагревании расширяются. Если в валуне есть щель, то ее форма может меняться более хитрым способом, в том числе уменьшаться на нагревании камня. В результате получается такой камень, куда можно вставить ночью вставить легко железяку, а вытащить можно только рано утром, пока камень еще не нагрелся, а благородные люди еще спят.

Очень круто было перейти благодаря такому от монархии к теократической выборной монархии с "институцией перевоплощения" а ля Далай-лама.
И народу понравилось, легенды про меч в камне и короле Артуре до сих по слагают. Король из народа это все-таки мощная штука.

#текучка #мероприятия
Сегодня буду на Альфа-конфе, а завтра на конференции "Исскуственный интеллект эволюция бизнес-реальности".

Если кто там будет - давайте пересечемся!

Сделал когда-то доклад для WildTeam о том как устроен изнутри наш проект DeepWhale.
Наткнулся тут что есть видео и выложено в публичный доступ. Делюсь тут.
Про то, почему такие картиночки реально сложно рисовать, как мы это делаем и зачем они нужны
https://rutube.ru/video/d1fc66c043a0cd64226255090eaa22af/

https://www.kaggle.com/competitions/santa-2025/data

На каггл идет конкурс по плотнейшей упаковке ёлок в квадраты.
Это моя тема и как математика и как оптимизатора. И еще за похожую задачу взялся по работе. Так что попробую и в этом конкурсе поучаствовать. Хотя глубоко разбираться, чтобы дожать до призовых мест будет лень. Лучше уж научную статью тогда сделать.