Парадокс Симпсона в реальной жизни.
#кейс #математика #парадокс

Был летом заказчик, я написал для него программу оптимизации работы завода. И там всплыла контринтуитивная штука.
Есть два полуфабриката: 60% раствор некоторого вещества, 30% раствор того же вещества, и некоторый продукт, который делается из 30% раствора вещества. Полуфабрикаты так же являются и продуктами, то есть продаются напрямую.

Себестоимость и маржинальность привожу в табличке.
Заказчики придумали и используют способ поднять маржинальность. Они разбавляют 60% раствор вещества и используют его для основного продукта. Процедура разбавления простая, можно заметить что 14000/2 = 7000 < 8000. Себестоимость продукта падает на 1 тысячу, а маржинальность поднимается. Казалось бы прекрасно. Мы подняли маржинальность одного из продуктов, а другие маржинальности остались неизменны, то есть мы подняли общую маржинальность.

Нет! Общая маржинальность уменьшилась.

Как так? Смотрим картинки, я расписал 2 сценария.
Просто надо считать средневзвешенную маржу. Правда уменьшение общей маржинальности это тоже выворот статистики, так как мы стали продавать больше 30% полуфабриката, и у нас просто увеличился общий объем продаж.

А смотреть реально надо на потерянные 6 миллионов прибыли.

Причем чтобы увидеть, что мы теряем эти 6 миллионов на ровном месте, достаточно просто использовать здравый смысл.

Продукт тут вообще не причем. Если разбавить 1 тонну 60% раствора и продать то мы заработаем 2*30=60 миллионов вместо 63, то есть мы потеряем 3 миллиона. А мы для улучшения продукта разбавили 2 тонны и потеряли 6 миллионов.

Вот и вся арифметика.

Этот пример абсолютно реальный, но бумажный. Мне приходили входные данные и приходилось убеждать, что не надо разбавлять 60% раствор. Но на практике, они вроде так не делали.

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

Линейное программирование может больше, чем кажется, ч. 3.
#mip #lp #моделирование

ЛП может находить самые равномерные решения.

От меня с ЛП как-то отмахивались, рассказав следующую историю. Сделали алгоритм оптимизации запасов на складах и распределении этих запасов между клиентами.

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

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

Разработчики алгоритма заявили, что проблема связана с фундаментальной особенностью ЛП – то, что решение всегда находится экстремальное, то есть на границе. И если у одного клиента выше приоритет раздачи, то он получает всё, а другие ничего.

На мой взгляд, проблема тут в недопоставленной задачи. Просто был сделан алгоритм под стандартную ситуацию – когда всего хватает и не был обработан редкий, но важный случай ситуации нехватки остатков. Точнее он даже был сделан – по приоритетам клиентов, но не так как будет действовать реальный диспетчер. Достаточно было проработать эту ситуацию, описать поведение диспетчера и его автоматизировать. Видимо человек все равно бы звонил клиентам и выяснял бы у кого горит, а кому пока не критично. А из тех, кому критично распределять по уровню недовольства. При этом можно использовать те же приоритеты, и если у нас один клиент в два раза более приоритетный чем другой, то мы раздадим запасы 100 к 50, а не 150 к 0.

А “экстремальность” решений ЛП легко превращается равномерность при правильной постановке задачи.

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

Был такой великий математик и педагог Игорь Федорович Шарыгин, с кем мне довелось быть знакомым. Ему для учебника понадобилось нарисовать неравнобедренный и неравносторонний треугольник. И он задумался, какой многоугольник самый несимметричный. Точную постановку задачи уже не помню. Кажется, у него получился треугольник с углами 20 60 и 100 градусов, и он очень радовался треугольнику в 100 градусов.

#cad #ai
С появлением LLM БЯМ, возникает возможность нового интерфейса работы с программами - чат запросов. Это и интерфейс резко упрощает и не надо помнить, где какая функция находится.
Технически все отлично реализуется, БЯМ достаточно уметь переводить запрос в файл конфига (или создает патч этого конфига). А программа уже просто визуализирует этот конфиг файл.

Появляются первые варианты, вот видео Text-to-CAD от https://zoo.dev/

Подскажите кто-нибудь уже делает что-то подобное в России? Хочу проконсультироваться.