Re: [Rd] inconsistency in treatment of USE.NAMES argument
> Hervé Pagès > 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
[Rd] Minor portability patch
Hi, I've used the following patch
First because re-defining strtoi is a problem, and it's named Strtoi
elsewhere.
Second because that is the sole use of strtoi that isn't Strtoi.
Third, use = instead of ==, which is bash-specific.
Additionally I must note there are a number of tests in configure.ac which
do not append x to the beginning of the string.
I have been told that it may result in undefined behaviour in some shells when
the string is empty.
If you wish, I will provide a patch for this as well.
--- src/main/character.c.orig 2016-02-03 01:59:38.0 +
+++ src/main/character.c
@@ -1561,7 +1561,7 @@ SEXP attribute_hidden do_strtrim(SEXP ca
return s;
}
-static int strtoi(SEXP s, int base)
+static int Strtoi(SEXP s, int base)
{
long int res;
char *endp;
@@ -1595,7 +1595,7 @@ SEXP attribute_hidden do_strtoi(SEXP cal
PROTECT(ans = allocVector(INTSXP, n = LENGTH(x)));
for(i = 0; i < n; i++)
- INTEGER(ans)[i] = strtoi(STRING_ELT(x, i), base);
+ INTEGER(ans)[i] = Strtoi(STRING_ELT(x, i), base);
UNPROTECT(1);
return ans;
--- configure.ac.orig 2016-02-05 17:07:44.0 +
+++ configure.ac
@@ -327,7 +327,7 @@ AC_ARG_ENABLE([lto],
if test "x${want_lto}" != xno; then
LTO=-flto
fi
-if test "x${want_lto}" == xyes; then
+if test "x${want_lto}" = xyes; then
LTOALL=-flto
fi
AC_SUBST(LTO)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Typo in C++11 Section of Writing R Extensions
Hi, I was reading through the R extensions website and noticed that the example
code at the end of the section makes references to CXX11XSTD and CXX11XFLAGS,
shouldn’t these be CXX1XSTD and CXX1XFLAGS respectfully? (on the second and
fourth line)
CXX1X=`"${R_HOME}/bin/R" CMD config CXX11X`
CXX1XSTD=`"${R_HOME}/bin/R" CMD config CXX11XSTD`
CXX="$(CXX1X) $(CXX1XSTD)"
CXXFLAGS=`"${R_HOME}/bin/R" CMD config CXX11XFLAGS`
AC_LANG(C++)
Sorry if this has been reported before,
Jonathan Lisic
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Typo in C++11 Section of Writing R Extensions
Yes you are quite correct and this is the right place for reporting errors in
the manuals. I have fixed it.
Martyn
From: R-devel on behalf of Jonathan Lisic
Sent: 09 February 2016 20:31
To: r-devel@r-project.org
Subject: [Rd] Typo in C++11 Section of Writing R Extensions
Hi, I was reading through the R extensions website and noticed that the example
code at the end of the section makes references to CXX11XSTD and CXX11XFLAGS,
shouldn’t these be CXX1XSTD and CXX1XFLAGS respectfully? (on the second and
fourth line)
CXX1X=`"${R_HOME}/bin/R" CMD config CXX11X`
CXX1XSTD=`"${R_HOME}/bin/R" CMD config CXX11XSTD`
CXX="$(CXX1X) $(CXX1XSTD)"
CXXFLAGS=`"${R_HOME}/bin/R" CMD config CXX11XFLAGS`
AC_LANG(C++)
Sorry if this has been reported before,
Jonathan Lisic
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
---
This message and its attachments are strictly confidenti...{{dropped:8}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] build fails with --enable-strict-barrier
Hi, I'm very new here and unfamiliar with R. However, I feel like I can still provide some input. This is a bug, it must not use DATAPTR. Perhaps this is a suitable replacement for these instances: xd = x[1]; A safer temporary option is to drop this flag. I am unsure whether that is acceptable though. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] problem plotting "ts" in a data.frame
Hello: I'm having trouble plotting an object of class "ts" that is in a data.frame. I can do it with(data.frame, plot(...)) but not with plot(..., data.frame); see the example below. This work around gets me past this problem. However, I thought the R Core team might want to know about this if they don't already. Thanks for all your work in making R and CRAN the great tools that they are -- and I apologize for wasting your time if you are already familiar with this. Spencer Graves > y.ts <- ts(2:4, 5) > XY <- data.frame(x1=6:8, y1=y.ts) > plot(y1~x1, XY) Error in plot.window(...) : need finite 'xlim' values In addition: Warning messages: 1: In .cbind.ts(list(...), .makeNamesTs(...), dframe = dframe, union = FALSE) : non-intersecting series 2: In min(x) : no non-missing arguments to min; returning Inf 3: In max(x) : no non-missing arguments to max; returning -Inf 4: In min(x) : no non-missing arguments to min; returning Inf 5: In max(x) : no non-missing arguments to max; returning -Inf > plot(y1, XY) Error in plot(y1, XY) : object 'y1' not found > with(XY, plot(y1)) > sessionInfo() R version 3.2.3 (2015-12-10) Platform: x86_64-apple-darwin13.4.0 (64-bit) Running under: OS X 10.11.2 (El Capitan) locale: [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8 attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] tools_3.2.3 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
