Чи подібна проблема комбінаторної оптимізації будь-якій відомій проблемі?

10

Проблема полягає в наступному:

У нас є двовимірний масив / сітка чисел, кожне з яких представляє певну "вигоду" або "прибуток". У нас також є два фіксованих цілих числа і (для "ширини" і "висоти") і фіксованого цілого числа . $w$ $h$ $n$

Тепер ми хочемо накласти на сітку прямокутників розмірами , щоб загальна сума значень комірок у цих прямокутниках була максимальною. $n$ $w \times h$

Наступний малюнок - приклад двовимірної сітки з накладеними на ній двома такими прямокутниками (малюнок не демонструє оптимального рішення, лише один можливий наклад, де і ) $w = h = 2$ $n = 2$

Приклад сітки

Прямокутники не можуть перетинатися (інакше нам просто потрібно знайти оптимальне положення для одного прямокутника, а потім поставити всі прямокутники в це положення.)

У наведеному вище прикладі загальна сума значень у клітинках складе $-2 + 4.2 + 2.4 + 3.14 + 2.3 -1.4 + 1 - 3.1$

Чи схоже це на будь-яку відому проблему комбінаторної оптимізації? так що я можу почати читати щось і спробувати знайти шляхи вирішення.

Ще кілька відомостей для зацікавлених:

Поки єдині ідеї, які у мене були, це або жадібний алгоритм (який би знайшов найкраще місце для першого прямокутника, потім знаходив локоніон, що не перекривається для другого прямокутника тощо), або деякі метагевристичні, такі як генетичні алгоритми.

Насправді я хочу вирішити цю проблему за допомогою сітки, яка містить близько мільйона комірок і десятки тисяч (а то й сотень тисяч) прямокутників, хоча вирішувати її не потрібно за короткий час (тобто це було б прийнятно для алгоритм займає години чи навіть дні.) Я не сподіваюся на точне рішення, але хочу отримати таке, яке є максимально гарним, враховуючи ці обмеження.

Ура!

— п'ятдесят вісім
джерело

(по телефону), схоже, це може бути вирішено з максимальною відповідністю під час перетворення та деякими додатковими обмеженнями. Спробую записати пізніше.

— Ніколас Манкузо

Я можу уявити, що вимагати використання точного означає, що іноді не використовується "локальний" максимум, але навколо нього є кільце. Я уявляю тут просту форму купола, де "жадібне" взяття центру купола означає, що ви не можете вмістити всі навколо нього.

n

$n$

n - 1

$n-1$

— Марк Херд

Першою моєю думкою було б спробувати динамічне програмування. Пронумеруйте квадрати відповідно до відстані Манхеттена від лівого верхнього кута. Підпроблема - це число квадрата; список вибраних прямокутників, у верхньому лівому полі яких число менше ; і мета - розширити на найкращий можливий набір квадратів, що не перекриваються, додавши деяку підмножину квадратів з лівими верхними кутами, що мають числа . Ви можете вирішити кожну підпроблему швидко, якщо у вас є рішення для всіх пізніших підпроблем. Питання лише в тому, скільки підпроблем вам доведеться вивчити.

s

$s$

L

$L$

s

$s$

L

$L$

\geq s

$\ge s$

— DW

2

Моя остання рецептура мала фатальний недолік, який потребував би експоненціальної кількості «обмежувальних» вузлів.

Іншим природним графічним формулюванням проблеми було б створення графіка, де кожна вершина являє собою прямокутник з . Будь-яка пара прямокутників, що перекриваються має ребро на цьому графіку. Розв’язуючи максимально зважений незалежний набір розміром ми маємо вирішити вашу вихідну задачу. Для цього існує багато хороших евристичних та алгоритмів наближення. $r$ $w_r$ $r, r'$ $k=n$

— Ніколас Манкузо
джерело

Це напрямок, до якого я зараз схиляюся, я буду експериментувати з цим і прийму рішення, якщо це буде той, яким я в кінцевому підсумку користуюся, привіт.

— fiftyeight

2

Ви можете сформулювати це як екземпляр гігантського цілого лінійного програмування (ILP), а потім застосувати незавершений вирішувач ILP (lp_solve, CPLEX тощо). Вони дадуть вам найкраще рішення, яке вони можуть знайти. Враховуючи розмір вашої проблемної інстанції, я не знаю, чи буде це досить ефективно, але це було б легко спробувати.

$x_r$ $r$ $x_r=1$ $r$ $x_r=0$ $\sum_r c_r x_r$ $c_r$ $r$ $\sum_r x_r = n$ $x_r + x_s \le 1$ $r,s$

— DW
джерело

Як ви вважаєте, ця проблема є надзвичайно важкою? Я не переконаний, що в ньому немає рішення, що займає полі часу, і розв'язувачі ILP навряд чи закінчать екземпляри середнього розміру.

— RB

1

@RB, я не маю уявлення, чи це NP-важко. Дивіться мій коментар під запитанням про динамічне програмування для моєї першої думки про те, як спробувати знайти алгоритм поліноміального часу (але я не знаю, чи буде отриманий алгоритм у P чи ні). Щодо того, що можуть зробити вирішувачі ILP, єдиний спосіб з’ясувати це спробувати - іноді їх продуктивність може бути дивовижною.

— DW