Что делать с несовершенными, но полезными функциями?

Я мог бы точно так же озаглавить этот вопрос: «Достаточно ли этого для CRAN?»

У меня есть набор функций, которые я создал для конкретных задач. Некоторые из них - вспомогательные функции:

# Returns odds/evens from a vector
odds=function(vec) {
    stopifnot(class(vec)=="integer")
    ret = vec[fpart(vec/2)!=0]
    ret
}
evens=function(vec) {
    stopifnot(class(vec)=="integer")
    ret = vec[fpart(vec/2)==0]
    ret
}

Некоторые из них представляют собой незначительные дополнения, которые оказались полезными при ответе на распространенный вопрос SO:

# Shift a vector over by n spots
# wrap adds the entry at the beginning to the end
# pad does nothing unless wrap is false, in which case it specifies whether to pad with NAs
shift <- function(vec,n=1,wrap=TRUE,pad=FALSE) {
    if(length(vec)<abs(n)) { 
        #stop("Length of vector must be greater than the magnitude of n \n") 
    }
    if(n==0) { 
        return(vec) 
    } else if(length(vec)==n) { 
        # return empty
        length(vec) <- 0
        return(vec)
    } else if(n>0) {
        returnvec <- vec[seq(n+1,length(vec) )]
        if(wrap) {
            returnvec <- c(returnvec,vec[seq(n)])
        } else if(pad) {
            returnvec <- c(returnvec,rep(NA,n))
        }
    } else if(n<0) {
        returnvec <- vec[seq(1,length(vec)-abs(n))]
        if(wrap) {
            returnvec <- c( vec[seq(length(vec)-abs(n)+1,length(vec))], returnvec )
        } else if(pad) {
            returnvec <- c( rep(NA,abs(n)), returnvec )
        }

    }
    return(returnvec)
}

Наиболее важными являются расширения существующих классов, которые нельзя найти где-либо еще (например, функция панели CDF для графиков решетки, различные функции вывода xtable и LaTeX, классы для обработки и преобразования между типами геопространственных объектов и выполнения различных операций, подобных ГИС, таких как как накладки).

Я хотел бы сделать их доступными где-нибудь в Интернете в R-ized форме (например, размещение их в блоге, поскольку функции обычного текста - это не то, что я ищу), чтобы упростить обслуживание и чтобы я и другие могли получить доступ их с любого компьютера, к которому я захожу. Логично сделать из них пакет и отправить в CRAN - и действительно, они у меня уже упакованы. Но подходит ли этот набор функций для пакета CRAN?

У меня две основные проблемы:

  1. Кажется, что у функций нет какого-либо связного наложения. Это просто набор функций, которые делают много разных вещей.
  2. Мой код не всегда самый красивый. Я пытался очистить его, изучая лучшие методы кодирования, но создание красивого кода, достойного R Core, не подходит.

На веб-странице CRAN на удивление отсутствуют инструкции по размещению сообщений. Следует ли мне публиковать сообщения в CRAN, учитывая, что некоторые люди сочтут это полезным, но в каком-то смысле навсегда заблокируют R, чтобы он использовал некоторые довольно простые имена функций? Или есть другое место, где я могу использовать команду, похожую на install.packages, для установки? Обратите внимание: я бы предпочел не размещать пакет на веб-странице и не заставлять людей запоминать URL-адрес для установки пакета (не в последнюю очередь для проблем с контролем версий).


person Ari B. Friedman    schedule 26.07.2011    source источник


Ответы (3)


Большинство пакетов должны быть коллекциями связанных функций с очевидной целью, поэтому полезно было бы попытаться сгруппировать то, что у вас есть, и посмотреть, сможете ли вы их классифицировать. Несколько меньших пакетов лучше, чем один огромный бессвязный пакет.

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

Что касается написания красивого кода, самое важное, что вы можете сделать, - это использовать руководство по стилю.

person Richie Cotton    schedule 26.07.2011
comment
Я уже группировал функции, когда создавал файлы справки, поэтому я мог добавить еще один уровень агрегации и выпустить их как серию небольших пакетов для CRAN, а также написать некоторые другие пакеты, которые расширяют мои классы, и посмотреть, будут ли они: Я бы добавил одну или две функции. Однако я бы побеспокоился, что переполну CRAN небольшими ненужными пакетами, но я понимаю, что это может быть предпочтительнее. - person Ari B. Friedman; 26.07.2011
comment
@ AriB.Friedman Я бы не стал беспокоиться о маленьком размере пакетов. Небольшие пакеты легче обслуживать, и они с меньшей вероятностью сломаются в будущем. Самая большая проблема для CRAN - это код, который ломает и особенно ломает код в обратных зависимостях пакета. - person Thomas; 17.08.2016

Я бы использовал http://r-forge.r-project.org/. Сверху страницы:

R-Forge предлагает центральную платформу для разработки пакетов R, программного обеспечения, связанного с R, и других проектов. Он основан на FusionForge, предлагая легкий доступ к лучшим в SVN, ежедневно создаваемым и проверяемым пакетам, спискам рассылки, отслеживанию ошибок, доскам объявлений / форумам, хостингу сайтов, постоянному архивированию файлов, полным резервным копиям и общему веб-администрированию.

