Приветствую! Отличный вопрос. Давайте я покажу контекст на примере.
Если посмотреть на официальный Getting Started ноутбук от организаторов Kaggle — вот там действительно хаос https://www.kaggle.com/code/inversion/santa-2025-getting-started. Детали просто раскиданы по сетке, чтобы показать механику конкурса. В моём же случае хаоса минимум — я, скорее, наоборот, привожу всё к жесткому порядку.
Если рассуждать философски, то за фазой войны или пожара всегда следует фаза рождаемости и произрастания. На этом дуализме и построен наш «трехфазный термодинамический двигатель раскроя».
Мы сначала «отжигаем» (даем деталям хаотично найти первые зацепки), затем «закаливаем» (стягиваем их в монолит) и совмещаем в единое целое. По сути — кристаллизуем Материк.
Дальше, если время и силы останутся, можно внедрить еще пару фаз и продолжать телебонить алгоритм, еще ближе продвигаясь к идеальному результату. Так что для реального лазера наш «хаос» гораздо дружелюбнее, чем то, что выдают стандартные подходы на соревнованиях!
Канторовича чтим и помним, но классическое линейное программирование (ЛП) и целочисленное программирование ломают зубы о невыпуклые полигоны (те самые «ёлочки» сложной формы) и свободное вращение деталей.
Чтобы описать укладку 200 сложных геометрических объектов через систему линейных неравенств Канторовича, потребуется такое количество переменных и ограничений, что комбинаторный взрыв случится раньше, чем алгоритм выдаст первый шаг. Поэтому для сложной 2D-геометрии «кожа к коже» эвристика вроде Front-Propagation и Shapely на практике оказывается эффективнее и быстрее.
«Ztare, вы правы в том, что реальность всегда вносит коррективы (мятая коробка, пересорт или лишний паллет). Но 3D-планирование нужно не для того, чтобы превратить грузчиков в киборгов, а для решения конкретных бизнес-задач:
Контроль объема: Без плана менеджер может подтвердить клиенту загрузку, которая физически не влезет. Система на этапе заявки говорит: «Стоп, сюда нужно два авто вместо одного».
Визуальная шпаргалка: Грузчику не нужно иметь высшее образование, чтобы посмотреть на планшет и увидеть: «тяжелое — вниз, длинное — вдоль борта». Это банально ускоряет работу и снижает риск того, что хрупкий товар окажется под сейфом.
Очередность выгрузки (LIFO/FIFO): Если у фуры 5 точек разгрузки, план помогает не заставить товар для первой точки тем, что нужно выгружать в последнюю. Иначе грузчикам придется «перебирать» всю фуру на обочине.
Понятно, что никто не требует соблюдения плана до миллиметра, но наличие «карты» в разы снижает количество споров в духе «почему не влезло» и «кто виноват». Это как навигатор: вы можете ехать и по памяти, но с ним вероятность свернуть не туда гораздо меньше».
Я ни в коем случае не считаю, что в "Магните" работают дураки. Наоборот, там сильнейшая команда, которая держит на плаву гигантскую махину.
Но одно дело — знать, где теряются деньги, и совсем другое — иметь ресурс внедрить решение здесь и сейчас. Мой пост — это попытка сократить этот путь через внешний импульс, пусть и резкий. В конечном счете, если алгоритм даст профит, выиграют все: и компания, и те, кто в ней работает
Согласен, в связке с C (через NumPy/Pandas) Python работает отлично.
Впрочем, это уже нюансы реализации. Главное, что текущая математика даже на "медленном" Python выдает результат за доли секунды. На данном этапе вопрос выбора языка считаю неактуальным. Важнее понять, дает ли алгоритм профит на порядки или нет
Справедливо. Статья резкая. Но разве Хабр — это место исключительно для комплиментов? Если присмотреться внимательнее, то никаких явных ошибок в "Магните" нет: задача коммивояжёра официально не решена, и игнорировать "выскочку" на Хабре — это нормальная защитная реакция, так как вероятность прорывного решения со стороны обычно низка.
С другой стороны, отсутствие хейта по существу на протяжении уже шести моих статей — тоже сигнал к тому, чтобы на секунду отложить эмоции и дать волю разуму и цифрам. Мой пост — это не резюме на вакансию, а публичный оффер на проверку гипотезы. Если она рабочая, то, надеюсь, мой "сложный характер" отойдёт на второй план перед лицом реальной операционной эффективности. Ждём реакцию (или её отсутствие)
Этот проект (то что в репохе) — прямой наследник идеи «конструктора» из вашей статьи, только возведенный в абсолют. Если у вас «квинтетная модель» (5 полей), то здесь — «дуплеты» (всего 2 поля: кто с кем связан). Ваще мне канешна сложно все это понять, проще кодом запилить какую-то конкретную задачу. А так, все ,что написали в статье - правда, кудабы это применить, только.
Статья написана почти год назад и 2 комментария всего. Порог для понимания очень высокий. Попробую адаптировать как могу. Репоха публичная (по-моему отражает суть, тут ОС, База на новом движке и ФС тоже на новых рельсах): https://github.com/Andreymazo/LinkTheory Ридми информативный.
запускайте, пробуйте. своя ОС да и база совсем не скьюэль по скорости python query.py. Язык питон, всем доступен
не увидел всего 2,2тыс просмотров у статьи такого масштаба это очень мало. Это переворот в мироощущении, как в фильме Матрица, а почитать и понять никто не может. написано машинным языком, народу просто не понять. очень жаль.
Коллеги, давайте разделим «мух и котлеты»: физические риски логистики и возможности математического ядра.
Про «билет в один конец» (LIFO): Да, LIFO — это всегда риск. Если на первой точке у вас не приняли 2 паллеты, они становятся «пробкой». Но давайте будем честны: возить всё вперемешку или гонять три полупустые машины вместо одной — это не решение проблемы, а капитуляция перед неэффективностью. Весь современный ритейл строится на попытках обуздать LIFO, потому что альтернатива — это просто сжигание денег в баке фуры.
Алгоритм — это инструмент, а не догма: Главное заблуждение критиков: «Алгоритм заставит нас грузить так, что мы не выгрузимся». Нет. Моему движку абсолютно всё равно, сколько и каких ограничений (constraints) вы в него загрузите.
Нужен технический проход в 60 см для доступа к дальним паллетам? Пожалуйста.
Хотите ограничить плотность загрузки до 85%, чтобы оставить место для маневра? Легко.
Нужно исключить LIFO для определенных категорий товара? Одна строчка в JSON.
Суть предложения: «Шампур-Скребок» — это не «сферическая фура в вакууме». Это универсальный математический решатель. Он не спорит с вашими бизнес-процессами, он их обсчитывает мгновенно.Если завтра «Магнит» скажет: «Нам нужно возить по 20 паллет, но с идеальной развесовкой по осям и учетом 15 правил товарного соседства», — алгоритм выдаст схему за миллисекунды. Пока система считает это «на глаз» или в тяжелых легаси-системах, она проигрывает математике.
Итог: Мой вызов «225 машин» остается в силе. Давайте добавим в условия теста любые ваши «страшилки» про грузчиков и возвраты на WB. Если алгоритм их пережует и всё равно покажет экономию — признаем, что математика сильнее инерции. Если нет — я публично признаю поражение.
Мяч на стороне тех, кто платит за бензин и штрафы.
Коллега, жму руку! Битва PHP с API маркетов — это отдельный вид промышленного альпинизма, уважаю.
"Мой алгоритм" называется "Шампур-Скребок" (или Skewer). И название тут говорящее: "Шампур" — мы пронизываем пространство с невероятной скоростью жадного алгоритма. "Скребок" — укротитель. Мы выскребаем каждый сантиметр и каждый килограмм полезной нагрузки, чтобы не возить воздух, с учетом LIFO, веса и баланса.
Это не "математика против людей", а математика для людей. Чтобы грузчик на складе получил четкую карту сборки: "Паллету А ставь сюда, паллету Б — туда". Без гаданий и лишних перекладываний. Зайдите в @routeload_bot, гляньте демо. Там как раз видно, что "Шампур" — это про порядок, а не про мучения склада
"Не должен сильно влиять" — это как раз та серая зона, где сгорают деньги на штрафах. В стандартной еврофуре (13.6 м) за задней тележкой осей остается приличное плечо. Выгрузка даже 1.5–2 тонн с самого края создает момент, который догружает ведущую ось тягача.
На бумаге это "чуть-чуть", а на весах — пробитие лимита на 200-300 кг и протокол. Мой алгоритм уходит от "не должен" к точным цифрам. Безопасность и экономика как раз и начинаются там, где кончаются гадания на глаз. Зайдите в бот, проверьте развесовку на реальных координатах
Нельзя всех под одну гребенку. Все разные и в первой и во второй вышеназванных мной группах есть сообразительные и есть наоборот. А ещё есть пословица: "лучше с умным потерять, чем с дураком найти", это я сейчас вообще в отрыве от чьей-либо личности. Если правильно всё организовать по форме, то вообще не поинципиальна суть (с ИИ или без), суть (результат) подтянется.
Статью дочитал, спс. Боялся обижулька на ИИ очередного потерявшего работу айтишника будет, но этого нет. Естесственно сейчас 2 глобальных лагеря: ЗаКодировниесИИ и ПротивКодированиясИИ, я в первой. Не буду здесь рекламировать свои статьи и алгоритм, это некрасиво, но вообщем и по моему примеру, если пройдете убедитесь на протестированных цифрах и по аналогичным примерам ребят из первой группы, что вопрос в деталях. Если разобрался как управлять этой "ядерной" силой, то все ок, если нет, то только хуже сделаешь, чем было. Просто надо уметь. Это такая же работа, как, например, укладывать плитку, а не развлечение. Я про кодирование с Ии, если что)
Мой алгоритм можно улучшать и дальше: например, переезд на Rust удвоит "скорострельность" как минимум. Но суть не в языке, а в математике.
Почему они не сделали за 5 лет? Во-первых, не только они — вообще никто пока не решил эту NP-трудную задачу "идеальным" способом, включая вашего покорного слугу. Но в моем варианте изменен сам подход к комбинаторике. Почему получилось именно у меня? Может, звезды сошлись, может, интуиция, но тесты говорят то, что говорят. цифры — упрямая вещь
Элемент предположения есть, я действительно не знаю, как сейчас работает Магнит изнутри. Но в этом и смысл публикации алгоритма — заявить о себе и вызвать на открытый диалог. "Наезда" я не увидел, а увидел возможность законно заработать.
Противоречия тут нет: если бы я знал их "кухню", мы бы решали это в рабочем порядке, а не публично. Мой посыл — проверить теорию практикой (тест 225 машин). Если расчеты совпадут с реальностью — профит, если нет — будем искать "косяки". По-моему, нормальный путь.
Спасибо за первый комментарий по существу. В статье я как раз заложил три сценария теста "225 машин", включая тот, где их решение эффективнее моего.
Я допускаю разные варианты, но по результатам своих тестов ставлю 95% на то, что мой алгоритм отработает чище. Скорее всего, истина посередине и будет смысл скомбинировать их опыт и мой движок. Но чтобы это понять, нужно переходить от "мыслей" к реальному пилоту
Приветствую! Отличный вопрос. Давайте я покажу контекст на примере.
Если посмотреть на официальный Getting Started ноутбук от организаторов Kaggle — вот там действительно хаос https://www.kaggle.com/code/inversion/santa-2025-getting-started. Детали просто раскиданы по сетке, чтобы показать механику конкурса. В моём же случае хаоса минимум — я, скорее, наоборот, привожу всё к жесткому порядку.
Если рассуждать философски, то за фазой войны или пожара всегда следует фаза рождаемости и произрастания. На этом дуализме и построен наш «трехфазный термодинамический двигатель раскроя».
Мы сначала «отжигаем» (даем деталям хаотично найти первые зацепки), затем «закаливаем» (стягиваем их в монолит) и совмещаем в единое целое. По сути — кристаллизуем Материк.
Дальше, если время и силы останутся, можно внедрить еще пару фаз и продолжать телебонить алгоритм, еще ближе продвигаясь к идеальному результату. Так что для реального лазера наш «хаос» гораздо дружелюбнее, чем то, что выдают стандартные подходы на соревнованиях!
Канторовича чтим и помним, но классическое линейное программирование (ЛП) и целочисленное программирование ломают зубы о невыпуклые полигоны (те самые «ёлочки» сложной формы) и свободное вращение деталей.
Чтобы описать укладку 200 сложных геометрических объектов через систему линейных неравенств Канторовича, потребуется такое количество переменных и ограничений, что комбинаторный взрыв случится раньше, чем алгоритм выдаст первый шаг. Поэтому для сложной 2D-геометрии «кожа к коже» эвристика вроде Front-Propagation и Shapely на практике оказывается эффективнее и быстрее.
Чтобы не снижать "запас прочности системы" оставим как есть - "бесконечный аврал, панику среди совсем немотивированных сотрудников". Хм ... логично.
«Ztare, вы правы в том, что реальность всегда вносит коррективы (мятая коробка, пересорт или лишний паллет). Но 3D-планирование нужно не для того, чтобы превратить грузчиков в киборгов, а для решения конкретных бизнес-задач:
Контроль объема: Без плана менеджер может подтвердить клиенту загрузку, которая физически не влезет. Система на этапе заявки говорит: «Стоп, сюда нужно два авто вместо одного».
Визуальная шпаргалка: Грузчику не нужно иметь высшее образование, чтобы посмотреть на планшет и увидеть: «тяжелое — вниз, длинное — вдоль борта». Это банально ускоряет работу и снижает риск того, что хрупкий товар окажется под сейфом.
Очередность выгрузки (LIFO/FIFO): Если у фуры 5 точек разгрузки, план помогает не заставить товар для первой точки тем, что нужно выгружать в последнюю. Иначе грузчикам придется «перебирать» всю фуру на обочине.
Понятно, что никто не требует соблюдения плана до миллиметра, но наличие «карты» в разы снижает количество споров в духе «почему не влезло» и «кто виноват». Это как навигатор: вы можете ехать и по памяти, но с ним вероятность свернуть не туда гораздо меньше».
Я ни в коем случае не считаю, что в "Магните" работают дураки. Наоборот, там сильнейшая команда, которая держит на плаву гигантскую махину.
Но одно дело — знать, где теряются деньги, и совсем другое — иметь ресурс внедрить решение здесь и сейчас. Мой пост — это попытка сократить этот путь через внешний импульс, пусть и резкий. В конечном счете, если алгоритм даст профит, выиграют все: и компания, и те, кто в ней работает
Согласен, в связке с C (через NumPy/Pandas) Python работает отлично.
Впрочем, это уже нюансы реализации. Главное, что текущая математика даже на "медленном" Python выдает результат за доли секунды. На данном этапе вопрос выбора языка считаю неактуальным. Важнее понять, дает ли алгоритм профит на порядки или нет
Справедливо. Статья резкая. Но разве Хабр — это место исключительно для комплиментов? Если присмотреться внимательнее, то никаких явных ошибок в "Магните" нет: задача коммивояжёра официально не решена, и игнорировать "выскочку" на Хабре — это нормальная защитная реакция, так как вероятность прорывного решения со стороны обычно низка.
С другой стороны, отсутствие хейта по существу на протяжении уже шести моих статей — тоже сигнал к тому, чтобы на секунду отложить эмоции и дать волю разуму и цифрам. Мой пост — это не резюме на вакансию, а публичный оффер на проверку гипотезы. Если она рабочая, то, надеюсь, мой "сложный характер" отойдёт на второй план перед лицом реальной операционной эффективности. Ждём реакцию (или её отсутствие)
https://github.com/Andreymazo/LinkTheory/blob/main/README.md Операционная система, Файловая система и база - на основании этой теории. На питоне.
Теория - жадная, очень жадная)
Нашел вас по вашему комментарию к ТеорииСвязей. Посмотрел и у вас интересный вариант, с теорией связей перекликается. https://github.com/Andreymazo/LinkTheory/blob/main/README.md можете попэцкать тут.
Этот проект (то что в репохе) — прямой наследник идеи «конструктора» из вашей статьи, только возведенный в абсолют. Если у вас «квинтетная модель» (5 полей), то здесь — «дуплеты» (всего 2 поля: кто с кем связан). Ваще мне канешна сложно все это понять, проще кодом запилить какую-то конкретную задачу. А так, все ,что написали в статье - правда, кудабы это применить, только.
Статья написана почти год назад и 2 комментария всего. Порог для понимания очень высокий. Попробую адаптировать как могу. Репоха публичная (по-моему отражает суть, тут ОС, База на новом движке и ФС тоже на новых рельсах): https://github.com/Andreymazo/LinkTheory Ридми информативный.
запускайте, пробуйте. своя ОС да и база совсем не скьюэль по скорости python query.py. Язык питон, всем доступен
не увидел всего 2,2тыс просмотров у статьи такого масштаба это очень мало. Это переворот в мироощущении, как в фильме Матрица, а почитать и понять никто не может. написано машинным языком, народу просто не понять. очень жаль.
Коллеги, давайте разделим «мух и котлеты»: физические риски логистики и возможности математического ядра.
Про «билет в один конец» (LIFO):
Да, LIFO — это всегда риск. Если на первой точке у вас не приняли 2 паллеты, они становятся «пробкой». Но давайте будем честны: возить всё вперемешку или гонять три полупустые машины вместо одной — это не решение проблемы, а капитуляция перед неэффективностью. Весь современный ритейл строится на попытках обуздать LIFO, потому что альтернатива — это просто сжигание денег в баке фуры.
Алгоритм — это инструмент, а не догма:
Главное заблуждение критиков: «Алгоритм заставит нас грузить так, что мы не выгрузимся». Нет.
Моему движку абсолютно всё равно, сколько и каких ограничений (constraints) вы в него загрузите.
Нужен технический проход в 60 см для доступа к дальним паллетам? Пожалуйста.
Хотите ограничить плотность загрузки до 85%, чтобы оставить место для маневра? Легко.
Нужно исключить LIFO для определенных категорий товара? Одна строчка в JSON.
Суть предложения:
«Шампур-Скребок» — это не «сферическая фура в вакууме». Это универсальный математический решатель. Он не спорит с вашими бизнес-процессами, он их обсчитывает мгновенно.Если завтра «Магнит» скажет: «Нам нужно возить по 20 паллет, но с идеальной развесовкой по осям и учетом 15 правил товарного соседства», — алгоритм выдаст схему за миллисекунды. Пока система считает это «на глаз» или в тяжелых легаси-системах, она проигрывает математике.
Итог: Мой вызов «225 машин» остается в силе. Давайте добавим в условия теста любые ваши «страшилки» про грузчиков и возвраты на WB. Если алгоритм их пережует и всё равно покажет экономию — признаем, что математика сильнее инерции. Если нет — я публично признаю поражение.
Мяч на стороне тех, кто платит за бензин и штрафы.
Коллега, жму руку! Битва PHP с API маркетов — это отдельный вид промышленного альпинизма, уважаю.
"Мой алгоритм" называется "Шампур-Скребок" (или Skewer). И название тут говорящее: "Шампур" — мы пронизываем пространство с невероятной скоростью жадного алгоритма. "Скребок" — укротитель. Мы выскребаем каждый сантиметр и каждый килограмм полезной нагрузки, чтобы не возить воздух, с учетом LIFO, веса и баланса.
Это не "математика против людей", а математика для людей. Чтобы грузчик на складе получил четкую карту сборки: "Паллету А ставь сюда, паллету Б — туда". Без гаданий и лишних перекладываний. Зайдите в @routeload_bot, гляньте демо. Там как раз видно, что "Шампур" — это про порядок, а не про мучения склада
"Не должен сильно влиять" — это как раз та серая зона, где сгорают деньги на штрафах. В стандартной еврофуре (13.6 м) за задней тележкой осей остается приличное плечо. Выгрузка даже 1.5–2 тонн с самого края создает момент, который догружает ведущую ось тягача.
На бумаге это "чуть-чуть", а на весах — пробитие лимита на 200-300 кг и протокол. Мой алгоритм уходит от "не должен" к точным цифрам. Безопасность и экономика как раз и начинаются там, где кончаются гадания на глаз. Зайдите в бот, проверьте развесовку на реальных координатах
Нельзя всех под одну гребенку. Все разные и в первой и во второй вышеназванных мной группах есть сообразительные и есть наоборот. А ещё есть пословица: "лучше с умным потерять, чем с дураком найти", это я сейчас вообще в отрыве от чьей-либо личности. Если правильно всё организовать по форме, то вообще не поинципиальна суть (с ИИ или без), суть (результат) подтянется.
Статью дочитал, спс. Боялся обижулька на ИИ очередного потерявшего работу айтишника будет, но этого нет. Естесственно сейчас 2 глобальных лагеря: ЗаКодировниесИИ и ПротивКодированиясИИ, я в первой. Не буду здесь рекламировать свои статьи и алгоритм, это некрасиво, но вообщем и по моему примеру, если пройдете убедитесь на протестированных цифрах и по аналогичным примерам ребят из первой группы, что вопрос в деталях. Если разобрался как управлять этой "ядерной" силой, то все ок, если нет, то только хуже сделаешь, чем было. Просто надо уметь. Это такая же работа, как, например, укладывать плитку, а не развлечение. Я про кодирование с Ии, если что)
Мой алгоритм можно улучшать и дальше: например, переезд на Rust удвоит "скорострельность" как минимум. Но суть не в языке, а в математике.
Почему они не сделали за 5 лет? Во-первых, не только они — вообще никто пока не решил эту NP-трудную задачу "идеальным" способом, включая вашего покорного слугу. Но в моем варианте изменен сам подход к комбинаторике. Почему получилось именно у меня? Может, звезды сошлись, может, интуиция, но тесты говорят то, что говорят. цифры — упрямая вещь
Судьбоносное замечание в контексте этой статьи. Пойду запишу
Элемент предположения есть, я действительно не знаю, как сейчас работает Магнит изнутри. Но в этом и смысл публикации алгоритма — заявить о себе и вызвать на открытый диалог. "Наезда" я не увидел, а увидел возможность законно заработать.
Противоречия тут нет: если бы я знал их "кухню", мы бы решали это в рабочем порядке, а не публично. Мой посыл — проверить теорию практикой (тест 225 машин). Если расчеты совпадут с реальностью — профит, если нет — будем искать "косяки". По-моему, нормальный путь.
Спасибо за первый комментарий по существу. В статье я как раз заложил три сценария теста "225 машин", включая тот, где их решение эффективнее моего.
Я допускаю разные варианты, но по результатам своих тестов ставлю 95% на то, что мой алгоритм отработает чище. Скорее всего, истина посередине и будет смысл скомбинировать их опыт и мой движок. Но чтобы это понять, нужно переходить от "мыслей" к реальному пилоту
Снимаю шляпу. У меня в комментариях физика постарела