Re: [Rd] Definition of uintptr_t in Rinterface.h
The problem is elsewhere - Rinterface.h guards the ultima-ratio fallback with HAVE_UINTPTR_T but that config flag is not exported in Rconfig.h. Should be now fixed in R-devel - please check if that works for you. Thanks, Simon > On Dec 26, 2016, at 11:25 PM, Laurent Gautier wrote: > > Hi, > > I was recently pointed out that a definition in Rinterface.h can be > conflicting > with a definition in stdint.h: > > /usr/include/R/Rinterface.h has: > typedef unsigned long uintptr_t; > > /usr/include/stdint.h has: > typedef unsigned int uintptr_t; > (when 32bit platform complete definition is: > > #if __WORDSIZE == 64 > # ifndef __intptr_t_defined > typedef long intintptr_t; > # define __intptr_t_defined > # endif > typedef unsigned long int uintptr_t; > #else > # ifndef __intptr_t_defined > typedef int intptr_t; > # define __intptr_t_defined > # endif > typedef unsigned intuintptr_t; > #endif > > ) > > Is this expected ? Shouldn't R rely on the definition in stdint.h > rather than define its own ? > > > (report for the issue: > https://bitbucket.org/rpy2/rpy2/issues/389/failed-to-compile-with-python-360-on-32 > ) > > > Laurent > > [[alternative HTML version deleted]] > > __ > 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
Re: [Rd] Definition of uintptr_t in Rinterface.h
Thanks for looking at it. Having HAVE_UINTPTR_T defined in Rconfig.h should fix the issue. Will the fix make it to R-3.3.3 (if that point release is planned, or R-3.3.2-patched), or will it only be with R-3.4 ? L. PS: I am forwarding a thank you note to the reporter of the problem on the rpy2 issue tracker. 2016-12-29 10:55 GMT-05:00 Simon Urbanek : > The problem is elsewhere - Rinterface.h guards the ultima-ratio fallback > with HAVE_UINTPTR_T but that config flag is not exported in Rconfig.h. > Should be now fixed in R-devel - please check if that works for you. > > Thanks, > Simon > > > > > On Dec 26, 2016, at 11:25 PM, Laurent Gautier > wrote: > > > > Hi, > > > > I was recently pointed out that a definition in Rinterface.h can be > conflicting > > with a definition in stdint.h: > > > > /usr/include/R/Rinterface.h has: > > typedef unsigned long uintptr_t; > > > > /usr/include/stdint.h has: > > typedef unsigned int uintptr_t; > > (when 32bit platform complete definition is: > > > > #if __WORDSIZE == 64 > > # ifndef __intptr_t_defined > > typedef long intintptr_t; > > # define __intptr_t_defined > > # endif > > typedef unsigned long int uintptr_t; > > #else > > # ifndef __intptr_t_defined > > typedef int intptr_t; > > # define __intptr_t_defined > > # endif > > typedef unsigned intuintptr_t; > > #endif > > > > ) > > > > Is this expected ? Shouldn't R rely on the definition in stdint.h > > rather than define its own ? > > > > > > (report for the issue: > > https://bitbucket.org/rpy2/rpy2/issues/389/failed-to- > compile-with-python-360-on-32 > > ) > > > > > > Laurent > > > > [[alternative HTML version deleted]] > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] colnames for data.frame could be greatly improved
> Hi there,
> Any update on this?
> Should I create bugzilla ticket and submit patch?
> Regards
> Jan Gorecki
Hi Jan,
Why should we care that the do.NULL = FALSE case is slower?
After all do.NULL = TRUE is the default.
In other words, where are use cases where it is problematic that
do.NULL = FALSE is relatively slow?
Shorter code *is* nicer than longer code, so I need a bit more
conviction why we should add more code for that special case ..
Martin Maechler, ETH Zurich
> On 20 December 2016 at 01:27, Jan Gorecki wrote:
> > Hello,
> >
> > colnames seems to be not optimized well for data.frame. It escapes
> > processing for data.frame in
> >
> > if (is.data.frame(x) && do.NULL)
> > return(names(x))
> >
> > but only when do.NULL true. This makes huge difference when do.NULL
> > false. Minimal edit to `colnames`:
> >
> > if (is.data.frame(x)) {
> > nm <- names(x)
> > if (do.NULL || !is.null(nm))
> > return(nm)
> > else
> > return(paste0(prefix, seq_along(x)))
> > }
> >
> > Script and timings:
> >
> > N=1e7; K=100
> > set.seed(1)
> > DF <- data.frame(
> > id1 = sample(sprintf("id%03d",1:K), N, TRUE), # large groups (char)
> > id2 = sample(sprintf("id%03d",1:K), N, TRUE), # large groups (char)
> > id3 = sample(sprintf("id%010d",1:(N/K)), N, TRUE), # small groups (char)
> > id4 = sample(K, N, TRUE), # large groups (int)
> > id5 = sample(K, N, TRUE), # large groups (int)
> > id6 = sample(N/K, N, TRUE),# small groups (int)
> > v1 = sample(5, N, TRUE), # int in range [1,5]
> > v2 = sample(5, N, TRUE), # int in range [1,5]
> > v3 = sample(round(runif(100,max=100),4), N, TRUE) # numeric e.g.
> > 23.5749
> > )
> > cat("GB =", round(sum(gc()[,2])/1024, 3), "\n")
> > #GB = 0.397
> > colnames(DF) = NULL
> > system.time(nm1<-colnames(DF, FALSE))
> > # user system elapsed
> > # 22.158 0.299 22.498
> > print(nm1)
> > #[1] "col1" "col2" "col3" "col4" "col5" "col6" "col7" "col8" "col9"
> >
> > ### restart R
> >
> > colnames <- function (x, do.NULL = TRUE, prefix = "col")
> > {
> > if (is.data.frame(x)) {
> > nm <- names(x)
> > if (do.NULL || !is.null(nm))
> > return(nm)
> > else
> > return(paste0(prefix, seq_along(x)))
> > }
> > dn <- dimnames(x)
> > if (!is.null(dn[[2L]]))
> > dn[[2L]]
> > else {
> > nc <- NCOL(x)
> > if (do.NULL)
> > NULL
> > else if (nc > 0L)
> > paste0(prefix, seq_len(nc))
> > else character()
> > }
> > }
> > N=1e7; K=100
> > set.seed(1)
> > DF <- data.frame(
> > id1 = sample(sprintf("id%03d",1:K), N, TRUE), # large groups (char)
> > id2 = sample(sprintf("id%03d",1:K), N, TRUE), # large groups (char)
> > id3 = sample(sprintf("id%010d",1:(N/K)), N, TRUE), # small groups (char)
> > id4 = sample(K, N, TRUE), # large groups (int)
> > id5 = sample(K, N, TRUE), # large groups (int)
> > id6 = sample(N/K, N, TRUE),# small groups (int)
> > v1 = sample(5, N, TRUE), # int in range [1,5]
> > v2 = sample(5, N, TRUE), # int in range [1,5]
> > v3 = sample(round(runif(100,max=100),4), N, TRUE) # numeric e.g.
> > 23.5749
> > )
> > cat("GB =", round(sum(gc()[,2])/1024, 3), "\n")
> > #GB = 0.397
> > colnames(DF) = NULL
> > system.time(nm1<-colnames(DF, FALSE))
> > # user system elapsed
> > # 0.001 0.000 0.000
> > print(nm1)
> > #[1] "col1" "col2" "col3" "col4" "col5" "col6" "col7" "col8" "col9"
> >
> > sessionInfo()
> > #R Under development (unstable) (2016-12-19 r71815)
> > #Platform: x86_64-pc-linux-gnu (64-bit)
> > #Running under: Debian GNU/Linux stretch/sid
> > #
> > #locale:
> > # [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
> > # [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
> > # [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
> > # [7] LC_PAPER=en_US.UTF-8 LC_NAME=C
> > # [9] LC_ADDRESS=C LC_TELEPHONE=C
> > #[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
> > #
> > #attached base packages:
> > #[1] stats graphics grDevices utils datasets methods base #
> > #
> > #loaded via a namespace (and not attached):
> > #[1] compiler_3.4.0
>
> __
> 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] structure(NULL, *) is deprecated [was: Unexpected I(NULL) output]
> Martin Maechler > on Thu, 22 Dec 2016 10:24:43 +0100 writes: > Florent Angly > on Tue, 20 Dec 2016 13:42:37 +0100 writes: >> Hi all, >> I believe there is an issue with passing NULL to the function I(). >> class(NULL) # "NULL" (as expected) >> print(NULL) # NULL (as expected) >> is.null(NULL) # TRUE (as expected) >> According to the documentation I() should return a copy of its input >> with class "AsIs" preprended: >> class(I(NULL)) # "AsIs" (as expected) >> print(I(NULL)) # list() (not expected! should be NULL) >> is.null(I(NULL)) # FALSE (not expected! should be TRUE) >> So, I() does not behave according to its documentation. > yes. >> In R, it is >> not possible to give NULL attributes, but I(NULL) attempts to do that >> nonetheless, using the structure() function. Probably: >> 1/ structure() should not accept NULL as input since the goal of >> structure() is to set some attributes, something cannot be done on >> NULL. > I tend to agree. However if we gave an error now, I notice that > even our own code, e.g., in stats:::formula.default() would fail. > Still, I think we should consider *deprecating* structure(NULL, *), > so it would give a *warning* (and continue working otherwise) > (for a while before giving an error a year later). [..] > Martin Maechler > ETH Zurich Since svn rev 71841, structure(NULL, *) now __is__ deprecated in R-devel, i.e., > structure(NULL, foo = 2) list() attr(,"foo") [1] 2 Warning message: In structure(NULL, foo = 2) : Calling 'structure(NULL, *)' is deprecated, as NULL cannot have attributes. Consider 'structure(list(), *)' instead. > A dozen or so CRAN packages now not only give warnings but partially also ERRORS in their checks, which I find strange, but it may be because of too stringent checks (e.g. checks were all warnings are turned into errors). The most prominent packages now giving errors are data.table and ggplot2, then also GGally. Of course, we (the R core team) could make the deprecation even milder by not giving a warning() but only a message(.) aka "NOTE"; however, that renders the deprecation process longer and more complicated (notably for us), and there is still a few months' time before this version of R will be released... and really, as I said,... a new warning should rarely cause *errors* but rather warnings. OTOH, some of us have now seen / read on the R-package-devel mailing list that it seems ggplot2 has stopped working correctly (under R-devel only!) in building packages because of this warning.. The current plan is it will eventually, i.e., after the deprecation period, become an error, so ideally packages are patched and re-released ASAP. It's bedtime here now and we will see tomorrow how to continue. My current plan is to an e-mail to the package maintainers of CRAN packages that are affected, at least for those packages that are "easy to find". Martin Maechler, ETH Zurich __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
