Роз'яснення з розгалуженням та зв'язком

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

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

Що мені потрібно - це деякі проблеми, і як можна вирішити ці проблеми за допомогою гілки та прив’язки.

Давайте застосуємо Branch and Bound до Рюкзака , сподіваємось, це зрозуміє вам концепцію.

Ми маємо $n$ предмети, марковані $1$ через до $n$. $v_i$ - це значення $i$й пункт, і $w_i$його вага. Ми намагаємось помістити їх у рюкзак, який може містити до$T$ ваги загалом, і ми намагаємося максимально збільшити суму значень предмета, який ми кладемо в ранець.

Звичайний зворотній підхід - наша основа. Ми спочатку ставимо$v_1$ в упаковці, а потім вирішіть проблему для решти $n-1$предмети з рекурсією. Потім видаляємо$v_1$ з пачки і вирішити проблему для решти $n-1$ Елементи знову, і ми повертаємо найкращу конфігурацію, яку ми знайшли.

Цей зворотний трек є частиною «Відділення» відгалуження та зв’язування. Ви розгалужуєте (у випадку з Рюкзаком) два випадки: 'предмет$i$ є частиною елемента "та" рішення $i$не є частиною рішення ". Ви можете уявити це як двійкове дерево, де ліва дитина - один випадок, а права дитина - інший. Це дерево є деревом пошуку (або пошуковим простором ): його глибина становить$n$і тому воно має $O(2^n)$вузли. Тому алгоритм має експоненціальний час у кількості елементів.

Тепер ми переходимо до частини "Обмежена": ми намагаємось знайти такі критерії, які б могли сказати: "ця конфігурація ніколи не виходить, тому ми можемо не турбуватися обчислювати це". Прикладом такого критерію є «вага предметів, які ми вже помістили в рюкзак, перевищує$T$': якщо ми додали, скажімо, перше $n/2$ предметів у рюкзак, і тому він уже заповнений, немає сенсу намагатися ставити предмети $n/2+1$ через до $n$ і в рюкзаку, але також немає сенсу намагатися вмістити будь-який підмножина $n/2+1$ через до $n$ у рюкзаку, оскільки він уже повний, тому ми економимо $2^{n/2}$справ. Інший приклад - " навіть якщо я вставлю всі решта елементів, значення елементів, які я вклав, не буде перевищувати найкращу конфігурацію, яку я знайшов досі ".

Ці критерії по суті відрізають частини дерева пошуку: на якомусь вузлі ви говорите, наприклад, «ліве піддерево не дасть мені кращої конфігурації, оскільки X», тож ви забудете про це піддірева і не будете його досліджувати. Піддерево глибини$d$ що ви вирізали таким чином, вас економить $O(2^d)$ вузлів, які можуть бути досить трохи швидкими, якщо вам пощастить.

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

Ви можете зробити «Обмежувальну» частину настільки складною, як вам подобається. Наприклад, проблеми цілого програмування часто вирішуються за допомогою релаксації: ви розслабляєте свою програму до лінійної програми, яку ви можете вирішити в поліноміальний час, а потім можете викинути безліч справ для ваших бінарних змінних, які ніколи не вийдуть. Потім ви відгалужуєте на інші параметри.

Зауважте, що Branch and Bound зазвичай лише збільшує швидкість на практиці, але не в теорії: важко точно сказати, яка частина дерева пошуку вирізана за допомогою вашої евристики. Про це свідчить кількість різних евристик, що використовуються на практиці в таких проблемах. Якщо вам не пощастило, решта дерева пошуку залишається величезною навіть з великою кількістю обмежень.

Розглянемо планування , завдання присвоїти робочі місця з певною тривалістю та строками роботи. Ми припускаємо дискретний час. Багато таких проблем є NP (O) -твердими.

Зокрема, ця відповідь піде на розмову $1 \mid r_i \mid L_\max$, це ми плануємо

• на одній машині
• проблеми з датами випуску і ми
• мінімізуйте максимальну затримку , тобто максимальну різницю між терміном та часом завершення для всіх завдань.$L_\max$

Версія цієї проблеми є важкою для NP; це можна побачити, зменшивши з 3PARTITION .

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

Тепер, щоб застосувати Branch & Bound до цієї проблеми, нам потрібно виправити деякі параметри:

• Ми обчислюємо нижню межу, дозволяючи передбачити і використовувати EDD.
• Ми відділяємось, фіксуючи кожну позапланову роботу як наступну.
• Ми йдемо до дитини спочатку зі смайлами нижньої межі.

Ви повинні зробити це для кожної заявки B&B.

Для конкретного прикладу розглянемо цей екземпляр :$1 \mid r_i \mid L_\max$

$\qquad \displaystyle \begin{array}{c|cccc} i & 1 & 2 & 3 & 4 \\ \hline p_i & 4 & 2 & 6 & 5 \\ r_i & 0 & 1 & 3 & 5 \\ d_i & 8 & 12 & 11 & 10 \end{array}$

з робочих місць часи обробки, дати релізу і належних термінів.$p_i$$r_i$$d_i$

Виконуючи B&B, як зазначено вище, це відбувається:

_{Цей GIF не циклічно. Перезавантажте його на новій вкладці, щоб побачити спочатку.}
^{[ джерело ] [ статична версія ]}

Зауважте, що з 41 вузла лише чотири відвідуються належним чином, і лише для десяти обчислюються нижні межі.