#текучка #награды
Обещал выложить фотку с награждения дипломом. Вот выкладываю. А то спрашивают потенциальные заказчики имел ли я дело дело с ИИ.

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

Upd. На другом таки. Я заранее планировал, при оперативном планировании что-то поменяли

Программа как завод.
#алгоритмы #голдратт

После прочтения Голдратта и оптимизации несколько заводов я теперь везде эти заводы вижу.

В заводах есть сырье/материалы, полуфабрикаты и изделия и переделы между ними.

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

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


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

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

Правило остановки солвера.
#для_специалистов #mip

У всех MIP солверов есть ровно две стандартные опции для остановки расчета.
Предел времени (time limit) или достижение заданного отклонения от оценки снизу (gap), то есть найденое решение отличается от оптимального только на 1% скажем.
Если выставить оба параметра, то солвер останавливается по первому сработавшему правилу.

Скажите, кто из читателей тоже делает модельки, это только меня раздражает? 🤯

Если поставить gap то хороший и быстрый расчет останавливается и отдает неоптимальное решение.
А если не ставить, то он уходит в очень долгий расчет там, где уже есть достаточно хорошее решение.

Во-первых, это просто не красиво. А во вторых, если работа солвера является подзадачей более сложного алгоритма, то нужно правильно балансировать между качеством и скоростью работы и просто двух параметров time_limit mip_gap явно для этого не хватает. Неужели это только мне не хватает?

Я в старых проектах писал специальную обертку, в которую можно было задать gap как функцию от времени (монотонно растущую). Получалась более гибкая история, которая нам срезала в среднем процентов 50% времени. Писал для Гуроби когда у меня была лицензия, кажется снова придется писать для highs.

#текучка #воронка_продаж
Заключил договор на планирование крупного производства, не прошло и полгода. Уже и работа идет вовсю и заканчивать скоро 😄

ТРИЗ и ИКР (идеальный конечный результат).
#мысль #рецензия

Когда я был школьником была популярная тема ТРИЗ - теория решения изобретательских задач.
На мой взгляд реально правильная и крутая штука.
Основа теории - это ИКР, идеальный конечный результат. Надо сначала сформулировать то, что ты хочешь, отсеять, то что является частью решения а не идеального решения, а потом уже делать необходимый минимум.

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

Сейчас для меня идея ИКР стала очевидна. Я позже еще пост про это напишу.

Еще в ТРИЗ были чек-листы для именно изобретательской работы: нагреть охладить, собрать разобрать. пустить ток, положить в воду.
Мы уже не патенты пишем и не мастерим изделия. Так что из ТРИЗ реально полезна именно идея ИКР.



Напоследок приведу пример про физика Роберта Вуда. Он заказал пластинку из соли толщиной 1 миллиметр, ему сказали что могут выточить только 2 а дальше она хрупкая и тоньше не получится. Он поспорил, что сделает тоньше.
Вуд просто взял влажную тряпочку и стал протирать пластинку, и допротирал ее до толщины 1/4 миллиметра.

Школа Системного Мышления Анатолия Левенчука
#рецензия #системное_мышление
Есть такой очень интересный человек Анатолий Левенчук и он сделал школу системного мышления. Точнее теперь уже менеджмента.

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

Помимо ракет хорошим примером сложных систем являются биологические системы, я по этой причине пишу биологические примеры.

Для себя я определил основные идеи системного мышления так:
1. Системы состоят из подсистем, и являются частью над систем. Такая иерархия систем.
2. Разделение целого на части бывает не только структурное (к которому мы все привыкли), но и функциональное.

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

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

Забавно, например, осознавать, что чуть ли не основной задачей автомобиля является спасти жизнь человека, а не перевезти его из точки А в точку Б. По крайней мере если смотреть на стоимость частей.


