Re: [Bioc-devel] Overflow in as(rlelist, IntegerList
I was thinking the same thing and given this encouragement made the change to devel. On Sat, Mar 29, 2014 at 10:04 PM, Hervé Pagès hpa...@fhcrc.org wrote: Hi Michael, On 03/29/2014 02:07 PM, Michael Lawrence wrote: Just coerce the RleList to SimpleIntegerList. Isn't what as(x, IntegerList) should do when 'x' is a SimpleRleList? Thanks, H. On Sat, Mar 29, 2014 at 1:10 PM, Gabe Becker becker.g...@gene.com wrote: Hi all, Apologies if this gets duplicated. I was not subscribed when I originally sent it. We have a very large RleList, such that the sum of the lengths is larger than INT.MAX, that we want to convert to an also very large IntegerList (whole genome coverages by chromosome I believe, though I'm not the author of the code that ran into this so I could be wrong about the details there). The IntegerList will fit in memory fine, but the coercion method is trying to collapse our RleList into a single Rle (in compress_listData() which is called from coerceToCompressedList() ) during the coercion step, which is too long and causes an integer overflow in the constructor. Specically the Rle_constructor C function is calling _sum_non_neg_ints C function, which throws an error. I can see that there is quite a bit of machinery trying to make these coercions go fast, but it seems they have introduced an unintended (?) limitation on the size of the *List objects involved. Is there a slower but more robust coercion machinery I don't know about, and if not could one be exposed? (Fast and more robust would also be acceptable ;-) ) Thanks, ~G [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel -- 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...@fhcrc.org Phone: (206) 667-5791 Fax:(206) 667-1319 [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
[Bioc-devel] Viper package is now publicly available
Dear BioC developers, I am happy to inform you that the viper package is now publicly available from BioC. The package implements the viper algorithm, which infers regulatory protein activity from any gene expression signature. The algorithm integrates information about differential expression of the target genes (regulon) for each of the regulators in a gene regulatory network to infer their relative activity at the protein level. I hope you find it useful. Best Regards, Mariano -- Mariano J. Alvarez Research Scientist Department of Systems Biology Columbia University [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
[Rd] CXX_STD and configure.ac in packages
In C++ code for use in a R-3.1.0 package, my specific problem is that I would
like to use unordered_map if it is available, or tr1/unordered_map if not,
or map if all else fails.
I (think I) can accomplish this with configure.ac as
AC_INIT(DESCRIPTION)
CXX=`${R_HOME}/bin/R CMD config CXX`
CXXFLAGS=`${R_HOME}/bin/R CMD config CXXFLAGS`
AC_CONFIG_HEADERS([src/config.h])
AC_LANG(C++)
AC_CHECK_HEADERS([unordered_map tr1/unordered_map])
AC_OUTPUT
Use of configure.ac does not seem to be entirely consistent with section 1.2.4
of Writing R Extensions, where one is advised that to use C++(11? see below)
code one should
CXX_STD = CXX11
in Makevars(.win). My code does not require a compiler that supports the full
C++11 feature set. In addition, I do not understand the logic of setting a
variable that influences compiler flags in Makevars -- configure.ac will see a
compiler with inaccurate flags.
Is use of configure.ac orthogonal to setting CXX_STD=CXX11?
Some minor typos:
/R-3-1-branch$ svn diff
Index: doc/manual/R-exts.texi
===
--- doc/manual/R-exts.texi (revision 65339)
+++ doc/manual/R-exts.texi (working copy)
@@ -2250,7 +2250,7 @@
@subsection Using C++11 code
@R{} can be built without a C++ compiler although one is available
-(but not necessarily installed) or all known @R{} platforms.
+(but not necessarily installed) on all known @R{} platforms.
For full portability across platforms, all
that can be assumed is approximate support for the C++98 standard (the
widely used @command{g++} deviates considerably from the standard).
@@ -2272,7 +2272,7 @@
support a flag @option{-std=c++0x}, but the latter only provides partial
support for the C++11 standard.
-In order to use C++ code in a package, the package's @file{Makevars}
+In order to use C++11 code in a package, the package's @file{Makevars}
file (or @file{Makevars.win} on Windows) should include the line
@example
@@ -2329,7 +2329,7 @@
anything other than the GNU version of C++98 and GNU extensions (which
include TR1). The default compiler on Windows is GCC 4.6.x and supports
the @option{-std=c++0x} flag and some C++11 features (see
-@uref{http://gcc.gnu.org/gcc-4.6/cxx0x_status.html}. On these
+@uref{http://gcc.gnu.org/gcc-4.6/cxx0x_status.html}). On these
platforms, it is necessary to select a different compiler for C++11, as
described above, @emph{via} personal @file{Makevars} files. For
example, on OS X 10.7 or later one could select @command{clang++}.
--
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109
Location: Arnold Building M1 B861
Phone: (206) 667-2793
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] rgl question
Hello, If I call lines3d(x,y,z) I get lines connecting each point, but when I call rgl.lines(x,y,z) I get dashed lines, and adding something like type='l' leads to an error message. The docs seem to suggest that rgl.lines() calls lines3d(), so I would expect the result to be the same. Any tips would be appreciated. Thanks, Dominick __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
