Comments 24
А ведь можно просто использовать графовую БД Neo4j для Python'а.
Ну здесь все же материал о том, как это все устроено по своей сути. А для задач, касающихся работы с графами, конечно, нужно выбирать наиболее удобные и быстрые инструменты.
А можете посоветовать какие-то проверенные инструменты для работы с большими графами? То есть где и как хранить, как обрабатывать, какие есть нюансы и т.д. Хотя, возможно, это на отдельную статью тянет уже, но очень хочется побольше информации о практическом опыте.
Попробуйте igraph. Это библиотека на C с провязками с Python и R. Позволяет довольно шустро обрабатывать графы с несколькими миллионами вершин и несколькими десятками миллионов рёбер на обычном ноутбуке. Умеет читать и писать несколько различных форматов. Поддерживает тьму классических и не очень алгоритмов на графах.
Для анализа и визуализации взгляните на GePhi. Совсем большие графы тянет плохо, а вот средние и малые — в самй раз
Для анализа и визуализации взгляните на GePhi. Совсем большие графы тянет плохо, а вот средние и малые — в самй раз
Спасибо, а эта библиотека позволяет работать с разными характеристиками вершин? Скажем цвет + вес.
Любой вершине и любому ребру можно сопоставить произвольное число атрибутов. Значением могут быть любые объекты языка. Числовые атрибуты можно использовать как вес. Часть алгоритмов принимает в качестве веса как имя атрибута, так и функцию, которая в динамике этот вес может выдать (например вычислить или подгрузить из базы).
«А вот как выглядит это дерево» и картинки нету, добавьте/верните её.
Спасибо, познавательно :)
Спасибо, прочитал с удовольствием, хоть и так это знал.
{c, e}, # b = {c, F}, # b ????
Перевод хромает.
«Это дает серьезное снижение скорости, но если вам действительно требуется это представление, то это его единственная проблема.»
«Если все, что делает ваш алгоритм — это обход соседних вершин, то использование объектов типа множество не просто бессмысленно: накладные расходы могут ухудшить постоянные множители в асимптотике вашей реализации»
слов «kids» — это не «дети», а «ребятишки».
для обозначения дочеринх узлов всегда и везде используется слово «children»
«Это дает серьезное снижение скорости, но если вам действительно требуется это представление, то это его единственная проблема.»
«Если все, что делает ваш алгоритм — это обход соседних вершин, то использование объектов типа множество не просто бессмысленно: накладные расходы могут ухудшить постоянные множители в асимптотике вашей реализации»
слов «kids» — это не «дети», а «ребятишки».
для обозначения дочеринх узлов всегда и везде используется слово «children»
Странно, что такой простой вещи, как Bunch до сих пор нет в «батарейках». Где-нибудь в collections, по соседству с namedtuple смотрелось бы очень хорошо. Наверняка где-то пылится соответствующий PEP.
Спасибо, хорошая, позновательная статья — как раз для изучения питона.
А на чем картинки создавались, позвольте поинтересоваться? Красивые получаются.
А на чем картинки создавались, позвольте поинтересоваться? Красивые получаются.
познавательная*
Мы делаем перевод сразу в LaTeX, так что картинки сделаны в tikz. На хабре была вводная статья о том, как с ним работать: habrahabr.ru/blogs/latex/48260/
Перевод тоже вероятно удастся выложить, когда решатся правовые вопросы. Исходник одной из картинок: pastebin.com/XJrbSHBi
А может кто-нить сказать что-то на счёт code.google.com/p/python-graph/?
Sign up to leave a comment.
Реализация графов и деревьев на Python