Я лично прошел один базовый курс и больше пока не успеваю. Но по отзывам это очень мощная штука и дальше. Лично я подозреваю что там 10% основных идей даст 90% результата, но пока не уверен.
В любом случае разобраться хотя бы первых 10% системного менеджмента, это очень очень полезная штука, которая даст долгосрочный эффект в карьере, зарплате и просто понимании мира.

P.S. Еще у Анатолия Левенчука очень хороший вкус на новые вещи. В 2014 я переживал, что пропустил Биткоин. Это было обидно, так как я работал в центре распределенных вычислений и про Биткоин который их использует не знал. А вот про существование Эфириума я узнал из блога Левенчука, когда Эфириум стоил 30 центов, а главное идейно был очень и очень крутым.

Продолжаем про системное мышление.
#системное_мышление #кейс

Когда мы говорим про функциональное назначение систем и элементов, то автоматом всплывает для кого это нужно.
Так появляется понятие стейкхолдер. По русски что-то лучше слова не нашлось. В общем это все люди/организации, которые влияют на систему или на которых влияет система.
И первая задача которую надо сделать - это определить всех стейкхолдеров.

Удивительно как легко этот пункт продолбать и не заметить слона в комнате.

Первый пример - школьные автобусы
Вот я описывал старый пример оптимизационной задачи, в которой делали оптимальный развоз школьных автобусов и забыли про школьников, которых возят получили +100% к стоимости и срокам.

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

Он решал задачу оптимальной программы телепередач на французском телевидении. Там есть масса требований, какие передачи можно ставить в какое время.
В общем делал он делал, все сделал стал внедрять и выяснилось, что они забыли про рекламодателей.
А рекламодателям далеко не все равно, рядом с какой передачей стоять. А еще им важно в какое время и какому числу людей показывается реклама. Все пришлось переделывать. По сути ТВ это рекламная площадка и от него все зависит.
Сетку нельзя сделать универсальную. Придет дорогой рекламодатель и надо будет сетку менять под то, чтобы его реклама лучше всего показывалась.


Кто девушку платит, тот ее и танцует, это поговорка про функциональные требования и системное мышление. :)

Получилось, что определили сначала двух крупных стейкхолдеров - государство и зрителей и продолбали третьего - рекламодателей.
А после них ТЗ выросло раза в 3-4 и задача стала совсем другой, я так понимаю


Третий пример это проблема вагонетки для автопилотов. Или как системное мышление бьет философию.

Меня как-то спросили, что я думаю насчет автопилота, который будет спасать людей на зебре и жертвовать своим пассажиром.
Я сразу же сказал, что правильный автопилот должен в первую очередь спасать жизнь своего владельца.
Иначе люди просто не будут покупать машины с таким автопилотом,
Позже я услышал, что Мерседес это официально объявил, что пассажиры будут всегда в приоритете.

Забавно что, например, арендованный автопилот может уже иметь другие приоритеты. :)


Еще замечу, что идея учитывать стейкхолдеров очень важна в b2b продажах, когда для одного и того же продукта надо делать разные предложения разным стейкхолдерам внутри компании. И получается такой золотой ключик который открывает двери.
Владельцу можно например говорить про добавленную стоимость, уменьшение рисков, менеджеру про уменьшение головняка, его рост внутри компании, исполнителям объяснять что программа их не заменит, а облегчит работу и еще они премии будут получать, если вот так будут делать (одна алмазная компания конкурент занижала план, чтобы исполнитель мог улучшить их решение и получить премию, даже такое бывает).
Хоть одному не так продаешь и всё, продажа не состоялась. Как если хотя бы одна бороздка ключа не подошла, то замок не откроешь. Я на своей шкуре это испытывал не раз.




Это я еще не рассказал про роли и кучу еще всего. Системное мышление большая все таки штука. Не всё сразу :)

#мысль
Услышал архитектурную поговорку.

Красивое наполовину правильное.

Мне очень нравится, потому даже красоту еще до ума доводить надо.

#анализ_данных #домики_для_роботов #кейс

