The two CRAN packages I'm (co)authoring, dplR and sisal, would both be OK with the change. (Cc'ing to the Maintainer of dplR and my other email address)
- Mikko On 11.02.2016 17:02, Michael Lawrence wrote: > Changing the vapply() behavior makes sense in principle. I analyzed > the CRAN code base using the R parser and found 143 instances of > calling vapply with USE.NAMES=FALSE. These would need to be inspected > to understand the consequences of the change. > > For reference: > /AzureML/R/datasets.R:226 > /BBmisc/R/toRangeStr.R:33 > /DBI/R/DBDriver.R:205 > /Kmisc/R/str_rev.R:37 > /Matrix/R/diagMatrix.R:98 > /MuMIn/R/utils-models.R:110 > /OpenMx/R/MxNamespace.R:702 > /OrthoPanels/R/opm.R:167 > /XML2R/R/utils.R:16 > /assertive.base/tests/testthat/test-utils.R:14 > /bigrquery/R/utils.r:13 > /bold/R/zzz.R:29 > /checkmate/R/checkList.r:56 > /coin/R/ExactDistributions.R:80 > /coin/R/ExactDistributions.R:97 > /coin/R/ExactDistributions.R:234 > /coin/R/SymmetryTests.R:217 > /copula/R/aux-acopula.R:950 > /covr/R/data_frame.R:13 > /covr/R/display_name.R:40 > /cplm/R/lme4_lmer.R:423 > /crunch/R/batches.R:71 > /crunch/R/batches.R:102 > /crunch/R/categorical-array.R:87 > /crunch/R/hide-variables.R:78 > /crunch/R/misc.R:68 > /crunch/R/share.R:11 > /crunch/R/shoji-catalog.R:39 > /crunch/R/show.R:88 > /crunch/R/subvariables.R:76 > /crunch/R/subvariables.R:95 > /dplR/R/common.interval.R:8 > /dplR/R/fill.internal.NA.R:47 > /dplR/R/helpers.R:3 > /dplyr/R/dataframe.R:49 > /dplyr/R/glimpse.R:38 > /dplyr/R/id.r:36 > /dplyr/R/tbl-cube.r:98 > /dplyr/R/utils.r:15 > /fulltext/R/chunks.R:352 > /fulltext/R/chunks.R:356 > /ggvis/R/transform.R:56 > /httr/R/oauth-token-utils.R:23 > /igraph/R/lazyeval.R:219 > /jsonlite/R/asJSON.data.frame.R:74 > /jsonlite/R/deparse_vector.R:26 > /jsonlite/R/simplifyDataFrame.R:14 > /jsonlite/R/unescape_unicode.R:10 > /knitr/R/utils.R:207 > /knitrBootstrap/R/knit_bootstrap.R:303 > /lazyeval/R/names.R:27 > /learningr/R/buggy_count.R:67 > /lintr/R/absolute_paths_linter.R:35 > /lintr/R/absolute_paths_linter.R:71 > /loo/R/helpers.R:13 > /loo/R/helpers.R:20 > /matconv/R/convEasySyntax.R:71 > /matconv/R/convFunctionCalls.R:11 > /matconv/R/utils.R:113 > /micropan/R/biostrings.R:80 > /micropan/R/biostrings.R:106 > /mime/R/mime.R:129 > /packrat/R/bundle.R:137 > /packrat/R/hooks.R:45 > /packrat/R/lockfile.R:56 > /pixiedust/R/sprinkle_colnames.R:66 > /plyr/R/id.r:38 > /polyCub/R/polyCub.SV.R:110 > /polyCub/R/polyCub.exact.Gauss.R:99 > /polyCub/R/polyCub.iso.R:130 > /polyCub/R/polyCub.iso.R:166 > /polyCub/R/polyCub.iso.R:168 > /pryr/R/dots.r:25 > /rappdirs/R/utils.r:39 > /rbison/R/bison.R:181 > /rcrossref/R/cr_ft_text.R:191 > /rcrossref/R/get_styles.R:16 > /rebus.base/R/internal.R:29 > /rerddap/R/info.R:73 > /rerddap/R/info.R:80 > /rerddap/R/search.R:37 > /rerddap/R/search_adv.R:64 > /reutils/R/ecitmatch.R:33 > /reutils/R/parse-docsum.R:53 > /reutils/R/utils.R:44 > /reutils/R/utils.R:51 > /reutils/R/utils.R:55 > /rgbif/R/occ_search.r:230 > /rgbif/R/zzz.r:120 > /rjstat/R/rjstat.R:75 > /rlist/R/internal.R:155 > /rnoaa/R/homr.R:140 > /rnoaa/R/storm_shp.R:42 > /roxygen2/R/template.R:27 > /rplos/R/fulltext.R:29 > /rplos/R/fulltext.R:82 > /shiny/inst/tests/test-bootstrap.r:12 > /shinyjs/inst/examples/demo/helpers.R:49 > /simcausal/R/network.R:319 > /sisal/R/sisalTable.R:806 > /sisal/R/sisalTable.R:829 > /sisal/R/sisalTable.R:853 > /sisal/R/sisalTable.R:915 > /sisal/R/sisalTable.R:924 > /sisal/R/sisalTable.R:933 > /stringdist/R/seqdist.R:130 > /stringdist/R/stringdist.R:286 > /surveillance/R/calibration_null.R:25 > /surveillance/R/calibration_null.R:185 > /surveillance/R/epidata.R:356 > /surveillance/R/epidata.R:362 > /surveillance/R/hhh4.R:311 > /surveillance/R/hhh4_methods.R:403 > /surveillance/R/hhh4_oneStepAhead.R:126 > /surveillance/R/hhh4_plot.R:419 > /surveillance/R/hhh4_plot.R:691 > /surveillance/R/hhh4_plot.R:744 > /surveillance/R/pit.R:29 > /surveillance/R/pit.R:45 > /surveillance/R/spatial_tools.R:261 > /surveillance/R/spatial_tools.R:264 > /surveillance/R/twinSIR_profile.R:229 > /surveillance/R/twinSIR_simulation.R:284 > /surveillance/R/twinSIR_simulation.R:288 > /surveillance/R/twinstim.R:212 > /surveillance/R/twinstim.R:553 > /surveillance/R/twinstim_epitest.R:188 > /surveillance/R/twinstim_helper.R:139 > /surveillance/R/twinstim_siaf.R:176 > /surveydata/R/questions.R:164 > /sweidnumbr/R/luhn_algo.R:75 > /sweidnumbr/R/oin.R:104 > /sweidnumbr/R/oin.R:134 > /sweidnumbr/R/pin.R:202 > /sweidnumbr/R/pin.R:440 > /taxize/R/gni_parse.R:29 > /taxize/inst/ignore/taxonclass.R:117 > /taxize/inst/ignore/taxonclass2.R:157 > /testthat/R/utils.r:13 > /textreuse/R/TextReuseCorpus.R:137 > /textreuse/R/minhash.R:46 > /textreuse/R/similarity.R:111 > /tidyr/R/id.R:17 > > On Tue, Feb 9, 2016 at 3:37 AM, Martin Maechler > <maech...@stat.math.ethz.ch> wrote: >>>>>>> Hervé Pagès <hpa...@fredhutch.org> >>>>>>> on Mon, 8 Feb 2016 10:48:50 -0800 writes: >> >> > Hi, >> > Both vapply() and sapply() support the 'USE.NAMES' argument. According >> > to the man page: >> >> > USE.NAMES: logical; if ‘TRUE’ and if ‘X’ is character, use ‘X’ as >> > ‘names’ for the result unless it had names already. >> >> > But if 'X' has names already and 'USE.NAMES' is FALSE, it's not clear >> > what will happen to the names. Are they going to propagate to the >> > result or not? Unfortunately, vapply() and sapply() give a different >> > answer: >> >> >> vapply(list(A="a", B=1:2), is.integer, logical(1), USE.NAMES=FALSE) >> > [1] FALSE TRUE >> >> >> sapply(list(A="a", B=1:2), is.integer, USE.NAMES=FALSE) >> > A B >> > FALSE TRUE >> >> This is very unfortunate, and I was not aware of this. >> >> You know that sapply() is an order of magnitude older than vapply() >> and you probably don't know that lapply() is also somewhat older >> than sapply() [but that part is pre-R (but S-) history ...] >> which explains part: >> >> 1) lapply() does *not* have a USE.NAMES argument and it >> always keeps names when they are there in X. >> >> 2) sapply() has been designed as "s"implified l"apply" where >> in this case "simplified" also was to mean "user-friendly" / >> "simple to use". >> For that reason, >> a) sapply() also keeps names when they are there (as lapply). >> b) If USE.NAMES=TRUE (as by default) is also constructs names >> in cases where lapply() does not contain, i.e., in case of >> character X. >> >> 3) IIRC, the goals for vapply() had been "like sapply", with two advantages: >> a. faster >> b. "error-checking" in the sense of ensuring consistent >> results of the single function calls. >> >> > Wouldn't it make sense to have vapply() and sapply() treat the >> > 'USE.NAMES' argument consistently? >> >> Yes, but from what I wrote above, I believe vapply() would have >> to change. >> >> Martin >> >> >> > The behavior of vapply() seems >> > to make more sense to me. Note that it's consistent with what mapply() >> > does: >> >> >> mapply(is.integer, list(A="a", B=1:2), USE.NAMES=FALSE) >> > [1] FALSE TRUE >> >> > If the behavior of sapply() cannot be changed, at least the man page >> > could clarify what happens when 'USE.NAMES' is FALSE, which is >> > different for each function. >> >> > Thanks, >> > H. >> >> > -- >> > Hervé Pagès >> >> > Program in Computational Biology >> > Division of Public Health Sciences >> > Fred Hutchinson Cancer Research Center >> > 1100 Fairview Ave. N, M1-B514 >> > P.O. Box 19024 >> > Seattle, WA 98109-1024 >> >> > E-mail: hpa...@fredhutch.org >> > Phone: (206) 667-5791 >> > Fax: (206) 667-1319 >> >> > ______________________________________________ >> > R-devel@r-project.org mailing list >> > https://stat.ethz.ch/mailman/listinfo/r-devel >> >> ______________________________________________ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