person Roman Luštrik    schedule 26.07.2011
comment
Похоже, это неплохо позаботится о проблемах с версией. Вот моя главная проблема. Когда я кого-то учу, я часто говорю: «А потом вы просто используете эту функцию в этом пакете». Чтобы установить его, введите ____. Насколько сложно ____, если мой пакет находится в R-Forge? - person Ari B. Friedman; 26.07.2011
comment
install.packages("mypackage",repos="http://r-forge.r-project.org"). Единственная проблема, с которой я столкнулся при использовании R-forge для обучающих пакетов и т. Д., Заключается в том, что изменения в r-forge не распространяются на собранные пакеты в течение 24 часов, поэтому я иногда прибегал к публикации самые последние версии пакетов в моем собственном репозитории. - person Ben Bolker; 26.07.2011
comment
@Ben: Определенно лучше, чем ставить его где-нибудь на сервере. Спасибо. Я либо сделаю это, либо просто перейду на CRAN, возможно, разделив на более мелкие пакеты согласно подсказке Ричи. - person Ari B. Friedman; 26.07.2011
comment
@Ben Некоторое время назад я обнаружил, что размещение кода в googlecode и связывание svn с r-forge было отличным вариантом. Вы можете предоставить двоичные файлы в googlecode, когда r-forge занимает слишком много времени; в противном случае вы получите удобство install.packages(). Однако похоже, что r-forge больше не предлагает эту возможность. Может быть, разработчикам удастся снова включить его? - person baptiste; 27.07.2011
comment
@ gsk3: У меня смешанные чувства по поводу разделения на орду более мелких пакетов. Гигантские непоследовательные пакеты раздражают, но (для меня) я устанавливаю целую кучу крошечных кросс-зависимых пакетов (хотя это лучше, чем пакеты, которые влекут за собой целую серию больших жирных зависимостей, особенно тех, которые требуют бинарных компонентов для конкретной платформы. ..) - person Ben Bolker; 27.07.2011
comment
@Ben: Я подозреваю, что между ними есть хороший баланс. В любом случае, у меня не хватает духу пройти и разделить это на части. Я сижу на этом коде много лет и просто хотел бы опубликовать его. Можно много сказать о подходе Stata, когда вы можете выпускать по одной функции за раз (но еще больше можно сказать против него!). - person Ari B. Friedman; 27.07.2011
comment
Откровенно говоря, рекомендую либеральное подчинение. Будь то 1, 2 или 3 пакета, не имеет большого значения. Со временем все наладится за счет общего рефакторинга. Доступ к хорошему коду - отличная экономия времени. У меня есть 10-20 вспомогательных функций, которые я в конечном итоге выпущу в одном пакете. Некоторые из этих вещей должны быть в базе R, но разработчики R Core могли не подумать об этом. По крайней мере, наличие кода в одном (или двух или трех) центральных репозиториях упрощает его просмотр и включение. - person Iterator; 01.08.2011

На мой взгляд, не стоит превращать материал этого типа в пакеты.
Разные пакеты действительно существуют, но в основном по историческим причинам и / или из-за их авторитетных участников, см. Фрэнк Харрелл Hmisc.

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

  1. Всего на CRAN всего 7000 пакетов. Маловероятно, что ваш пакет будет выбран, если он не нацелен на конкретное поле, и даже когда это произойдет, очень возможно, что другие установленные пакеты сделают то же самое. Поэтому ваша упаковка также должна содержать оригинальное / лучшее решение проблемы, с которой она связана.

  2. Репозитории, и в частности CRAN, ориентированы на задачи, что предполагает, что функции пакетов должны решать согласованную задачу. И на то есть веская причина: нет смысла загружать целый пакет, скажем, с 50 автономными функциями, когда мне нужна всего пара из них. Вместо этого, если пакет решает конкретную мою проблему с данными, мне, скорее всего, понадобится большинство (если не все) из них.

  3. Репозитории R имеют тенденцию маскировать контент. В отличие от технических блогов, вы не сразу видите источник функций. Вам необходимо загрузить отдельный пакет с исходным кодом, а из-за структуры пакета возникает много накладных расходов, которые скрывают фактические функции, которые вы хотите показать, и другие, которые необходимо прочитать.

На мой взгляд, лучшее место для общих функций удобства - это такие сайты, как GitHub. По факту:

  1. Их сразу же читают с удобством подсветки синтаксиса. Если они интересны, их можно вставить в R, чтобы попробовать, и, возможно, оставить их, в противном случае можно просто перейти к чтению следующей функции.

  2. Есть возможность систематизировать код, но без всех ограничений реального пакета. Подобные функции могут находиться в одном файле, а связанные файлы - в одной подпапке.

  3. Вы можете просто показать свои идеи другим. Файл readme может сразу стать своего рода мини-страницей (через разметку). В сравнении с этим CRAN довольно жесткий.

Есть много других преимуществ (история изменений, принятие вкладов, страницы GitHub), которые могут вас заинтересовать, а могут и не заинтересовать.

Конечно, после того, как несколько функций вырастут в стабильном последовательном направлении, вы превратите их в настоящий CRAN-пакет. Также потому, что метод копирования и вставки становится неудобным.

РЕДАКТИРОВАТЬ: В настоящее время существуют альтернативы GitHub, которые также можно принять во внимание, и GitHub стал обычным способом распространения пакетов, еще не готовых для CRAN, или интеграции официальной страницы распространения CRAN.

person antonio    schedule 14.08.2016