[Bioc-devel] FYI: new package 'piano'
Dear BioC developers, This is just to announce the public availability of the new package 'piano'. Piano performs gene set analysis using various statistical methods, from different gene level statistics and a wide range of gene-set collections. Furthermore, the Piano package contains functions for combining the results of multiple runs of gene set analyses. All comments will be appreciated. Kindest regards *Leif Väremo*,* *PhD student *Systems and Synthetic Biology* Department of Chemical and Biological Engineering Chalmers University of Technology Kemivägen 10, SE-412 96 Göteborg www.sysbio.se www.chalmers.se [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] DESeq2 and miscTranformsation(s)
hi Steve, Thanks for pointing me to this bug. I have fixed this in version 1.0.9. So now rlogTransformation should accept the given dds just like varianceStabilizingTransformation. To avoid making a copy of the dds but still re-estimate dispersions, one can do: design(dds) - ~ 1 mcols(dds)$dispersion - NULL then either rlogTransformation or varianceStabilizingTransformation, which will call estimateDispersions internally. Mike On Sun, Apr 21, 2013 at 8:13 PM, Steve Lianoglou mailinglist.honey...@gmail.com wrote: Hi Michael, On Sat, Apr 20, 2013 at 12:18 AM, Michael Love michaelisaiahl...@gmail.com wrote: hi Steve, Thanks. Can you send a minimal example of the error? I can provide an alternate formula without error: dds - makeExampleDESeqDataSet() design(dds) - formula(~ condition) rld - rlogTransformation(dds) I'll see your `condition` and raise you a `treatment` :-) === R set.seed(123) R library(DESeq2) R dds - makeExampleDESeqDataSet() R colData(dds)$treatment - factor(sample(c(x, y), ncol(dds), replace=TRUE)) R design(dds) - formula(~ condition + treatment) ## Fails for rlogTransformation R dds.rlog - rlogTransformation(dds) gene-wise dispersion estimates mean-dispersion relationship final dispersion estimates Error in SummarizedExperiment(assays = rlogData(object, samplesVector, : error in evaluating the argument 'assays' in selecting a method for function 'SummarizedExperiment': Error in modelMatrixNames[match(convertNames$from, modelMatrixNames)] - convertNames$to : NAs are not allowed in subscripted assignments ## vst seems OK R dds.vst - varianceStabilizingTransformation(dds) gene-wise dispersion estimates mean-dispersion relationship final dispersion estimates I'm using DESeq2_1.0.7 on R-3.0.0 Thanks, -steve -- Steve Lianoglou Computational Biologist Department of Bioinformatics and Computational Biology Genentech [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony
On 13-04-21 9:22 PM, steven mosher wrote:
Well, color me confused as heck. I've upgraded to R 3.0 so that I can bring
my packages up to date, but the instructions surrounding Rtools30 are not a
model of clarity.
First thing is, you should not pay attention to Gabor's complaints.
They are valid, but they only matter to a tiny minority of R users,
those who use software that requires the ancient sort and find
utilities from MSDOS. Rtools installs a minimal Unix emulator, and
sort and find act differently there.
You should also ignore many of the instructions that you find on the
web, because people write them then don't update them when things
change. Pay attention to the R Installation and Administration manual
(which is kept up to date), and the instructions that are installed
along with the tools (and readable on the web site).
If you can't follow those instructions, point out which ones you don't
understand. If you can follow them but things don't work, then describe
what problems you are having.
Duncan Murdoch
On Sun, Apr 21, 2013 at 4:04 PM, Gabor Grothendieck ggrothendi...@gmail.com
wrote:
On Sun, Apr 21, 2013 at 6:17 PM, Henrik Bengtsson h...@biostat.ucsf.edu
wrote:
I (as well) keep a specific Rsetup.bat file for launching Windows
cmd.exe with the proper PATH etc setup for build R packages etc. It's
only after this thread I gave it a second thought; you can indeed
temporarily set the PATH via ~/.Rprofile or ~/.Renviron, which *are*
processed at the very beginning when calling 'R CMD ...'.
EXAMPLE WITH .Rprofile:
## ~/.Rprofile (e.g. C:/User/foo/.Rprofile):
path - unlist(strsplit(Sys.getenv(PATH), ;));
path - c(C:\\Rtools\\bin, C:\\Rtools\\gcc-4.6.3\\bin, path);
Sys.setenv(PATH=paste(unique(path), collapse=;));
## DISABLED:
x:\ R --no-init-file CMD INSTALL matrixStats_0.6.2.tar.gz
* installing to library 'C:/Users/hb/R/win-library/3.0'
* installing *source* package 'matrixStats' ...
** libs
*** arch - i386
ERROR: compilation failed for package 'matrixStats'
* removing 'C:/Users/hb/R/win-library/3.0/matrixStats'
## ENABLED:
x:\ R CMD INSTALL matrixStats_0.6.2.tar.gz
* installing to library 'C:/Users/hb/R/win-library/3.0'
* installing *source* package 'matrixStats' ...
** libs
*** arch - i386
gcc -m32 -IC:/PROGRA~1/R/R-3.0.0patched/include -DNDEBUG [...]
[...]
* DONE (matrixStats)
EXAMPLE WITH .Renviron:
## ~/.Renviron (e.g. C:/User/foo/.Renviron):
# Backslashes are preserved iff put within quotes
PATH=C:\Rtools\bin;C:\Rtools\gcc-4.6.3\bin;${PATH}
x:\ R --no-environ CMD INSTALL matrixStats_0.6.2.tar.gz
= fails
x:\ R CMD INSTALL matrixStats_0.6.2.tar.gz
= works
As long as R is on the PATH, the above either of the approaches
removes the need to add Rtools to the PATH via a BAT file and it won't
clutter up your PATH. This begs the question (as somewhat already
proposed), instead of users/developers doing this manually, would it
be possible to have 'R CMD ...' to locate add Rtools to the PATH
internally. That would certainly lower the barriers for newcomers to
install packages from source that need compilation. Obviously, this
doesn't make the tools (e.g. make) in Rtools available outside of R,
it does not allow you to build R itself from source, but it does cover
the very common use cases of calling 'R CMD build/INSTALL/check/...'.
/Henrik
PS. Hadley, is this what you meant when you wrote Better solutions
(e.g. Rstudio and devtools) temporarily set the path on when you're
calling R CMD *., or those approaches are only when you call 'R CMD'
from the R prompt? I believe the latter, but I just want to make sure
I didn't miss something.
That seems like a reasonable approach although the code shown does
entail more setup and ongoing maintenance by the user than R.bat which
does not require that the user edit any files and additionally locates
R itself and has many other features. Also, because R.bat locates R
itself it can be useful even if you are not doing development. On the
other hand if you are looking to do development strictly from within R
then devtools is already developed.
__
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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Converting an environment to a list: mget vs. as.list
Hi all, An interesting discovery: if you want to convert an environment to a list, and you already know the names of the objects in the environment, using mget is about twice as fast as using as.list on the environment. https://gist.github.com/hadley/5434786 Hadley -- Chief Scientist, RStudio http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony
On 21/04/2013 6:57 PM, Hadley Wickham wrote: PS. Hadley, is this what you meant when you wrote Better solutions (e.g. Rstudio and devtools) temporarily set the path on when you're calling R CMD *., or those approaches are only when you call 'R CMD' from the R prompt? I believe the latter, but I just want to make sure I didn't miss something. Well both devtools and RStudio allow you to do package development without leaving R, so neither do anything to your path when you're not using them. In teaching windows users to develop R packages, I found the use of the command line to be a substantial road-block, and if you can develop packages without leaving R, why not? The idea of temporary additions to the path during the INSTALL/build/check code sounds reasonable. R could probably do it more accurately than devtools or RStudio can (since we know the requirements, and you have to guess at them), but could hopefully do it in a way that isn't incompatible with those. The code called by install.packages() and related functions within R is essentially the same code as called by R CMD INSTALL etc from the command line, so this would help both cases. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Converting an environment to a list: mget vs. as.list
On Apr 22, 2013, at 9:14 AM, Hadley Wickham wrote: Hi all, An interesting discovery: if you want to convert an environment to a list, and you already know the names of the objects in the environment, using mget is about twice as fast as using as.list on the environment. I'd say the more interesting part is that ls() is so slow if you use the ambiguous name argument instead of the direct envir one: microbenchmark(ls(env), ls(envir=env), .Internal(ls(env, FALSE))) Unit: nanoseconds expr minlq medianuq max neval ls(env) 12445 13422 14450 15144 37505 100 ls(envir = env) 1741 2020 2331 2643 15574 100 .Internal(ls(env, FALSE)) 631 730828 910 4157 100 Note that your objects are so small that you cannot distinguish constant cost (e.g. just the method dispatch on as.list) - and that is in fact what causes the difference - not the actual conversion: microbenchmark(as.list(env), as.list.environment(env), mget(c(x, y), env)) Unit: microseconds expr min lq median uq max neval as.list(env) 4.8 5.55.9 6.1 33.1 100 as.list.environment(env) 1.4 1.92.1 2.4 4.8 100 mget(c(x, y), env) 2.6 3.13.4 3.7 37.5 100 So be careful with general statements on very small run times. Suddenly it's no longer surprising ... Cheers, S https://gist.github.com/hadley/5434786 Hadley -- Chief Scientist, RStudio http://had.co.nz/ __ 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] Converting an environment to a list: mget vs. as.list
I'd say the more interesting part is that ls() is so slow if you use the ambiguous name argument instead of the direct envir one: microbenchmark(ls(env), ls(envir=env), .Internal(ls(env, FALSE))) Unit: nanoseconds expr minlq medianuq max neval ls(env) 12445 13422 14450 15144 37505 100 ls(envir = env) 1741 2020 2331 2643 15574 100 .Internal(ls(env, FALSE)) 631 730828 910 4157 100 That is interesting! Note that your objects are so small that you cannot distinguish constant cost (e.g. just the method dispatch on as.list) - and that is in fact what causes the difference - not the actual conversion: That's a good point, but the first example was quite a bit larger, and hence the impact of S3 dispatch slightly less: env - environment(plot) names - ls(env) microbenchmark( as.list(env), as.list.environment(env), mget(names, env)) expr min lq median uq max neval as.list(env) 42 49 51 53 140 100 as.list.environment(env) 39 44 46 48 117 100 mget(names, env) 33 35 37 38 83 100 so mget still wins in that case. Hadley -- Chief Scientist, RStudio http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony
The idea of temporary additions to the path during the INSTALL/build/check code sounds reasonable. R could probably do it more accurately than devtools or RStudio can (since we know the requirements, and you have to guess at them), but could hopefully do it in a way that isn't incompatible with those. Both devtools and Rstudio check if gcc and ls are on the path already, and if they are, do nothing, so anything you did should be compatible. JJ and I would of course be happy to make any changes if necessary, and share our code for Rtools detection (along with useful error messages in all the edge cases). Hadley -- Chief Scientist, RStudio http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony
On Mon, Apr 22, 2013 at 10:27 AM, Duncan Murdoch murdoch.dun...@gmail.com wrote: On 21/04/2013 6:57 PM, Hadley Wickham wrote: PS. Hadley, is this what you meant when you wrote Better solutions (e.g. Rstudio and devtools) temporarily set the path on when you're calling R CMD *., or those approaches are only when you call 'R CMD' from the R prompt? I believe the latter, but I just want to make sure I didn't miss something. Well both devtools and RStudio allow you to do package development without leaving R, so neither do anything to your path when you're not using them. In teaching windows users to develop R packages, I found the use of the command line to be a substantial road-block, and if you can develop packages without leaving R, why not? The idea of temporary additions to the path during the INSTALL/build/check code sounds reasonable. R could probably do it more accurately than devtools or RStudio can (since we know the requirements, and you have to guess at them), but could hopefully do it in a way that isn't incompatible with those. The code called by install.packages() and related functions within R is essentially the same code as called by R CMD INSTALL etc from the command line, so this would help both cases. I would like to comment on this as I have had to implement similar facilities myself as part R.bat in the batchfiles. There is an issue of keeping R and Rtools in sync. Currently different Rtools versions will work with the same R version. For example, I have used both Rtools 1927 and 1930 with the current version of R. Its necessary to determine the relative paths that the version of Rtools in use requires since in principle the relative Rtools paths can vary from one version of Rtools to the next if the gcc version changes, say. Ideally the system would be able to figure this out even if registry entries and environment variables are not set by looking in standard locations for the Rtools root and finding the relative paths by querying some file in the Rtools installation itself. devtools does this by querying the Rtools version and uss an internal database of relative paths keyed by version. R.bat in batchfiles does it by scanning the Rtools unins000.dat file and extracting the relative paths directly from it. This has the advantage that no database need be maintained and it also automatically adapts to new versions of Rtools without any foreknowledge of them. Of course since you have control of both ends you alternately could add the relative paths to an expanded version of the VERSION file or add some additional text file into Rtools for the purpose of identifying he relative paths.. Another possibility if significant changes were to be considered would be to make Rtools into an R package thereby leveraging existing facilities and much simplifying any synchronization. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] vignettes: problems with PDF compaction
On 4/21/2013 1:28 PM, Michael Friendly wrote: [Env: OS: Win Xp; R 2.15.2; IDE: eclipse/StatET] Each time I update my heplots package, I get warnings from R CMD check on R-Forge, * checking sizes of PDF files under ‘inst/doc’ ... WARNING ‘gs+qpdf’ made some significant size reductions: compacted ‘HE-examples.pdf’ from 739Kb to 366Kb To follow up my own post, I did some more checking of whether/how to compact PDFs on my own system. My conclusion is that that I am unable to comply with the request from CRAN maintainers, even though I would like to. Once again, I wonder why this cannot be handled on the CRAN side automatically. qpdf: running it from a cmd prompt (using the options from tools::compactPDF) doesn't do very much compression C:\R\testqpdf --stream-data=compress --object-streams=generate HE-examples.pdf HE-examples-comp.pdf C:\R\testdir HE-examples* 04/22/2013 10:55 AM 699,191 HE-examples-comp.pdf 04/22/2013 10:28 AM 756,624 HE-examples.pdf gs: I have gs installed at C:\Program Files\gs\gs9.07\bin\gswin32.exe, but the gs installer doesn't put itself on the path, so tools::compactPDF sees gs_cmd as empty: gs_cmd = Sys.getenv(R_GSCMD, ) [1] so it can't run gs+qpdf. OK, so I try to do it manually: Sys.setenv(R_GSCMD = C:/Program Files/gs/gs9.07/bin/gswin32.exe) setwd(test) tools::compactPDF(HE-examples.pdf) tools::compactPDF(HE-examples.pdf, gs_quality=ebook) But this doesn't do anything, not even changing the timestamp on the file, because the file size doesn't change enough. C:\R\testdir HE-examples.pdf 04/22/2013 10:28 AM 756,624 HE-examples.pdf -- Michael Friendly Email: friendly AT yorku DOT ca Professor, Psychology Dept. Chair, Quantitative Methods York University Voice: 416 736-2100 x66249 Fax: 416 736-5814 4700 Keele StreetWeb: http://www.datavis.ca Toronto, ONT M3J 1P3 CANADA __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] vignettes: problems with PDF compaction
On 22.04.2013 17:59, Michael Friendly wrote: On 4/21/2013 1:28 PM, Michael Friendly wrote: [Env: OS: Win Xp; R 2.15.2; IDE: eclipse/StatET] Each time I update my heplots package, I get warnings from R CMD check on R-Forge, * checking sizes of PDF files under ‘inst/doc’ ... WARNING ‘gs+qpdf’ made some significant size reductions: compacted ‘HE-examples.pdf’ from 739Kb to 366Kb To follow up my own post, I did some more checking of whether/how to compact PDFs on my own system. My conclusion is that that I am unable to comply with the request from CRAN maintainers, even though I would like to. Once again, I wonder why this cannot be handled on the CRAN side automatically. Because we cannot know if the result is acceptable. This is not a lossless compression. qpdf: running it from a cmd prompt (using the options from tools::compactPDF) doesn't do very much compression C:\R\testqpdf --stream-data=compress --object-streams=generate HE-examples.pdf HE-examples-comp.pdf C:\R\testdir HE-examples* 04/22/2013 10:55 AM 699,191 HE-examples-comp.pdf 04/22/2013 10:28 AM 756,624 HE-examples.pdf gs: I have gs installed at C:\Program Files\gs\gs9.07\bin\gswin32.exe, but the gs installer doesn't put itself on the path, so tools::compactPDF sees gs_cmd as empty: gs_cmd = Sys.getenv(R_GSCMD, ) [1] so it can't run gs+qpdf. OK, so I try to do it manually: Sys.setenv(R_GSCMD = C:/Program Files/gs/gs9.07/bin/gswin32.exe) setwd(test) tools::compactPDF(HE-examples.pdf) tools::compactPDF(HE-examples.pdf, gs_quality=ebook) But this doesn't do anything, not even changing the timestamp on the file, because the file size doesn't change enough. Either you changed it or not, there is no not enough. Best, Uwe C:\R\testdir HE-examples.pdf 04/22/2013 10:28 AM 756,624 HE-examples.pdf __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] vignettes: problems with PDF compaction
It's certainly not obvious, but you should use 'gswin32c.exe' instead of 'gswin32.exe'. From http://ghostscript.com/doc/current/Install.htm#Install_Windows GSWIN32C.EXE Ghostscript as a 32-bit Windows command line program. This is usually the preferred executable. GSWIN32.EXE 32-bit Ghostscript using its own window for commands Basically, 'gswin32c.exe' corresponds to 'gs' on Unix systems (the other one tries to open its own Windows which doesn't work). If you're installing the 64-bit version of Ghostscript, use 'gswin64c.exe'. You can verify that you have the proper setup by: Sys.setenv(R_GSCMD=C:/Program Files/gs/gs9.07/bin/gswin32c.exe) res - system2(Sys.getenv(R_GSCMD), args=--version) 9.07 res [1] 0 If you get 127 it indicates an error/command not found, e.g. Sys.setenv(R_GSCMD=C:/Program Files/gs/gs9.07/bin/gswin32c.exeHIDE) res - system2(Sys.getenv(R_GSCMD), args=--version) res [1] 127 So, after confirming that you get res == 0, then retry with: tools::compactPDF(HE-examples.pdf, gs_quality=ebook) FYI, you can set your R_GSCMD in C:/Users/foo/.Renviron, cf. help(.Renviron). Hope this helps Henrik On Mon, Apr 22, 2013 at 2:51 PM, Uwe Ligges lig...@statistik.tu-dortmund.de wrote: On 22.04.2013 17:59, Michael Friendly wrote: On 4/21/2013 1:28 PM, Michael Friendly wrote: [Env: OS: Win Xp; R 2.15.2; IDE: eclipse/StatET] Each time I update my heplots package, I get warnings from R CMD check on R-Forge, * checking sizes of PDF files under ‘inst/doc’ ... WARNING ‘gs+qpdf’ made some significant size reductions: compacted ‘HE-examples.pdf’ from 739Kb to 366Kb To follow up my own post, I did some more checking of whether/how to compact PDFs on my own system. My conclusion is that that I am unable to comply with the request from CRAN maintainers, even though I would like to. Once again, I wonder why this cannot be handled on the CRAN side automatically. Because we cannot know if the result is acceptable. This is not a lossless compression. qpdf: running it from a cmd prompt (using the options from tools::compactPDF) doesn't do very much compression C:\R\testqpdf --stream-data=compress --object-streams=generate HE-examples.pdf HE-examples-comp.pdf C:\R\testdir HE-examples* 04/22/2013 10:55 AM 699,191 HE-examples-comp.pdf 04/22/2013 10:28 AM 756,624 HE-examples.pdf gs: I have gs installed at C:\Program Files\gs\gs9.07\bin\gswin32.exe, but the gs installer doesn't put itself on the path, so tools::compactPDF sees gs_cmd as empty: gs_cmd = Sys.getenv(R_GSCMD, ) [1] so it can't run gs+qpdf. OK, so I try to do it manually: Sys.setenv(R_GSCMD = C:/Program Files/gs/gs9.07/bin/gswin32.exe) setwd(test) tools::compactPDF(HE-examples.pdf) tools::compactPDF(HE-examples.pdf, gs_quality=ebook) But this doesn't do anything, not even changing the timestamp on the file, because the file size doesn't change enough. Either you changed it or not, there is no not enough. Best, Uwe C:\R\testdir HE-examples.pdf 04/22/2013 10:28 AM 756,624 HE-examples.pdf __ 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
