Моделювання складного графіку роботи


9

У мене є реальна проблема, яку я намагаюся представляти та автоматизувати. Я спростив і абстрагував це до наступного:

  • Є n місць роботи (P1, P2, ..., Pn).
  • Кожне місце, Pn має ключ, Kn.
  • Є m Workers, (W1, W2, ..., Wm).
  • Для того, щоб працювати на Pn, робітник повинен утримувати Kn.
  • Кожен ключ може бути утримуваний працівником або залишений на Біржі, E.
  • Працівник може здійснити поїздку на Біржу в будь-який час, щоб забрати кілька незатребуваних ключів або скинути деякі ключі, щоб інші могли використовувати.

  • Зараз існує екзогенний графік роботи, який повинен бути виконаний у суворому порядку. Наприклад:

    • 2016-04-21 W1 повинен працювати на P6
    • 2016-04-21 W2 повинен працювати на P3
    • ** необхідний обмін ключами **
    • 2016-04-22 W3 повинен працювати на P3
    • 2016-04-22 W2 повинен працювати на P6
  • Будь-яка кількість працівників, можливо, доведеться працювати в Pn в якийсь момент свого графіку, хоча ніколи в той же день

Ми знаємо:

  • Початкове розташування всіх ключів, або з працівниками, або на E
  • Майбутні робочі доручення, які повинен буде виконати кожен працівник

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

Що я хочу мінімізувати - це загальна кількість поїздок до E. Другою метою було б забезпечити, щоб жоден працівник не здійснював непропорційну кількість поїздок.

Спасибі заздалегідь!!


2
Середня кількість поїздок до E на одного працівника = "загальна кількість поїздок" / м. Отже, якщо m постійний, ваші дві цілі - одна і та ж мета. Цікавіше: я думаю, кожен працівник може одночасно носити більше одного ключа?
Doc Brown

Так, працівники можуть носити будь-яку кількість ключів. Щодо "середнього", я думаю, що я виразився погано. Я більше думав про справедливість, що жодному працівникові не доведеться виконувати непропорційну кількість поїздок, тому низька дисперсія. (відредаговано питання на відповідність)
Гарет Ллойд

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

Чи варто витрачати гроші (гроші чи час) на біржу?
Ден Пішельман

Так, більше поїздок на біржу - гірший результат.
Гарет Ллойд

Відповіді:


1

Питання є дещо неоднозначним щодо одного ключового моменту: які елементи ми намагаємося вирішити. Ми дивимось на оптимізацію порядку делегування ресурсів? Мінімізація поїздок на біржу? Максимізація пропускної здатності робочого замовлення?

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

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

Перейшовши на наступний рівень, я б розглядав адаптацію топологічного сортування ( https://en.wikipedia.org/wiki/Topological_sorting ). Моделюйте проблемний простір як великий графік (сучасні бази даних графіків також можуть бути хорошим середовищем для деяких аналізів), а потім використовуйте різні топологічні види для вирішення різних аспектів проблемного простору.

Злегка дотична це звучить як дійсно веселий проект. Сьогодні я заздрю ​​вам, пане.


Погляньте на графіки в моєму github github.com/MatheusArleson/Graphs
linuxunil

Чи допомагає алгоритм фарбування в цій ситуації? en.m.wikipedia.org/wiki/Graph_coloring
linuxunil
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.