У меня бывают иногда заказы по анализу данных, не слишком часто, но направление интересное, планирую его расширять.
Пару недель назад для одного очень NDA клиента покопался в данных и нашел даже не просто value, а прямо слона в комнате. Увидел, как очень просто уменьшить расходы в 2 раза. Сейчас перепроверяем, а то кажется слишком хорошо, чтобы быть правдой.
Я планировать улучшить процессы на 1-2%, это бы окупило с запасом мои услуги. А ненароком получилось в десятки раз мощнее.

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

Я кстати зимой объявлял про то, что пытаюсь двигаться в сторону создания домиков для роботов. Дата центры очень дорогие, так что идти в эту сторону сложно, а вот лежать получается. И этот проект как раз из этой серии.

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

Новый алгоритм поиска кратчайшего пути на графе так называемый «барьер сортировки»

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

🚀 Что предложил новый алгоритм? https://arxiv.org/abs/2504.17033?utm_source=Securitylab.ru
Вместо сортировки границы текущей области, алгоритм разбивает её на кластеры и выбирает по одному узлу из каждого.
Это снижает количество сравнений и устраняет необходимость сортировки.
Работает как для ориентированных, так и для неориентированных графов с произвольными весами.
Вдохновлён идеями Беллмана-Форда, но использует их точечно, чтобы выявить ключевые «узлы-связки».

📈 Почему это важно?
Это первый универсальный алгоритм, который обходит сортировочный барьер без ограничений на тип графа.
Потенциально меняет подход к маршрутизации, логистике, сетевому анализу и многим другим задачам.

Для чего это нужно:
🚗 1. Навигация и транспорт
GPS и карты: Google Maps, Waze и другие используют алгоритмы кратчайшего пути для построения маршрутов.
Логистика: Оптимизация доставки товаров, маршруты грузовиков, дронов и курьеров.
Транспортные сети: Расчёт времени поездки в метро, автобусах, авиаперелётах.
🖥 2. Компьютерные сети
Маршрутизация пакетов: Протоколы типа OSPF и BGP используют кратчайшие пути для передачи данных.
Оптимизация трафика: Балансировка нагрузки между серверами и дата-центрами.
🧬 3. Биология и медицина
Анализ молекулярных сетей: Поиск путей между генами, белками, метаболическими реакциями.
Медицинская диагностика: Сравнение симптомов и заболеваний через графы знаний.
🛒 4. Рекомендательные системы
Поиск связей между пользователями и товарами: Например, в Amazon или Netflix.
Социальные сети: Определение степени близости между людьми (например, «друзья друзей»).
🏙 5. Городское планирование и робототехника
Планирование движения роботов: В складских системах, на заводах.
Оптимизация инфраструктуры: Где строить дороги, мосты, электросети.
🎮 6. Игры и искусственный интеллект
Играющие агенты: Перемещение персонажей по карте.
AI-планирование: Принятие решений в стратегических играх.
На русском https://www.securitylab.ru/news/562195.php

#архитектура #отладка #касдев #системное_мышление

Есть такая классическая головоломка для программистов - Ханойская башня. Нужно переставить блины пирамидки с одного штыря на другой. Но так, чтобы большой блин не лежал на блине меньшего размера. Благодаря дополнительному третьему штырю эта задачка имеет решение. Но её сложность растёт, как степень двойки от числа блинов. Чтобы передвинуть 10 блинов нужно больше тысячи операций, а чтобы 20 - больше миллиона.

Для меня это яркая аналогия для проектов. В каждом проекте есть сложности, которые умножают общую сложность проекта. И если таких проблем накапливается слишком много, то решить задачу становится невозможно.
Причем с такими очками можно смотреть на все уровни иерархии: от отдельных функций которые пишутся программистов, до согласования ТЗ с заказчиком.

