В pymorphy2 можно неизвестные слова добавить и без участия OpenCorpora, если очень нужно. Я, правда, не пробовал, но суть такая: в pymorphy2 за разбор и предсказание отвечают отдельные «юниты», в том числе за разбор по словарю (см. github.com/kmike/pymorphy2/blob/master/pymorphy2/units/by_lookup.py ). Можно подготовить XML-ку со своими дополнениями к словарю, скомпилировать ее через «pymorphy dict compile» и добавить еще один «юнит» для разбора по этому новому словарю в MorphAnalyzer (там в конструкторе параметр есть). Чтоб создать такой юнит, понадобится, видимо, просто отнаследоваться от DictionaryAnalyzer и в методе __init__ записать в атрибут .dict новый словарь (вместо того, что будет передаваться в параметрах). «Словарь» в этом случае — экземпляр pymorphy2.opencorpora_dict.wrapper.Dictionary.
Добавить этот юнит, наверное, лучше сразу за юнитом для разбора по стандартному словарю. В этом случае при разборе (склонении и т.д.) pymorphy2 попробует сначала разобрать по стандартному словарю, если не выйдет — по дополнительному, если опять не выйдет — включатся предсказатели.
Понятное дело, лучше в OpenCorpora все добавлять — но хочется думать, что этот use-case архитектурно предусмотрен :)
Кстати, то, что граф представлен массивом, очень помогло в написании pure-python читалки для него: все данные загружаются в питоний array.array и занимают ровно столько же памяти, сколько и в C++ реализации.
Спасибо! Да, в dawgdic точно такая же хитрость — алгоритм построения устроен так, что автомат, который описывает граф, внутри сразу оказывается минимизированным. Там еще что хорошо — граф внутри не на указателях построен (вроде в aot на указателях, если правильно помню), а в «double array» закодирован и лежит в памяти единым куском. Это позволяет память экономить + для кэша процессора это лучше, чем по указателям прыгать.
По структурам данных — Ахо, Ульман — «Структуры данных и алгоритмы». Про обработку текста — nlp.stanford.edu/fsnlp/, например. Если попроще, без особых деталей — то nltk.org/book/ — но там гораздо меньше все объясняется. Курсы на coursera по NLP хорошие (и от Стенфорда, и идущий сейчас от Колумбийского университета). Про детали того, как все для русского языка делается — статьи читать можно. Чтоб все понимать, хорошо бы знания тории вероятности и статистики освежить (или получить): «машинное обучение» — это большей частью то же самое, что и статистика.
Морфологический анализ — это только один небольшой шаг к тому, чтоб с текстом что-то делать, не всегда даже обязательный :)
Это планируется, но не совсем в рамках pymorphy2. Pymorphy2 просто смотрит на то, как слово написано, и выдает все разумные варианты разбора. Ну т.е. как — если просто брать первый разбор, который выдает pymorphy2, то где-то 70% слов (чуть больше) будут разобраны правильно (это если не учитывать пунктуацию, с ней 80%).
Если нужно лучше — то нужно знать, как предложения разбираются на самом деле. А для этого нужно имеющуюся неоднозначность разбора поснимать вручную сначала. И вот этим как раз занимается opencorpora.org/ — когда там все будет готово, мы будем знать:
а) какие разборы встречаются чаще (=> pymorphy2 даже без учета контекста сможет выдавать их в более точном порядке);
б) как разборов друг с другом согласуются (=> можно будет написать штуку, снимающую неоднозначность с учетом контекста).
Размеченные тексты есть также в НКРЯ ( www.ruscorpora.ru/ ), и почти все системы, о которых я знаю, натренированы именно на НКРЯ — но там все мутно с лицензией, и проект «только для своих».
Отношение такое: человек, запатентовавший алгоритм, может потенциально получить от этого выгоду, если алгоритм кто-то использует. Чтоб не поощрять патентование алгоритмов, лучше не использовать патентованные алгоритмы (и не пропогандировать их использование) — в этом случае у патентообладателя не будет возможности получить выгоду, и патентование оттого станет бессмысленным.
Про задачу — все еще не понял :) Есть N множеств чисел, в каждом множестве не более 100тыс элементов, и нужно понять, входит ли данное число в n-ное множество? Judy1 для этого хорош, это да. Можно еще какой-нибудь сжатый/разряженный bitarray найти, или двоичное дерево поиска использовать; если ошибки допустимы — можно использовать фильтр Блума (если недопустимы — то тоже можно, например, как «первый уровень», отсекать элементы, которых заведомо нет в множестве). Или задачу как-то переформулировать. Готового решения на php я в любом случае придумать не смогу, т.к. слабо в экосистеме разбираюсь.
А зачем использовать-поддерживать патентованный алгоритм (и тратить на него силы — слать патчи, например), если если много непатентованных, которые ту же задачу решат?
Почему я думаю, что есть много других вариантов, которые бы работали так же эффективно (или еще эффективнее):
вот есть какие-то массивы цифр, которые сначала хранятся в хэш-таблице (что, понятное дело, плохо). Потом вы их начинаете хранить в Judy Array и они занимают меньше памяти. Если я правильно понял графики, то было 100М цифр, которые при 4байтных данных заняли бы в простом массиве 400М. Если данные случайные, то меньше 400М они занимать и не могут — но они занимают в двух из трех Judy-массивах меньше. Значит, у данных есть какая-то структура (ну, например, большинство записей — нули). А раз у данных есть структура, то есть и более эффективные способы их хранения, чем просто массив (ну, например, разряженные матрицы).
Вы про структуру ничего не рассказываете, и ни с чем другим, кроме array, не сравниваете (который, очевидно, ужасен для хранения цифр), поэтому красивые бенчмарки и графики довольно бессмысленными кажутся. Из них можно сделать вывод, что иногда Judy Array будут работать лучше array, вот и все — а это и так вполне очевидно, иначе зачем бы биндинги делали к ним, и т.д.
Не очень интересно: снятия неоднозначности нет; слова, записанные через дефис — не разбираете правильно («человек-акула», «скажи-ка»); не open-source; словари такие же неполные, как и везде («алешенька» — женский род), склонятора нет (видимо, временно?). Не представляю, кому может понадобиться «голый» морфологический разбор в виде сервиса.
Я, понятно, лицо заинтересованное, но в github.com/kmike/pymorphy2 и словари лучше, и предсказатель умнее, и open-source все.
Ага, т.е. все-таки ветка. С ней, кстати, нужно иметь в виду, что там (в отличие от pip 1.3.1) не проверяются ssl-сертификаты при скачивании, ее обновить бы.
При установке с pypi-сервера еще, вроде бы, есть одна особенность — pip лезет еще по разным ссылкам (не разбирался каким, но вроде из long_description (часто это README) и по всем со странички Home Page, которая как url в setup.py указывается) и ищет новые версии еще и там (что замедляет установку — иногда очень сильно, а при отсутствии проверки ssl — это еще и небезопасно). Т.е., вроде бы, без pypi сервера может все работать быстрее и безопаснее. Ну так, предостережение — если используйте ветку, то лучше форкнуть и до мастера обновить ее.
С загрузкой пакетов — сделать «python setup.py sdist bdist_wheel», без «upload» — .tar.gz-шки (и, видимо, .whl-ки) появятся в папке dist рядом с setup.py (а дальше уже эти файлы куда угодно) — точно так же можно избежать выкачивания из git и прочей мороки.
Зеркало для архивов делается установкой переменной окружения PIP_DOWNLOAD_CACHE (хотя оно обычно не очень спасает, т.к. основное время все равно чаще тратится на скрейпинг ссылок c домашней странички проекта).
Но вцелом ясно, спасибо — с pypi-сервером, видимо, и правда удобнее права раздавать, + pip search заработает.
Деревья принятия решений являются удобным инструментом в тех случаях, когда требуется не просто классифицировать данные, но ещё и объяснить почему тот или иной объект отнесён к какому-либо классу.
Пробовали когда-нибудь интерпретировать то, что в деревьях принятия решений получается?) У отдельных деревьев (построенных одним из широко применяемых алгоритмов — ID3, C4.5, CART и тд) очень большая вариативность — при небольших изменениях в данных может получаться совершенно другое дерево; в таких условиях сложно говорить о какой-то интерпретации результатов. Ну т.е. интерпретировать можно; чуть данные изменились — совсем другое дерево и совсем другая интерпретация, смысл в такой интерпретации. Там не получается так, чтоб сверху дерева были более важные критерии. То, что вы же описали — это, вроде бы, ID3; у него точно те же проблемы — интерпретация работает только на примитивных примерах и редко работает в реальной жизни.
Дальше, Random Forest. Их интерпретировать, разглядывая структуру деревьев, еще сложнее, т.к. вместо одного дерева имеем много деревьев (совсем разных).
Вы описали упрощенный вариант RF, где для тренировки деревьев выбираются случайные подмножества обучающего набора. Но: в оригинальном RF для тренировки деревьев выбираются не только случайные подмножества обучающего набора, но и случайные подмножества фич (характеристик) для каждого дерева. Благодаря этому, в частности, становится возможно интерпретировать результаты RF — смотря, какие из фич оказывали большее влияние на результат, какие важнее.
Т.е. на практике RF может быть более понятным для интерпретации, чем отдельные деревья принятия решений: для каждой фичи можно вычислить хотя бы ее «важность».
1. В pip что-ли уже поддержку wheel влили? Или нужно ветку использовать, или wheel сам поддержку добавляет?
2. А без localshop нельзя? pip умеет ставить пакеты просто из папки («pip install --no-index --find-links:file:///local/dir/SomePackage»); можно еще просто путь до архива указывать, хоть локальный, хоть нет («pip install ./downloads/SomePackage-1.0.4.tar.gz»), да и листинг файлов вроде можно хоть nginx'ом, хоть «python -m http.server» отдавать (и ключиком каким-нибудь сказть pip-у там пакеты искать, pip же умеет ссылки в свободной форме скрейпить). Я сильно в вопросе не разбирался, но всегда было непонятно, почему люди хотят поднять локальный pypi сервер — может, подскажите, какие именно преимущества дает свой pypi сервер?
Незарелизенный Pillow из репозитория вполне под 3.х работает (с мелкими недочетами, правда — к примеру, exif данные из jpeg не читаются); незарелизенный South из официального репозитория ( bitbucket.org/andrewgodwin/south/overview ) — вроде как тоже должен.
Добавить этот юнит, наверное, лучше сразу за юнитом для разбора по стандартному словарю. В этом случае при разборе (склонении и т.д.) pymorphy2 попробует сначала разобрать по стандартному словарю, если не выйдет — по дополнительному, если опять не выйдет — включатся предсказатели.
Понятное дело, лучше в OpenCorpora все добавлять — но хочется думать, что этот use-case архитектурно предусмотрен :)
Ага, сравнить было бы интересно :)
Морфологический анализ — это только один небольшой шаг к тому, чтоб с текстом что-то делать, не всегда даже обязательный :)
Если нужно лучше — то нужно знать, как предложения разбираются на самом деле. А для этого нужно имеющуюся неоднозначность разбора поснимать вручную сначала. И вот этим как раз занимается opencorpora.org/ — когда там все будет готово, мы будем знать:
а) какие разборы встречаются чаще (=> pymorphy2 даже без учета контекста сможет выдавать их в более точном порядке);
б) как разборов друг с другом согласуются (=> можно будет написать штуку, снимающую неоднозначность с учетом контекста).
Размеченные тексты есть также в НКРЯ ( www.ruscorpora.ru/ ), и почти все системы, о которых я знаю, натренированы именно на НКРЯ — но там все мутно с лицензией, и проект «только для своих».
Про задачу — все еще не понял :) Есть N множеств чисел, в каждом множестве не более 100тыс элементов, и нужно понять, входит ли данное число в n-ное множество? Judy1 для этого хорош, это да. Можно еще какой-нибудь сжатый/разряженный bitarray найти, или двоичное дерево поиска использовать; если ошибки допустимы — можно использовать фильтр Блума (если недопустимы — то тоже можно, например, как «первый уровень», отсекать элементы, которых заведомо нет в множестве). Или задачу как-то переформулировать. Готового решения на php я в любом случае придумать не смогу, т.к. слабо в экосистеме разбираюсь.
Почему я думаю, что есть много других вариантов, которые бы работали так же эффективно (или еще эффективнее):
вот есть какие-то массивы цифр, которые сначала хранятся в хэш-таблице (что, понятное дело, плохо). Потом вы их начинаете хранить в Judy Array и они занимают меньше памяти. Если я правильно понял графики, то было 100М цифр, которые при 4байтных данных заняли бы в простом массиве 400М. Если данные случайные, то меньше 400М они занимать и не могут — но они занимают в двух из трех Judy-массивах меньше. Значит, у данных есть какая-то структура (ну, например, большинство записей — нули). А раз у данных есть структура, то есть и более эффективные способы их хранения, чем просто массив (ну, например, разряженные матрицы).
Вы про структуру ничего не рассказываете, и ни с чем другим, кроме array, не сравниваете (который, очевидно, ужасен для хранения цифр), поэтому красивые бенчмарки и графики довольно бессмысленными кажутся. Из них можно сделать вывод, что иногда Judy Array будут работать лучше array, вот и все — а это и так вполне очевидно, иначе зачем бы биндинги делали к ним, и т.д.
Я, понятно, лицо заинтересованное, но в github.com/kmike/pymorphy2 и словари лучше, и предсказатель умнее, и open-source все.
При установке с pypi-сервера еще, вроде бы, есть одна особенность — pip лезет еще по разным ссылкам (не разбирался каким, но вроде из long_description (часто это README) и по всем со странички Home Page, которая как url в setup.py указывается) и ищет новые версии еще и там (что замедляет установку — иногда очень сильно, а при отсутствии проверки ssl — это еще и небезопасно). Т.е., вроде бы, без pypi сервера может все работать быстрее и безопаснее. Ну так, предостережение — если используйте ветку, то лучше форкнуть и до мастера обновить ее.
С загрузкой пакетов — сделать «python setup.py sdist bdist_wheel», без «upload» — .tar.gz-шки (и, видимо, .whl-ки) появятся в папке dist рядом с setup.py (а дальше уже эти файлы куда угодно) — точно так же можно избежать выкачивания из git и прочей мороки.
Зеркало для архивов делается установкой переменной окружения PIP_DOWNLOAD_CACHE (хотя оно обычно не очень спасает, т.к. основное время все равно чаще тратится на скрейпинг ссылок c домашней странички проекта).
Но вцелом ясно, спасибо — с pypi-сервером, видимо, и правда удобнее права раздавать, + pip search заработает.
Пост про wheel — думаю да, полезно.
Пробовали когда-нибудь интерпретировать то, что в деревьях принятия решений получается?) У отдельных деревьев (построенных одним из широко применяемых алгоритмов — ID3, C4.5, CART и тд) очень большая вариативность — при небольших изменениях в данных может получаться совершенно другое дерево; в таких условиях сложно говорить о какой-то интерпретации результатов. Ну т.е. интерпретировать можно; чуть данные изменились — совсем другое дерево и совсем другая интерпретация, смысл в такой интерпретации. Там не получается так, чтоб сверху дерева были более важные критерии. То, что вы же описали — это, вроде бы, ID3; у него точно те же проблемы — интерпретация работает только на примитивных примерах и редко работает в реальной жизни.
Дальше, Random Forest. Их интерпретировать, разглядывая структуру деревьев, еще сложнее, т.к. вместо одного дерева имеем много деревьев (совсем разных).
Вы описали упрощенный вариант RF, где для тренировки деревьев выбираются случайные подмножества обучающего набора. Но: в оригинальном RF для тренировки деревьев выбираются не только случайные подмножества обучающего набора, но и случайные подмножества фич (характеристик) для каждого дерева. Благодаря этому, в частности, становится возможно интерпретировать результаты RF — смотря, какие из фич оказывали большее влияние на результат, какие важнее.
Т.е. на практике RF может быть более понятным для интерпретации, чем отдельные деревья принятия решений: для каждой фичи можно вычислить хотя бы ее «важность».
1. В pip что-ли уже поддержку wheel влили? Или нужно ветку использовать, или wheel сам поддержку добавляет?
2. А без localshop нельзя? pip умеет ставить пакеты просто из папки («pip install --no-index --find-links:file:///local/dir/SomePackage»); можно еще просто путь до архива указывать, хоть локальный, хоть нет («pip install ./downloads/SomePackage-1.0.4.tar.gz»), да и листинг файлов вроде можно хоть nginx'ом, хоть «python -m http.server» отдавать (и ключиком каким-нибудь сказть pip-у там пакеты искать, pip же умеет ссылки в свободной форме скрейпить). Я сильно в вопросе не разбирался, но всегда было непонятно, почему люди хотят поднять локальный pypi сервер — может, подскажите, какие именно преимущества дает свой pypi сервер?