Да, к этому нет вопросов, если честно.

Как раз в этом кейсе по ссылке проявились весь блеск и нищета tidyverse - там лидер by_row из purrr, но в современном purrr его уже нет

векторизация конечно бьет, но при работе со списками она будет бесполезна и тут вполне нормально заходит lapply без purrr ...  хотя я не заморачиваюсь и бывает нещадно мешаю одно с другим и не комплексую по этому поводу ))

И всю эту пуррровскую братию mapply из базы заруливает почти в два раза. Такой вот mapply:

f_mapply <- function(df) {
    do.call(mapply, c(list, df, SIMPLIFY = FALSE))
}

если пурр возвращает контролируемый тип данных, то это явно порождает дополнительные расходы на проверку
так что неудивительно
другое дело, что сколько тех расходов - профилировать надо

Есть, см https://cran.r-project.org/web/packages/purrrlyr/

Спасибо! Читал же, но забыл)

Я вот даже никогда не задумывался. Мало того, что сортировка в группах в 99% бессмысленна, так она ещё и на несколько порядков медленнее, чем первичная сортировка всего дата фрейма

Однажды Julia Silge то ли в подкасте каком-то, то ли в статье, уже не помню, сказала что-то вроде: «один из больших моих страхов, от которого я просыпаюсь ночью в холодном поту — не забыла ли я сделать ungroup(), после summarise()»

Я тогда удивился, почитал про  несколько проблем group_by(), в частности с arrange(), но глубоко копать не стал, доверившись опытным людям. С тех пор привык к ungroup().
А еще не так давно (вроде) в summarise() завезли удобный параметр:
summarise(.groups = "drop")
я его теперь почти при каждой агрегации использую

Привет, прошёл career track (состоит из курсов и задач) по R на DataCamp: Quantitative Analyst и Data Science. Сейчас продолжаю ML. До этого самооборазование- книга R, Р.Кабакофф и др. - интересные задачи, но бывает, что одно и тоже рассматривается в разных курсах разных треков по-разному

Добрый день! Есть ли здесь социологи? Нужно немного проконсультироваться по статистике и математике в качественных исследованиях

Ну по моему, одно и тоже это плюс. Руку набивает)

Есть, но https://nometa.xyz/

Проспавшись, понял, что в тех редких случаях, когда мой код не заканчивается на summarise, дальше идёт ggplot, так что I'm fine.

В это воскресенье на воскресном скRинкасте мы будем анализировать данные Марио!

https://zoom.us/j/97810834493?pwd=QnZ5YkVSWHBVdmdUdHVNeUwwd3lOQT09

Привет! Я уже писал, что мы набираем участников на летнюю школу по анализу данных. Мы закрыли набор на стартовую и среднюю программы, но продолжаем набор на продвинутую, так что если вы давно хотели разобраться с байесовской статистикой, подавайтесь! :) https://letnyayashkola.org/andan/

а сам apply чем вреден? просто в purrr как раз таки нет его аналога, насколько я помню, с матрицами получается самое то

С матрицами может и нормально. За исключением того, что он в некоторых случаях транспонирует результат, на мой взгляд, неочевидным способом. Если матрица, на выходе функции одно число, то вреда от него не будет. Да, и по скорости он был не быстрее аналогичного цикла. Может, сейчас улучшили...

если всегда хватает векторизации, то лучше векторизация, чем lapply/{purrr}, но если не хватает, то оставшаяся альтернатива — это циклы for и, ну, уж лучше использовать все-таки lapply/{purrr}, мне кажется.
{purrr} можно использовать в отрыве от tidyverse, кстати. Некоторые вещи там понятнее, чем в *apply(). Например, проще понять использование суффиксов к map_*(), чем разобраться с vapply()

Об чём и речь.