Отладка lapply/sapply вызовы
Большинство приложений достаточно просто быть решенным в нормальном OO пути
OO, пути не всегда были "нормальны". Стандарт этого десятилетия был маргинализованным понятием прошлого десятилетия.
Функциональное программирование является математикой. Paul Graham на Lisp (заменяют функциональным программированием Lisp):
, Таким образом, короткое объяснение того, почему этот язык 1950-х не является устаревшим, состоит в том, что это не была технология, но математика, и математика doesn’t становится устаревшей. Правильной вещью сравнить Lisp с не являются аппаратные средства 1950-х, но, скажем, алгоритм Quicksort, который был обнаружен в 1960 и является все еще самым быстрым видом общего назначения.
7 ответов
Используйте стандартные методы отладки R, чтобы останавливаться точно при возникновении ошибки:
options(error = browser)
или
options(error = recover)
Когда закончите, вернитесь к стандартному поведению:
options(error = NULL)
Если вы заключите внутреннюю функцию с помощью оператора try (), вы получите дополнительную информацию:
> sapply(x, function(x) try(1/x))
Error in 1/x : non-numeric argument to binary operator
[1] "-0.5"
[2] "Error in 1/x : non-numeric argument to binary operator\n"
[3] "Inf"
[4] "1"
[5] "0.5"
В этом случае вы можете увидеть, какой индекс не работает.
Используйте пакет plyr с .inform = TRUE :
library(plyr)
laply(x, function(x) 1/x, .inform = TRUE)
Вы можете отладить () функцию или поместить браузер () внутрь тела. Это особенно полезно, если у вас нет огромного количества итераций для работы.
Кроме того, я лично этого не делал, но подозреваю, что вы могли бы включить browser () как часть tryCatch (), чтобы при возникновении ошибки вы могли использовать интерфейс browser ().
Использование отладки или браузера в этом случае не является хорошей идеей, потому что это будет очень часто останавливать ваш код. Вместо этого используйте Try или TryCatch и устраняйте возникающие ситуации.
Как сказал Джеффджентри:
> sapply(x, function(x) {
res <- tryCatch(1 / x,
error=function(e) {
cat("Failed on x = ", x, "\n", sep="") ## browser()
stop(e)
})
})
Кроме того, цикл for можно было бы переписать, чтобы он стал намного чище (возможно, немного медленнее):
> y <- NULL
> for (xi in x)
y <- c(y, 1 / xi)
Error in 1/xi : non-numeric argument to binary operator
Циклы For в R медленные, но если вы действительно мне нужна скорость, я бы пошел с простым итеративным подходом вместо запутанного понимания списка.
Если мне нужно выяснить какой-то код на лету, я всегда пойду:
sapply(x, function(x) {
browser()
...
})
И напишу код изнутри функции так что я вижу, что получаю.
- Дэн
Я столкнулся с той же проблемой и, как правило, выполнял свои вызовы с помощью (l) (m) (s) (t) применительно к функциям, которые я могу отлаживать () .
Итак, вместо blah <-sapply (x, function (x) {x + 1})
я бы сказал
myfn<-function(x){x+1}
blah<-sapply(x,function(x){myfn(x)})
и использовал отладку (myfn) с параметрами (error = recovery).
Мне также нравятся советы о том, как наклеивать строки print () здесь и там, чтобы увидеть, что происходит.
Еще лучше разработать тест myfn (x), который он должен пройти, и убедиться, что он проходит, сказал протестируйте, прежде чем подвергать его сапфированию. У меня есть терпение только в половине случаев.