Почему функция c () принимает недокументированный аргумент?

17

Документация для базовой функции c() показывает свои аргументы по умолчанию как

c(..., recursive = FALSE)

Теперь, если мы определим

lst <- list(x = 1:5, y = 6:10)

, а затем соедините список с

c(lst, recursive = TRUE)
# x1 x2 x3 x4 x5 y1 y2 y3 y4 y5 
#  1  2  3  4  5  6  7  8  9 10 

список сбрасывается, а имена сохраняются.

Но мы также можем использовать другой недокументированный аргумент use.names для удаления имен.

c(lst, recursive = TRUE, use.names = FALSE)
# [1]  1  2  3  4  5  6  7  8  9 10

Почему не use.names задокументировано как один из аргументов c() ?

    
задан Rich Scriven 18.07.2014 в 02:17
источник
  • . Чтобы закрыть цикл на этом, use.names = in c () был зарегистрирован в R 3.3.2 (cran.r-project.org/doc/manuals/r-devel/NEWS.html). На этом есть поток на r.789695.n4.nabble.com/... –  Peter Ellis 14.01.2017 в 06:02

2 ответа

10

Я думаю, что это связано с recursive=TRUE , которое, я считаю, должно использовать тот же код, что и unlist . Параметр use.names описан в ?unlist .

    
ответ дан 42- 18.07.2014 в 02:31
  • Они, кажется, имеют неперекрывающиеся кодовые пути в источнике. –  MrFlick 18.07.2014 в 02:34
  • Я видел это. Интересно, было ли это случайное включение? Поведение c (..., recursive = TRUE), безусловно, похоже, имитирует то, что я обычно использую unlist для выполнения. –  42- 18.07.2014 в 02:36
  • В какой-то момент Prof Ripley сказал, что c () и unlist () 'shared code': markmail.org/search/... –  42- 18.07.2014 в 02:42
  • @BondedDust - Хороший улов! Здесь, с 30 июля 1998 года, здесь do_c делится на do_c и do_unlist. –  Josh O'Brien 18.07.2014 в 03:07
  • Код ранее был разделен, но был (длительное время) разделен. Параметр use.names, по-видимому, остался в том случае, когда это произошло, но не задокументировано. –  42- 18.07.2014 в 05:41
Показать остальные комментарии
3

c - это общая функция S4, что означает, что в зависимости от ее аргументов вызывается другая функция.

Не все из этих функций принимают аргумент use.names , поэтому нет смысла документировать его в документации для c() .

    
ответ дан merlin2011 18.07.2014 в 02:27
  • Это странно, что в функции по умолчанию do_c_dflt, но это не такой документ, как «рекурсивный». В исходном коде они не обрабатываются иначе. –  MrFlick 18.07.2014 в 02:30
  • Я не покупаю это объяснение (или, по крайней мере, я не буду без каких-либо дополнительных доказательств!) Вот почему: (1) c () является такой же функцией S3, как и функция S4; сравните результаты методов («c») и showMethods («c») в новой сессии R. (2) рекурсивный = более универсально не поддерживается методами c (), чем use.names =; что рекурсивное = делать в c.numeric_version ()? (3) Генераторы S4 часто имеют всего несколько аргументов, они, как правило, документируются; почему исключение здесь, когда use.names является одним из трех формальных аргументов, переданных в базовую функцию C? –  Josh O'Brien 18.07.2014 в 02:45
  • c - примитивная функция, а не S4! –  lebatsnok 01.09.2014 в 14:39
  • @lebatsnok. Если вы посмотрите на вывод «c», он говорит, что это примитивная функция, но она также говорит далее о том, что эта функция является общей для S4. –  merlin2011 01.09.2014 в 18:49
  • @merlin - я думаю, страница справки запутывает здесь. вы можете определить методы S4 для c (я пробовал, он работает) с помощью setMethod, но вы также можете определить методы S3. Когда вы определяете общий вид S4 обычным способом и называете его, скажем, foo, то isS4 (foo) будет TRUE. Не для c. –  lebatsnok 01.09.2014 в 21:08
Показать остальные комментарии