Очень понравилась статья. Я в ТАСС пока начал испольовать DeepPavlov, но вижу, что Natasha тоже заполнит некоторые моменты.
Есть вопрос применительно к новостям. Хорошо ли справляется выделение ФИО с приведением к норальной форме (именительный падеж)? Столкнулся с тем, что лемматизаторы косячат, не видя, что фамилия — это фамилия. Например, «Песков» будет превращен в «песок» как наиболее вероятная лемма. А сам DeepPavlov NER вроде бы не нормализует их вообще.
Вопрос в том, при выделении ФИО с помощью Natasha NER, там такие кейсы как Эрик Конггорд («конггордый»)-Андерсен, или Елена Верещака («верещак»), или Николай Борцов («борец») не искажаются? Есть ли там база фамилий или умные правила на этот случай?
Уже посмотрел по ссылке стенд NER (https://natasha.github.io/ner/): есть хорошие срабатывания, есть косячки. «Эрик Конггорд-Андерсен». Фамилию через черточку не смог осилить полностью. «Йеспер Фамме». Перепутал местами имя и фамилию. Но с случаем «Дмитрий Песков» работает хорошо. «Джимми Моралеса спросили.» Одинаково неправильно сработал DP NER и Natasha NER:
Привет! Перечитывал тут старое. Корреляции могут дать повод для арбитражной торговли, когда приращения разошлись по знаку, если корреляция положительная. Делаются разнонаправленные позиции по обоим (парам) валютам.
Немного почитав про RL, можно понять, что специфика такова, что постоянно идет OOS. Нейронка делает предсказания на новых данных, обновляет веса на накопившейся истории. Обучение не останавливается, хотя можно и остановить, если есть понимание, что это надо делать.
Не пользовался. Ну, если сделать сплит один раз и записать его в колонку, то мое решение на основе r base будет быстрее опубликованного. Но из за превращения в матрицу проигрывает. У вас без этого шага. Вижу отличное решение...
По памяти, да, понял. А вот так: попробуйте профайлер памяти (не времени) Rprof с записью памяти с очень дробным промежутком времени. Там видно, если конечно я ничего не перепутал, запуск gc очень часто.
А gc ведь очищает только точно не нужные участки памяти, например, дататейблы без ссылок на них. И вообще тог работает по своей логике, я ее не особо знаю… Может не удаляются объекты, которые он считает нужными? И может ошибается?
Со сборкой мусора — особенно при фрагментации — у R не очень.
Не уверен. Есть обсуждение этого вопроса подетальнее, ссылка на форум или SE?
Еще интересно, возможно ли технически в DT организовать «внутренние» типы данных вроде float8, float16, int8 и т.д. В pandas/numpy это сильно помогает экономить память.
Так как DT это по сути list, она использует аровские типы. Для 64-разрядного интежера я вроде ставил библиотеку, чтобы повысить с 32. Есть и другие трюки, но опять же на аровских типах. В принципе, это наверное вопрос к создателям ДТ, про такие фичи я ничего не слышал, думаю, нет этого.
По сравнению с богатством типов данных в numpy здесь проигрыш явный, да.
Очень часто использую data.table — особенно при больших объемах данных. Есть еще интересный «побочный эффект»:
Интересное замечание! Графики внутри ДТ я не строил, но в остальном полное взаимодействие с окружением, да. Испольвал также set и get внутри ДТ в родительское окружение.
И, если я не ошибаюсь, piping создает копии объектов, поэтому для DT правильнее использовать chaining.
Спасибо, я срочно почитаю про это. Не совсем уверен в ответе.
Оставлю это здесь — ДТ делает всегда копию при фильтрации в i, неважно каким стилем оформления кода это делается. Далее наступает вопрос, как gc работает с этими копиями. Вопрос не тривиальный, возился с проектами, где копии таблиц отжирали 30+ Гб оперативки, после оптимизации снизил до 10 Гб.
Да, согласен. ) Но я хотел показать, что когда есть, например, текст из разных слов или стринга с различными значениями, разделенными пробелом, как это дело спарсить. Но для буквы ваш вариант должен быть идеальным. )
В R, что for loop, что *apply функции примерно одинаково быстры (медленны), явный цикл даже получше. Есть нюансы, например, apply на матрицах, которые делать не стоит. В остальном *apply, map, for полностью взаимно заменяемы по скорости. sapply еще делает пару операций под капотом: as.vector(unlist(...)), которые замедляют.
Я понимаю, что объем про одни только классы R6 будет большой, но сам вердикт я бы сформулировал так, что на R можно писать в стиле ООП на более крутом уровне, чем в S3, хотя функциональность более родна этому языку.
Есть вопрос применительно к новостям. Хорошо ли справляется выделение ФИО с приведением к норальной форме (именительный падеж)? Столкнулся с тем, что лемматизаторы косячат, не видя, что фамилия — это фамилия. Например, «Песков» будет превращен в «песок» как наиболее вероятная лемма. А сам DeepPavlov NER вроде бы не нормализует их вообще.
Вопрос в том, при выделении ФИО с помощью Natasha NER, там такие кейсы как Эрик Конггорд («конггордый»)-Андерсен, или Елена Верещака («верещак»), или Николай Борцов («борец») не искажаются? Есть ли там база фамилий или умные правила на этот случай?
Уже посмотрел по ссылке стенд NER (https://natasha.github.io/ner/): есть хорошие срабатывания, есть косячки. «Эрик Конггорд-Андерсен». Фамилию через черточку не смог осилить полностью. «Йеспер Фамме». Перепутал местами имя и фамилию. Но с случаем «Дмитрий Песков» работает хорошо. «Джимми Моралеса спросили.» Одинаково неправильно сработал DP NER и Natasha NER:
Но, в целом, кажется, что успешнее, чем «Павлов».
Привет! Перечитывал тут старое. Корреляции могут дать повод для арбитражной торговли, когда приращения разошлись по знаку, если корреляция положительная. Делаются разнонаправленные позиции по обоим (парам) валютам.
Пожалуйста. Он работает, но нужны все последние достижения и экспертное знание. Не просто здесь всё.
Не пользовался. Ну, если сделать сплит один раз и записать его в колонку, то мое решение на основе r base будет быстрее опубликованного. Но из за превращения в матрицу проигрывает. У вас без этого шага. Вижу отличное решение...
Вы верно ухватили смысл. Все так и есть. Рад, что нашли более крутое решение! Завтра попробую его. tstrsplit? Это из библиотеки?
Сори, Код не обновил… Скоро обновлю, посмотрите.
Пытался найти инфу по связке gc и DT, инфы маловато...
Интересно, интересно. Так не делал. Спасибо.
По памяти, да, понял. А вот так: попробуйте профайлер памяти (не времени) Rprof с записью памяти с очень дробным промежутком времени. Там видно, если конечно я ничего не перепутал, запуск gc очень часто.
А gc ведь очищает только точно не нужные участки памяти, например, дататейблы без ссылок на них. И вообще тог работает по своей логике, я ее не особо знаю… Может не удаляются объекты, которые он считает нужными? И может ошибается?
Не уверен. Есть обсуждение этого вопроса подетальнее, ссылка на форум или SE?
Так как DT это по сути list, она использует аровские типы. Для 64-разрядного интежера я вроде ставил библиотеку, чтобы повысить с 32. Есть и другие трюки, но опять же на аровских типах. В принципе, это наверное вопрос к создателям ДТ, про такие фичи я ничего не слышал, думаю, нет этого.
По сравнению с богатством типов данных в numpy здесь проигрыш явный, да.
Интересное замечание! Графики внутри ДТ я не строил, но в остальном полное взаимодействие с окружением, да. Испольвал также set и get внутри ДТ в родительское окружение.
Спасибо, я срочно почитаю про это. Не совсем уверен в ответе.
Оставлю это здесь — ДТ делает всегда копию при фильтрации в i, неважно каким стилем оформления кода это делается. Далее наступает вопрос, как gc работает с этими копиями. Вопрос не тривиальный, возился с проектами, где копии таблиц отжирали 30+ Гб оперативки, после оптимизации снизил до 10 Гб.
В R, что for loop, что *apply функции примерно одинаково быстры (медленны), явный цикл даже получше. Есть нюансы, например, apply на матрицах, которые делать не стоит. В остальном *apply, map, for полностью взаимно заменяемы по скорости. sapply еще делает пару операций под капотом: as.vector(unlist(...)), которые замедляют.
Советую посмотреть пару тредов на stackexchange на эту тему, освежает ум:
stackoverflow.com/questions/5533246/why-is-apply-method-slower-than-a-for-loop-in-r
stackoverflow.com/questions/42393658/lapply-vs-for-loop-performance-r
Закон большого пальца для R: все, что можно векторизовать, надо векторизовать. Циклы по элементам вектора и строкам dataframe нам не нужны, например.
Вот это правильно. Там под капотом оверхед из-за копирования объекта, что точно давит на память.
ООП освещен, однако, совсем слабо. А как же R6?
Придется поэкспериментировать. Кроме как замены через словарь я не нашел вариантов, а без замены выглядит не очень и не приятно русским заказчикам.
У них нет, там все просто.