Не далее как вчера применение parallel + hadleyverse позволило ускорить решение одной процессинговой задачки почти на порядок. Кода при этом стало существенно меньше.
Не далее как вчера применение parallel + hadleyverse позволило ускорить решение одной процессинговой задачки почти на порядок. Кода при этом стало существенно меньше.
Как я указал в тексте, это всего-лишь '"шпаргалка" для начала исследований по возможной оптимизации существующего кода.'
Но даже в такой простой повествовательной форме этот пост вызывает сильную неоднозначность у читающих. Я вот по оценкам статьи в целом вижу, что + и — идут в почти одинаковой пропорции. И это без каких-либо комментариев, видимо просто по первым абзацам.
Текст не совсем для новичков, а для людей, программирование для которые не является основной профессией. С текущей скоростью развития ИТ средств иногда забываешь, что требуется оптимизация и как ее лучше проводить. И когда упираешься в стену по производительности, желательно иметь подсказку, что делать.
Эти рекомендации изначально были выработаны для студентов физиков и математиков, которые занимаются сложными расчетными задачами и не погружены глубоко в детали вычислительного механизма. Не одна дипломная работа была спасена путем катастрофической оптимизации вычислений (с нескольких лет до нескольких суток), причем эти подходы применялись и в C++, и в R, и в Mathematica, и Matlab. Да, красота и четкость немного страдали, но временнОй выйгрыш того стоил.
map\walk подходы очень хороши и компактны, но надо их принять и полюбить. По моему опыту, функциональное программирование не для всех органично.
Кстати, самое интересное, что тема для очередного поста появляется в ходе дискуссий и вопросов по предыдущим. Дискуссии идут как в комментариях, так по почте. Приходится доставать кусочки кода из различных задач, решавшихся ранее, и актуализировать подходы, в соответствии с состоянием R на текущий день.
Во всем нужен разумный подход. Иногда лучше сделать с применением цикла, пусть чуть медленнее по исполнению, но зато понятнее и проще, чем сознательно пытаться обойти цикл.Это очень хорошо видно, когда студенты обучаются основам программирования.
С учетом современного развития пакетов в R очень удобно пользоваться итераторами и функциональным подходом. Естественно, что предварительно необходимо их понять и научиться легкости владения.
Современную позицию про итераторы можно почитать у Hadley: "21. Iteration"
Про какие именно алгоритмы заданы вопросы? Работа с временными рядами? Подходы к решению задачи будут сильно зависеть от характера самих рядов, например, наличие периодических составляющих.
Тут ничего нового нет, используем хорошо известное старое, но с адаптацией под особенности работы конкретных бизнес-процессов компании и информационных систем
Линейная корреляция рядов практически бесполезна, поскольку различные метрики могут иметь совершенно разные временные ряды, как по абсолютным значениям, так и по "дребезгу". Но при этом поведение ("как бы", 1-ая производная) может совпадать в фазе или в противофазе, иногда с определенной временной задержкой. Что может быть полезно с точки зрения практических упражнений?
Ссылки даю на англоязычные труды, поскольку они нашли реализацию в тех или иных пакетах R.
Предварительное сглаживание и устранение мелкого дребезга.
Построение поведенческих профилей метрик и переход от анализа абсолютных значений рядов к отклонениям от поведенческого профиля. То, что западные компании называют "deviation from baseline & behavior analysis". (см., например, Anomaly Detection Using Elasticsearch)
Поиск нетипичных значений и выбросов. Например, можно начать читать с twitter GitHub
Поиск точек смена поведения (change point analysis). Можно почитать статью
Немного погружаемся в архитектуру ОС и железа. Очень интересные методики созданы Brendan Gregg, можно начать знакомиться с его сайта
Если еще говорить о плюсах-минусах, то не всех может устраивать однопоточность ядра R. Прямой перенос произвольного кода на многопроцессорные\многоядерные системы ничего не даст в производительности.
Это не то, чтобы критичный момент, но некоторых может напрячь. Способы решения известные. Есть различные математические библиотеки (OpenBLAS，Intel MKL，NVIDIA cuBLAS) для проведения расчетов в параллельных режимах, в т.ч. не только на CPU, но и на GPU, есть пакеты R для программирования параллельных вычислений.
Мне, почему-то кажется, что поскольку смотрите неспешно и без экспериментов, то у Вас нет задач, которые не решаются текущими инструментами. Значит R просто Вам не нужен. Для академического интереса можно почитать книги Hadley Wickham, они доступны в электронном виде на его сате, раздел Teaching. R трудно использовать эффективно, пока не изучишь внутренности и не освоишь логику и не набьешь шишек.
Для задач "Hello world" все языки, включая ассемблер и бейсик одинаково хороши.
Как я написал в самом начале, постараюсь отвечать на все комментарии. Но в данном случае, я даже теряюсь, что можно ответить, и нужен ли ответ спрашивающему. Тем не менее.
Конкретно на хабре про R написано мало. А если и написано, то в разрезе математических вычислений. Я затронул вопросы о расширении предметной области. Привёл успешный опыт применения R для решения проблем обычных бизнес-пользователей.
Что именно подразумевается под примером? И в этой публикации и в предыдущей и последующей речь идёт о конкретных бизнес-примерах. С описанием задачи, схемы решения, примерами скриншотов и используемых инструментах. Также, в комментариях есть представитель одной из компаний, который, кстати, приглашал на референс-визит :).
Обычно "не интересно" и "скучно" используют тогда, когда смотрят по диагонали либо по верхам. Но, сложно не согласиться, что ни одно дело, будь то коммерция, автосервис, производство, обучение или что иное, не может быть скучным при серьёзном погружении. Всегда возникает столько нюансов, тонких моментов и новых знаний, в т.ч. в смежных областях, что можно говорить о чем угодно, кроме "не интересно".
По тексту приведено множество ссылок, в т.ч. на проекты, собранные на R+Shiny, и пакеты, исходники большинства которых доступны на GitHub. Исходники являются полным ответом на вопрос что сделали и как, можно поглядеть и туда.
С учётом того, что Вы не прошли равнодушно мимо этой темы, могу предположить, что есть несколько возможных на то причин:
Вам эта тема конкретно интересна, но Вы ожидали увидеть "на блюдечке" полное детальное решение ровно задачи, которая есть у Вас. Так, чтобы совсем не думать.
Вам эта тема абстрактно интересна, но нет никакой задачи, которую можно было бы попробовать решить приведённым подходом.
Вам эта тема совершенно безразлична, а комментарий написан "просто так" без чтения текста. Подбросить угольку "в топку".
Надеюсь, что я по всем пунктам ошибся и у Вас действительно есть задача, которую Вы можете здесь сформулировать и которая может быть решена приведёнными инструментами и методами. По конкретике, если считаете, что она неинтересна сообществу, можно и по хабр-почте списаться, например.
в контексте новичков я совершенно согласен.
У меня data.table не "пошел", да и задач для его специального применения не было.
Ускорять с суток до секунд разумно, в этом случае можно искать альтернативные подходы.
Ускорять с десятков секунд до секунд — ну только, если действительно никак нельзя подождать.
Но не упомянуть было бы неправильно.
Опять же, рядом упомянут и tibble.
А списывать data.table не стоит, в репозитории 9К пакетов, наверняка у половины из них есть активные пользователи.
Опасное заявление. Есть множество сторонников data.table и для ряда задач он действительно гораздо быстре. Люди в Яндексе, например, его любят. В целом, это хорошо, что есть альтернативные сосуществующие подходы. Но по простоте и широте подходов dplyr действительно выглядит лучше.
Евгений, добрый день.
В мой не входит, поскольку мне более интересно смотреть на задачи на стыке с бизнесом, чем писать низкоуровневые компоненты.
Если можете расширить список полезными для широкого круга на Ваш взгляд пакетами, допишите, пожалуйста, в комментарии, а я потом перетащу в текст.
pacman, как devtools начинают требоваться, когда занимаешься постоянными инсталляциями R на разных машинах\серверах.
Поэтому и не стал их упоминать с базовом списке.
Вряд-ли получится дождаться. Их в интернете есть множество, нет смысла дублировать. А вот если есть конкретная задача, то можно попробовать накидать костяк и на ее примере обсудить тонкие или непонятные моменты.
Новый термин — Tidyverse, который полезно взять на заметку.
Не далее как вчера применение parallel + hadleyverse позволило ускорить решение одной процессинговой задачки почти на порядок. Кода при этом стало существенно меньше.
Новый термин — Tidyverse, который полезно взять на заметку.
Не далее как вчера применение parallel + hadleyverse позволило ускорить решение одной процессинговой задачки почти на порядок. Кода при этом стало существенно меньше.
Как я указал в тексте, это всего-лишь '"шпаргалка" для начала исследований по возможной оптимизации существующего кода.'
Но даже в такой простой повествовательной форме этот пост вызывает сильную неоднозначность у читающих. Я вот по оценкам статьи в целом вижу, что + и — идут в почти одинаковой пропорции. И это без каких-либо комментариев, видимо просто по первым абзацам.
Текст не совсем для новичков, а для людей, программирование для которые не является основной профессией. С текущей скоростью развития ИТ средств иногда забываешь, что требуется оптимизация и как ее лучше проводить. И когда упираешься в стену по производительности, желательно иметь подсказку, что делать.
Эти рекомендации изначально были выработаны для студентов физиков и математиков, которые занимаются сложными расчетными задачами и не погружены глубоко в детали вычислительного механизма. Не одна дипломная работа была спасена путем катастрофической оптимизации вычислений (с нескольких лет до нескольких суток), причем эти подходы применялись и в C++, и в R, и в Mathematica, и Matlab. Да, красота и четкость немного страдали, но временнОй выйгрыш того стоил.
map\walk подходы очень хороши и компактны, но надо их принять и полюбить. По моему опыту, функциональное программирование не для всех органично.
Кстати, самое интересное, что тема для очередного поста появляется в ходе дискуссий и вопросов по предыдущим. Дискуссии идут как в комментариях, так по почте. Приходится доставать кусочки кода из различных задач, решавшихся ранее, и актуализировать подходы, в соответствии с состоянием R на текущий день.
Я сознательно не стал писать такую формулировку.
Во всем нужен разумный подход. Иногда лучше сделать с применением цикла, пусть чуть медленнее по исполнению, но зато понятнее и проще, чем сознательно пытаться обойти цикл.Это очень хорошо видно, когда студенты обучаются основам программирования.
С учетом современного развития пакетов в R очень удобно пользоваться итераторами и функциональным подходом. Естественно, что предварительно необходимо их понять и научиться легкости владения.
Современную позицию про итераторы можно почитать у Hadley: "21. Iteration"
Это уже следующий шаг, выход за рамки R.
Кстати, далеко ходить не надо.
Весьма интересная ссылка: "Monitoring R Applications with RZabbix"
и демо на Shiny app
Про какие именно алгоритмы заданы вопросы? Работа с временными рядами? Подходы к решению задачи будут сильно зависеть от характера самих рядов, например, наличие периодических составляющих.
Тут ничего нового нет, используем хорошо известное старое, но с адаптацией под особенности работы конкретных бизнес-процессов компании и информационных систем
Линейная корреляция рядов практически бесполезна, поскольку различные метрики могут иметь совершенно разные временные ряды, как по абсолютным значениям, так и по "дребезгу". Но при этом поведение ("как бы", 1-ая производная) может совпадать в фазе или в противофазе, иногда с определенной временной задержкой. Что может быть полезно с точки зрения практических упражнений?
Ссылки даю на англоязычные труды, поскольку они нашли реализацию в тех или иных пакетах R.
Предварительное сглаживание и устранение мелкого дребезга.
Прогнозирование. Можно ознакомиться с сайтом и трудами Rob J Hyndman, автором пакета forecast.
Также можно прочитать его книгу "Forecasting: principles and practice"
Построение поведенческих профилей метрик и переход от анализа абсолютных значений рядов к отклонениям от поведенческого профиля. То, что западные компании называют "deviation from baseline & behavior analysis". (см., например, Anomaly Detection Using Elasticsearch)
Поиск нетипичных значений и выбросов. Например, можно начать читать с twitter GitHub
Поиск точек смена поведения (change point analysis). Можно почитать статью
Если еще говорить о плюсах-минусах, то не всех может устраивать однопоточность ядра R. Прямой перенос произвольного кода на многопроцессорные\многоядерные системы ничего не даст в производительности.
Это не то, чтобы критичный момент, но некоторых может напрячь. Способы решения известные. Есть различные математические библиотеки (OpenBLAS，Intel MKL，NVIDIA cuBLAS) для проведения расчетов в параллельных режимах, в т.ч. не только на CPU, но и на GPU, есть пакеты R для программирования параллельных вычислений.
Подобная деятельность?: Spurious correlations
Мне, почему-то кажется, что поскольку смотрите неспешно и без экспериментов, то у Вас нет задач, которые не решаются текущими инструментами. Значит R просто Вам не нужен. Для академического интереса можно почитать книги Hadley Wickham, они доступны в электронном виде на его сате, раздел Teaching. R трудно использовать эффективно, пока не изучишь внутренности и не освоишь логику и не набьешь шишек.
Для задач "Hello world" все языки, включая ассемблер и бейсик одинаково хороши.
с учетом существующих пакетов возможны различные варианты для совершенства:
Вариант 1 (итераторы)
Вариант 2 (функциональный подход и pipes)
Как я написал в самом начале, постараюсь отвечать на все комментарии. Но в данном случае, я даже теряюсь, что можно ответить, и нужен ли ответ спрашивающему. Тем не менее.
С учётом того, что Вы не прошли равнодушно мимо этой темы, могу предположить, что есть несколько возможных на то причин:
Надеюсь, что я по всем пунктам ошибся и у Вас действительно есть задача, которую Вы можете здесь сформулировать и которая может быть решена приведёнными инструментами и методами. По конкретике, если считаете, что она неинтересна сообществу, можно и по хабр-почте списаться, например.
в контексте новичков я совершенно согласен.
У меня
data.tableне "пошел", да и задач для его специального применения не было.Ускорять с суток до секунд разумно, в этом случае можно искать альтернативные подходы.
Ускорять с десятков секунд до секунд — ну только, если действительно никак нельзя подождать.
Но не упомянуть было бы неправильно.
Опять же, рядом упомянут и
tibble.А списывать
data.tableне стоит, в репозитории 9К пакетов, наверняка у половины из них есть активные пользователи.Опасное заявление. Есть множество сторонников
data.tableи для ряда задач он действительно гораздо быстре. Люди в Яндексе, например, его любят. В целом, это хорошо, что есть альтернативные сосуществующие подходы. Но по простоте и широте подходовdplyrдействительно выглядит лучше.googleVis сам не использую, но включил
Евгений, добрый день.
В мой не входит, поскольку мне более интересно смотреть на задачи на стыке с бизнесом, чем писать низкоуровневые компоненты.
Если можете расширить список полезными для широкого круга на Ваш взгляд пакетами, допишите, пожалуйста, в комментарии, а я потом перетащу в текст.
pacman, какdevtoolsначинают требоваться, когда занимаешься постоянными инсталляциями R на разных машинах\серверах.Поэтому и не стал их упоминать с базовом списке.
К
pacmanя бы добавил еще иgithubinstallВряд-ли получится дождаться. Их в интернете есть множество, нет смысла дублировать. А вот если есть конкретная задача, то можно попробовать накидать костяк и на ее примере обсудить тонкие или непонятные моменты.