Будет ли Rstan быстрее подгонять модели с данными, хранящимися в виде матрицы или data.frame?

Я подгоняю серию многоуровневых логистических регрессий, используя rstan с помощью функции map2stan в библиотеке rethinking. Все работает нормально, модели все подходят и сходятся. Однако наборы данных, с которыми я работаю, очень велики, поэтому время выполнения каждой модели довольно велико (порядка дней). Следовательно, я ищу любые потенциальные ускорения, которые я могу найти.

Прямо сейчас мои данные хранятся в data.frames, все они имеют схожую структуру с масштабируемыми непрерывными переменными и категориальными переменными, разделенными на манекены 0/1. Например:

> str(dcc.s.dummy)
'data.frame':   85604 obs. of  34 variables:
 $ COST_DIST_ECOTONE        : num  -0.594 -0.593 -0.596 -0.591 -0.591 ...
 $ COST_DIST_HEA            : num  -0.663 -0.66 -0.672 -0.652 -0.65 ...
 $ COST_DIST_HISTOSOLS      : num  -2.09 -2.09 -2.09 -2.09 -2.09 ...
 $ COST_DIST_MEDSTR         : num  -0.178 -0.176 -0.177 -0.176 -0.174 ...
 $ COST_DIST_RIV_COAST      : num  0.34 0.337 0.335 0.341 0.338 ...
 $ DEM30_ASP_RE_2           : num  0 0 0 0 0 1 0 0 0 0 ...
 $ DEM30_ASP_RE_3           : num  0 0 0 0 0 0 0 0 0 0 ...
 $ DEM30_ASP_RE_4           : num  1 0 0 1 0 0 0 0 0 1 ...
 $ DEM30_ASP_RE_5           : num  0 1 0 0 1 0 0 0 0 0 ...
 $ DEM30_M                  : num  2.19 2.19 2.2 2.18 2.19 ...
 $ DEM30_SLOPE              : num  -0.797 -0.782 -0.839 -0.817 -0.76 ...
 $ DRIFT_THICK_1            : num  0 0 0 0 0 0 0 0 0 0 ...
 $ DRIFT_THICK_2            : num  0 0 0 0 0 0 0 0 0 0 ...
 $ DRIFT_THICK_3            : num  1 1 1 1 1 1 1 1 1 1 ...
 $ DRIFT_THICK_4            : num  0 0 0 0 0 0 0 0 0 0 ...
 $ LOC_REL_RE               : num  -0.862 -0.857 -0.857 -0.845 -0.84 ...
 $ LOC_SD_SLOPE             : num  -1.08 -1.08 -1.08 -1.06 -1.06 ...
 $ SITE_NONSITE             : int  0 0 0 0 0 0 0 0 0 0 ...
 $ SSURGO_ESRI_DRAINAGE_RE_2: num  0 0 0 0 0 0 0 0 0 0 ...
 $ SSURGO_ESRI_DRAINAGE_RE_3: num  0 0 0 0 0 0 0 0 0 0 ...
 $ SSURGO_ESRI_DRAINAGE_RE_4: num  0 0 0 0 0 0 0 0 0 0 ...
 $ SSURGO_ESRI_DRAINAGE_RE_5: num  0 1 1 0 1 1 0 0 0 0 ...
 $ SSURGO_ESRI_DRAINAGE_RE_6: num  1 0 0 1 0 0 1 1 1 1 ...
 $ SSURGO_ESRI_DRAINAGE_RE_7: num  0 0 0 0 0 0 0 0 0 0 ...
 $ SSURGO_ESRI_EROSION_RE_2 : num  1 0 0 1 0 0 1 1 1 1 ...
 $ SSURGO_ESRI_EROSION_RE_3 : num  0 0 0 0 0 0 0 0 0 0 ...
 $ SSURGO_ESRI_EROSION_RE_4 : num  0 0 0 0 0 0 0 0 0 0 ...
 $ SSURGO_ESRI_EROSION_RE_5 : num  0 0 0 0 0 0 0 0 0 0 ...
 $ SSURGO_ESRI_LOC_DIV      : num  -0.184 -0.22 -0.168 -0.316 -0.322 ...
 $ SSURGO_ESRI_NATIVEVEG_2  : num  0 0 0 0 0 0 0 0 0 0 ...
 $ SSURGO_ESRI_NATIVEVEG_3  : num  0 0 0 0 0 0 0 0 0 0 ...
 $ SSURGO_ESRI_NATIVEVEG_4  : num  0 0 0 0 0 0 0 0 0 0 ...
 $ SSURGO_PH                : num  0.86 0.632 0.518 0.86 0.518 ...
 $ WATERSHED_INDEX          : int  3 3 3 3 3 3 3 3 3 3 ...

Сократит ли преобразование data.frame в matrix с помощью data.matrix(frame, rownames.force = NA) или аналогичного периода время, необходимое rstan / map2stan для завершения выборки и подбора модели?

Я сталкивался с аргументом в ряде мест, что операции, выполняемые с матрицами, как правило, быстрее, чем операции с data.frames. Rstan выполняет всю тяжелую работу на С++, поэтому, насколько мне известно, он уже выполняет аналогичное преобразование в рамках своих операций. Любое понимание или рекомендации будут оценены.


r rstan dataframe matrix logistic-regression
person lambertj    schedule 14.12.2018    source источник
comment
Я рекомендую вам попробовать оба способа и засечь время, чтобы увидеть, какой из них быстрее. Начните с меньшего набора данных, чтобы поначалу сравнение не занимало много времени.   -  person MrFlick    schedule 14.12.2018

Ответы (1)


arrow_upward
1
arrow_downward

Если время выполнения составляет порядка нескольких дней, а время компиляции — около минуты, вы не заметите, сколько времени требуется, чтобы сначала сделать что-либо на стороне R, включая то, были ли данные сохранены в виде матрицы или data.frame. .

Другими словами, в этой ситуации вам следует гораздо больше беспокоиться о том, неэффективен ли код Стэна, сгенерированный моим rethinking::map2stan, а не о том, неэффективен ли код обработки данных в переосмыслении. Поскольку переосмысление не оптимизировано для вашего варианта использования, вполне вероятно, что rstanarm, brms или написанный от руки код Stan --- особенно использование линейной алгебры, а не более скалярного алгебраического кода, сгенерированного rethinking::map2stan --- будет работать намного быстрее.

person Ben Goodrich    schedule 16.12.2018
comment
Спасибо, Бен. Это имеет большой смысл. Я займусь оптимизацией моего кода Стэна гораздо тщательнее. - person lambertj; 17.12.2018