Блины бывают разные - это разнородные стейкхолдеры. Лебедь, щука и рак - пример проекта с 3 стейкхолдерами и всего с тремя блинами.
Это могут быть компоненты программы. Сейчас делаем систему в одном проекте. Есть IT системы заказчика, которые как-то работают. Есть делает исполнитель, а есть расчетное ядро, которое делаю я как субподрядчик.
Получается комплексная система, в которой данные по разному работают, по разному воспринимаются.
Отладка собственно замедляется, потому что часто проблема даже не внутри кого то а на границе между компонентами.

Алгоритм тоже, если цельный это одна история, а если он состоит например из эвристики и ЛП задачи, это уже две компоненты и два блина.

Если ЛП задача работает быстро и дает оптимальный результат, норм. А если дает ответ за разумные сроки это +1 блин.

Блинами являются сложные требования к мат модели, которые могут давать между собой странные сочетания.

Как с этим бороться ? Для начала считать эти блины и контролировать чтобы они не росли просто так.
Внимательно планировать архитектуру, чтобы число блинов было минимально.
Чинить ошибки, которые увеличивают, число блинов.

Программисты новички отличаются от сеньоров как раз этим. Если ты делал проекты из 2 блинов, то ты не паришься и делаешь почти работающий код. И в мелких проектах это прокатывает. Но в любом серьезном проекте так уже нельзя.
С этой блинной точки зрения видно для чего нужна система тестирования в какой форме и когда.

Так же видна цена принятия того или иного архитектурного решения.

На уровне клиентов - подсвечивать сразу будущие проблемные места проекта и вообще формировать проект с учетом этого

#lp #mip #солверы #алгоритмы

highs отличный солвер и быстро развивается.
Весной уперся в производительность scip протестил highs и он сильно лучше работает.
Вчера уперся в производительность highs, поигрался с настройками и задача стала считаться вместо часа минуту. Просто включил вместо симплекс метода (относительно) свежий метод PDLP - прямодвойственное гибридное линейное программирование.

Важно не забывать играться с солверами и настройками хотя бы раз в полгода.
Правда, детские болезни опенсорса тоже никуда не делись. Набор highs+pyomo+pdlp+abs_mip_gap не работает, вчера до ночи ковырялся из-за этого.

UPD. Ошибка, см следующий пост. Со включенным флагом pdlp решается только вещественная задача, потому так быстро.

Нельзя писать посты по горячим следам. Солвер highs работал очень быстро просто потому что считал вещественную задачу.
Нашел вот такую интересную и не очевидную запись в документации.
If "simplex"/"ipm"/"pdlp" is chosen then, for a MIP (QP) the integrality constraint (quadratic term) will be ignored
Догадаться проверить решение сразу не догадался 🙈
В общем pdlp никакая не серебряная пуля.
Солверы конечно с разной скоростью работают, но надо было заподозрить что укорение в 50 раз это перебор.

#мысль #разработка
Метод протаптывания тропинок.

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

Я этот принцип использую в работе. У меня есть правило - автоматизирую ручную работу, после того как она случилась 3 раза.
Несколько раз, во-первых, говорят, что проблема повторяется и значит автоматизация экономит время, а во-вторых разы несколько отличаются друг от друга и появляется понимание как правильно делать.


Звучит просто и естественно, но постоянно приходится бороться. У программистов стойкое желание автоматизировать сразу.
В результате приходится охлаждать пыл, когда проблема встретилась в первый раз.
А когда проблема стала повторяться пыл уже охлажден, и иногда надо наоборот его разогревать. Особенно, если решение как автоматизировать неочевидное. А как раз когда случаи разные, то приходится чуть-чуть подумать, как сделать универсальный метод.

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


По этой же причине очень часто продукт приходится переписывать с нуля после первых трех клиентов. Как ни крути, но на первом клиенте ты незаметно закладываешься на какие-то его особенности и это остается в архитектуре продукта. И только после трех клиентов становится ясно, где именно ты заложился, а менять архитектуру уже поздно. В результате получается, что продукт проще переписывать.