Представление запросов функций группе R Core - программирование
Подтвердить что ты не робот

Представление запросов функций группе R Core

Какой рекомендуемый способ/рабочий процесс связаться с R Core Team, чтобы предложить запросы функций?

В разделе "запросы функций" я не просто хочу уволить что-то вроде "Я бы хотел увидеть функциональность XY, делая XY, так что было бы здорово, если бы вы пошли и реализовали это для меня", но предлагая фактический код вместо этого.

Я люблю R и готов внести свой вклад, поделиться кодом и всем. Тем не менее иногда мне сложно понять, как именно как внести свой вклад;-) Я посмотрел на R Project Developer Страница и пару раз использовал список рассылки r-devel. Особенно в отношении последнего, у меня сложилось впечатление, что это не правильное место/нежелание разрабатывать один запрос функции с фактическим кодом (который иногда может быть не более чем двумя лайнерами). Поэтому я задаюсь вопросом, есть ли для этого "лучший" или более "систематический" способ.

EDIT 2011-11-09

Меня попросили привести короткий пример:

Я активно использую S4 Reference Classes и реализовал множество небольших полезных функций для своих объектов. Одна из таких функций полезности - это своего рода функция "reset":

setRefClass(
    "A", 
    fields=list(a="numeric", b="character"),
    methods=list(
        reset=function(fields=NULL, ...){
            temp <- new("A")
            if(is.null(fields)){
                fields <- names(getRefClass("A")$fields())
            }
            sapply(fields, function(x){
                .self$field(name=x, value=temp$field(x))        
            })
            return(TRUE)
        }
    )
)

x <- new("A", a=1:10, b=letters[1:10])

x$a
x$b
x$reset(fields="a")

x$a
x$b

x$reset()
x$a
x$b

Довольно часто это не самая причудливая функция в мире, которая появляется в моем списке "oh, that missing". Плюс это может быть такая "сингулярная" функция, что разработка целого пакета иногда кажется взломаной гайкой кувалдой.

4b9b3361

Ответ 1

Это отличный вопрос. Хотя мне очень нравится R, я нахожу, что его модель разработки расстраивает время от времени. Я бы сказал, что лучшие варианты

  • отправьте исходную идею (без расширенного кода) в R-devel и посмотрите, сможете ли вы начать дискуссию/энтузиазм. Вы должны быть готовы нажать: например, мне удалось получить дополнительную проверку ошибок, включенную в sweep несколько лет назад (на самом деле она жалуется на несоответствующие измерения, а не на молчание, возвращая неправильный ответ), но только после предложения идея; ожидание в неделю; воссоздание идеи; отправка кода прототипа; тестируя его, чтобы убедиться, что он не вызвал удар производительности; дальнейшее обсуждение...
  • реализовать свою идею как дополнительный пакет. Это, конечно, намного сложнее, если вы предлагаете изменение функциональности ядра R (с другой стороны, такое изменение также будет намного сложнее, если вы его примете). С другой стороны, вы можете реализовать практически все, что захотите, в дополнительном пакете, и оно имеет ряд преимуществ. (1) Ваш код будет доступен каждому для немедленного использования (если вы публикуете в R-forge, Rforge или CRAN); (2) это способ для идей развиваться и совершенствоваться без бай-инов из ядра R; (3), даже если он никогда не будет принят в R-core, он все равно будет использоваться как пакет.
  • изменить. Попробуйте найти существующую утилиту или пакет "misc", чтобы внести свой вклад (например, я внес вклад в пакет Jim Lemon plotrix, который представляет собой компиляцию небольших утилит построения графиков), и обратитесь к сопровождающему/автору.
  • Поместите свои элементы списка пожеланий в R-трекер ошибок (с вложениями кода и т.д.). Тем не менее, они будут замечены гораздо меньшим количеством людей, чем если бы вы использовали варианты №1 или №2, и, как результат, более вероятно, что они будут томиться в трекере ошибок, даже не видя свет дня.

