То есть каждый из параллельных потоков решает ограниченное число случайных задач, выбирает оптимальное из решений, а после выбирается оптимальный из результатов всех потоков? Как-то это слишком случайно.
Если уж не удается метод ветвей и границ параллелить (алгоритмы распараллеливания искали?), может быть попробовать полностью просчитывать дерево решений? Пусть каждый поток рассчитывает свою ветку. Полный перебор фактически будет, зато он действительно полный и параллельный заодно.
Да, я прекрасно понимаю, что работоспособность алгоритма на самом-то деле держится чуть ли не на «честном слове», но, опять же, как показывают результаты, он умудряется выдавать даже разумные результаты, а не совсем абы что. Собственно говоря, он в полной мере соответствует понятию «эвристический алгоритм».
Недостаток метода ветвей и границ в том, что он даже в последовательной реализации довольно мерзкий и сложный. Как его паралелить — тоже вопрос. Но в конечном итоге все упирается в то, что реализовывать эту штуку надо было с использованием технологий, с которыми я ранее не работал, и если Windows Azure — это по сути тот же C#, то остальные три уже представляли собой неслабый challenge, а потому хотелось использовать что-то максимально простое в реализации. Для начала была идея использовать алгоритм муравьиной колонии, но потом пришла в голову эта идея, я ее и реализовал. У меня всегда была слабость к решениям пусть не оптимальным, но зато самостоятельно придуманным.
Алгоритм, разумеется, не претендует на какие-либо лавры и прочая, но чтобы сдать задачу преподавателю его хватило. Эту статью же я написал как некий ответ на пост «Введение в оптимизацию. Имитация отжига», так как там и в самой посте, и в комментариях к нему велись обсуждения вопроса «а если менять два города местами — что будет?». Решил, что раз уж у меня есть именно такая реализация и даже некое исследование к ней, то будет неплохо ее запостить на всеобщее обозрение.
СПбГЭТУ «ЛЭТИ», факультет компьютерных технологий и информатики, кафедра математического обеспечения ЭВМ. Но на самом деле тут скорее не в вузе дело, а в преподавателе. Он у нас молодой и еще полон желания нести свет учения в массы, вот и «развлекает» нас нетривиальными требованиями.
Я как то решал эту задачу для мобил. Есть много имплементаций метода ветвей и границ, вот тут например есть пдф-ки, которые я тогда нарыл. В итоге я решил задачу методом Литтла, вот ссылка на его оригинальную рабору. Если вы погуглите, то найдете много чего интерсного, например вот этот репозиторий. В своем решении я использовал реализацию 1972 года, которую нарыл в архиве. Клевость именно этой реализации была в том, что там не использовалось ни единого обьекта, все было сделано на массивах. Работало ну очень резво даже в эмуляторе.
Не соглашусь с Вами. Да, в моем алгоритме нет «отжига» как такового (хотя «легким движением руки» его можно соответствующим образом в оный превратить: добавить температуру и переход из одного состояния в другое осуществлять также на вероятностной основе), но тем не менее этот алгоритм гораздо ближе к отжигу, чем к ММС (по крайней мере по той причине, что ММС — это детерминированный алгоритм). Поправьте если я неправ.
Да, Вы неверно поняли задачу. Алгоритм Дейкстры находит длину кратчайшего пути из пункта А в пункт Б, при этом этот путь может быть самим ребром, соединяющим эти вершины, а путь коммивояжера должен проходить через каждую вершину графа, притом ровно по одному разу, а после этого возвращаться в начальную вершину. Алгоритм Дейкстры, к тому же, находит только расстояния между вершинами (есть, вроде, вариации алгоритма Дейкстры, которые как-то еще и путь находят, но с такими я и правда не знаком), а в моей задаче важен именно путь (последовательность вершин), по которому должен пройти коммивояжер.
Как я изобретал метод имитации отжига