|
|
|
Хроматическое число графа
|
|||
|---|---|---|---|
|
#18+
Здравствуйте! Необходимо раскрасить граф минимальным кол-вом цветов так, чтобы смежные вершины были окрашены в разные цвета. Использовал следующий алгоритм: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. #1 color=1 #2 color=2 #3 color=3 #4 color=2 Результаты второго теста (в коде закоментированы там же и матрица смежности) при k=3 #1 color=1 #2 color=2 #3 color=3 #4 color=1 #5 color=2 #6 color=1 #7 color=2 #8 color=3 Но вершины 2 и 8 соединены ребром и они не могут иметь цвет 3. При k=4 тест проходит нормально, НО k=4 не хроматическое число данного графа его хроматич. число равно 3! Проверял на GRIN (графоанализатор http://graph-software.narod.ru/ ) м других графоанализаторах Пробовал реализовать другой алгоритм тоже перебором из книги Окулова Программировани в алгоритмах, но и он имеет ограничение и тоже показывает 4 цвета.(Также используя книгу Кристофидеса. Кстати кто читал. там для графа в котором ищется хром число методом ЗНП оно равно 3 (тоже GRIN показал ), а в примере в книге 4 тоже что то непонятно) Нет ли у вас исходников на Паскале (Дельфи) алгоритма реализующего "точный" поиск хроматического числа или ссылки на текст алгоритма (Паскаль или Дельфи). Сразу скажу что число вершин в графе не будет превышать 255 и граф представляется матрицей смежности ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2010, 20:21:56 |
|
||
|
Хроматическое число графа
|
|||
|---|---|---|---|
|
#18+
Я реализовал для поиска хроматического числа переборный алгоритм из книги Кристофидеса. Т.е ищем максимальный номер цвета и минимальный номер вершины, имеющий данный цвет и потом просматриваются смежные вершины. Единственная проблема, что алгоритм зависит от нумерации вершин, т.е при одной нумерации вершин алгоритм показывает 4 цвета, если же для данного графа изменить нумерацию вершин то он уже может найти меньшее кол-во минимальных цветов, например. 3. Я решил оптимизировать его таким образом: если способов нумерации вершин n! (где n - кол-во вершин в данном графе) то в цикле прогнать от 1 до n! код поиска минимального кол-ва цветов и каждый раз сравнивать найдено ли при этом меньшее кол-во цветов. т.е фактически я как бы каждый раз перебираю возможные нумерации вершин пока не будет найдено лучшее решение. У меня вопрос можно ли как нибудь раньше завершить прогон, а не прогонять код n! раз. Например, если я найду клик графа (наибольший клик), то кол-во вершин в клике укажет минимальное число цветов которое нужно использовать (для раскраски клика! Хроматическое число может быть больше) т.е я таким образом найду нижнюю границу А откдуа мне потом начинать раскраску после того как я найду клика с 1 вершины или со смежных вершин клика т.е вопрос в общем в том как можно оптимизировать алгоритм какие есть идеи? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2010, 21:18:11 |
|
||
|
Хроматическое число графа
|
|||
|---|---|---|---|
|
#18+
Я тоже столкнулся с подобной проблемой когда делал Графоанализатор . Вообще в этом алгоритме многое зависит от начал. По клику думаю судить нельзя. Может есть смысл начала раскрашивать вершины в клике... Насколько я знаю алгоритма сверх идеального без перебора не существует. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.04.2010, 03:31:03 |
|
||
|
|

start [/forum/topic.php?fid=16&msg=36445658&tid=1343727]: |
0ms |
get settings: |
11ms |
get forum list: |
20ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
495ms |
get topic data: |
14ms |
get forum data: |
3ms |
get page messages: |
55ms |
get tp. blocked users: |
2ms |
| others: | 229ms |
| total: | 837ms |

| 0 / 0 |