Ответ 2

Вы вряд ли получите новые функции в базе R самостоятельно, если я не буду интересоваться одной из R Development Team Team, или ii) является расширением существующих функциональных возможностей, которые улучшают способ его работы или делают его более эффективный и член R Core достаточно заинтересован. Конечно, вы можете найти ошибку в списке пожеланий и предоставить код, но не удивляйтесь, если R Core Team не принимает абсолютно новые функции, даже если они поставляются с кодом.

Причины этой позиции обсуждались ранее; Даже если вы предоставляете код, реализующий новую функцию X для включения в R, вы переносите нагрузку на обслуживание в R Core Team, и у этих ребят есть ограниченные ресурсы и время для этого. Основная группа R эффективно развивает базу R для своих собственных интересов/исследований/потребностей.

Поскольку пакеты R являются почти первоклассными гражданами, нет оснований даже просить R core реализовать или включить ваш код для функции X. Так, как говорили другие, реализуйте свои идеи в своем собственном пакете или внесите свой вклад к другому пакету, который уже предоставляет код, связанный с вашей новой функцией X.

Даже невероятно полезные пакеты, которые широко используются, например. data.table вряд ли попадут в базу R в краткосрочной перспективе, потому что они увеличивают сложность базы кода, имеют нагрузку на обслуживание R Core Team и/или не падают в замене существующего кода; data.table предоставляет фреймовое расширение данных, которое невероятно быстро и лучше подходит для больших наборов данных и "запросов" к этим данным. Он не совместим с кадром данных R, хотя, используя различные соглашения. Он отлично работает как пакет и может продолжать делать это как таковой, не нуждаясь в R.

Приведенное выше описывает ситуацию, поскольку я вижу ее для новых функций. Для отчетов об ошибках укажите отчет об ошибке! Затем подумайте над дальнейшим обсуждением R-Devel, указав идентификатор отчета об ошибке. Патчи, предоставленные для поддержки отчета об ошибке, облегчат исправление ошибок или добавят новые функции/улучшения. Патч должен включать в себя как источники R, нуждающиеся в изменении, так и патч для любой документации, которая должна быть изменена в результате. Патч должен быть против дерева SVN, найденного в R SVN-сервере. Как отмечает @BenBolker в комментариях, отчеты об ошибках лучше всего подаются на веб-сайте отчетности об ошибках R. Любое обсуждение ошибки в R-Devel должно быть связано с сообщением об ошибке. Таким образом, ошибки не попадают в трещины и пропущены.

Ответ 3

Обычный способ - написать пакет и получить его на CRAN. (Все объявления, отправленные в список пакетов, будут скопированы в rhelp.) Тогда использование демонстрации его продуктивного использования на rhelp (или, возможно, SO) заставит его заметить. Я думаю здесь об усилиях в течение многих лет Хэдли Уикхэма, Дирка Эддельбуэттеля, Терри Терно, Габора Гротендика, Фрэнка Харрелла и Мэтью Доула, чтобы назвать первых шести участников, которые приходят на ум, которые сделали мои усилия R более продуктивными. Фактически, когда я писал этот список, он продолжал расти, и я приношу свои извинения нескольким другим людям, которые внесли вклад, который я часто использую.

Ответ 4

При использовании R в этом году Брайан Рипли рассказал анекдот, в котором объясняется позиция команды R-core. Он сказал, что он принял двухстрочный патч к функции от уважаемого программиста R (John Chambers, если я правильно помню). Две строки кода содержали три ошибки (!), Которые он затем должен был исправить. С тех пор позиция по умолчанию R-core заключается в отказе от запросов функций для R-базы, даже с предоставленным кодом. (Запросы на исправление ошибок прекрасны, если у вас установлен высокий уровень проверки, что это действительно ошибка. Для этого используйте систему отслеживания ошибок R.

Хотя невозможно получить что-то в R-базе, почти всегда значительно (p < 1e-6) проще создать пакет самостоятельно или добавить к существующему.