[Bioc-devel] TIMEOUT and tokay2 require Rmpi
Hi, Our package SINCE has got TIMEOUT notice several times, but it only took a few seconds on my local Mac system. And it also states require Rmpi for Windows but not for Mac or Linux, how should I fix this? Thanks Jie ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Pushing towards a better home for matrix generics
I installed R 3.6 beta and can confirm that the clashes between the row/colSums
and row/colMeans generics from Matrix and BiocGenerics are gone. Excellent!
Thanks Michael.
H.
On 4/9/19 11:15, Michael Lawrence wrote:
This should be in trunk and the 3.6 release branch.
On Thu, Mar 28, 2019 at 9:57 AM Michael Lawrence
mailto:micha...@gene.com>> wrote:
Not yet. Too busy breaking other things ;) I'll move it up on my TODO list.
On Thu, Mar 28, 2019 at 9:16 AM Pages, Herve
mailto:hpa...@fredhutch.org>> wrote:
Hi Michael,
Did you get a chance to make this change?
Thanks,
H.
On 2/11/19 08:07, Michael Lawrence wrote:
> I propose that we just fix the signatures in the methods package and
> deal with the consequences. If Martin's OK with that, I'll make the
> change.
>
> Michael
>
> On Mon, Feb 11, 2019 at 7:45 AM McDavid, Andrew
> mailto:andrew_mcda...@urmc.rochester.edu>>
> wrote:
>> As a casual observer of this thread, my takeaway is that 1. the current
>> situation is untenable (e.g. it means that Aaron would have to essentially
>> reimplement S4 method dispatch) 2. Given the long history, and extent of
>> reverse dependencies to Matrix, there are good reasons to not mess with the
>> signature of its implicit generic (though I don't see much utility in
>> multiple dispatch here) and 3. therefore the least-bad alternative may be
>> to eliminate the call to setGeneric('colSums'), etc, in BiocGenerics,
>> hopefully with some fixes to the help system to make it more tolerant to S4
>> method naming. I appreciate that until these fixes are forthcoming it means
>> more work maintaining the help aliases for some methods. How often do we
>> think the aliases would be break?
>>
>> Andrew McDavid
>> Biostatistics and Computational Biology
>> Office: SRB 4.206 Ph: 585.275.5983
>>
>> Message: 1
>> Date: Sun, 10 Feb 2019 13:36:43 +
>> From: Aaron Lun
>> mailto:infinite.monkeys.with.keyboa...@gmail.com>>>
>> To: "Pages, Herve"
>> mailto:hpa...@fredhutch.org>>>,
>> Martin Maechler
>> mailto:maech...@stat.math.ethz.ch>>>
>> Cc: Michael Lawrence
>> mailto:lawrence.mich...@gene.com>>>,
>> "bioc-devel@r-project.org>"
>>
>> mailto:bioc-devel@r-project.org>>>
>> Subject: Re: [Bioc-devel] Pushing towards a better home for matrix
>> generics
>> Message-ID:
>> <1549805803.3935.11.ca...@gmail.com>>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Returning to this topic:
>>
>> It's good to hear some of the rationale behind the current state of
>> affairs. That said, the set-up we have now is quite difficult to work
>> with; as mentioned before, I've had to hack around it like:
>>
>> # Example from "BiocSingular",
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_LTLA_BiocSingular=DwIGaQ=4sF48jRmVAe_CH-k9mXYXEGfSnM3bY53YSKuLUQRxhA=YOujD4cGNGWN0ZskTj96dUHU2a4CkraklBd4BndS21sf3_emyYLIG1llnUarWCda=VBZgu2tHS9vBNQ2d8RSG4ijIcp3jyZkfCsRnA1mk7XI=FN4WdWx8gfnjFoLRQuBaIHaKrAjONVa9hsbAyIXSwGo=
>> .safe_colSums <- function(x) {
>> if (is(x, "Matrix")) {
>> Matrix::colSums(x)
>> } else {
>> colSums(x)
>> }
>> }
>>
>> ... which is ugly, and even worse, still incorrect, e.g., for non-
>> Matrix classes that have methods for the implicit colSums generic. This
>> situation is not sustainable for further package development.
>>
>> Is there a path forward that is palatable to everyone? Or perhaps these
>> conversations are already happening on R-devel?
>>
>> -A
>>
>> On Tue, 2019-01-29 at 18:46 +, Pages, Herve wrote:
>> Yes the help system could enforce the full signature for the aliases
>> but
>> that means the end user then will have to always do
>> ?`colSums,SomeClass,ANY,ANY-method`, which feels unnecessary
>> complicated
>> and confusing in the case of a generic where dispatching on the 2nd
>> and
>> 3rd arguments hardly makes sense.
>>
>> Or are you saying that the help system should enforce an alias that
>> strictly matches the signature explicitly used in the setMethod
>> statement? Problem with this is that then there is no easy way for
>> the
>> end user to know a priori which form to use to access the man page.
>> Is
>> it ?`colSums,dgCMatrix,ANY,ANY-method` or is it
>> ?`colSums,dgCMatrix-method`. Right now when you type colSums
>> (after loading the Matrix package), you get this:
>>
>> > library(Matrix)
>> > colSums
>> standardGeneric for "colSums" defined from package
Re: [Bioc-devel] Help with installing netReg
On Sun, Apr 14, 2019 at 6:30 PM Spencer Brackett <
spbracket...@saintjosephhs.com> wrote:
> Good evening,
>
> I am having problems with downloading the package used to generate
> regression models on R. The following is the error message I received. I
> tried installing BiocManager instead as suggested, but this too did not
> work. Any ideas?
>
> The downloaded binary packages are in
> C:\Users\Spencer\AppData\Local\Temp\Rtmp8YKVqx\downloaded_packages
> installation path not writeable, unable to update packages: class, cluster,
> codetools, foreign,
> lattice, MASS, Matrix, mgcv, nlme, rpart, survival
> Warning message:
> 'biocLite' is deprecated.
> Use 'BiocManager::install' instead.
> See help("Deprecated")
>
Dear Spencer
1) this is not an error message but a warning concerning the permission
setup on your computer
2) this mailing list is for package development in bioconductor, but the
question
does not address development, please do not use this list
3) use support.bioconductor.org for questions concerning
installation/BiocManager. Just point
your browser to support.bioconductor.org, and read the posting guidelines
Thank you
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
--
The information in this e-mail is intended only for the ...{{dropped:18}}
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
[Bioc-devel] Help with installing netReg
Good evening,
I am having problems with downloading the package used to generate
regression models on R. The following is the error message I received. I
tried installing BiocManager instead as suggested, but this too did not
work. Any ideas?
The downloaded binary packages are in
C:\Users\Spencer\AppData\Local\Temp\Rtmp8YKVqx\downloaded_packages
installation path not writeable, unable to update packages: class, cluster,
codetools, foreign,
lattice, MASS, Matrix, mgcv, nlme, rpart, survival
Warning message:
'biocLite' is deprecated.
Use 'BiocManager::install' instead.
See help("Deprecated")
[[alternative HTML version deleted]]
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Rd] stopifnot
In current definition of function 'stopifnot' in stop.R in R 3.6.0 beta
(https://svn.r-project.org/R/branches/R-3-6-branch/src/library/base/R/stop.R)
or R devel (https://svn.r-project.org/R/trunk/src/library/base/R/stop.R), if
'exprs' is specified, cl[[1]] is quote(stopifnot) . To be more robust,
quote(base::stopifnot) may be used instead.
Also, in current definition of function 'stopifnot' in R 3.6.0 beta or R devel,
for 'cl' if 'exprs' is specified, there a case with comment "the *name* of an
expression". The intent is allowing
stopifnot(exprs = ee) ,
where variable 'ee' holds an expression object, to work on the expression
object.
It is not quite right to use eval(exprs) . It fails when 'stopifnot' is called
inside a function, like
f <- function(ee) stopifnot(exprs = ee)
f(expression())
But, how about local=FALSE case? Should the following work?
f <- function(ee) stopifnot(exprs = ee, local = FALSE)
f(expression())
But, why bother making it work, while it is undocumented that 'exprs' argument
in 'stopifnot' can be an expression? Well, yes, expectation may be set from the
name "exprs" itself or from argument 'exprs' in function 'source' or
'withAutoprint'. Function 'withAutoprint' may be the closest match.
Function 'withAutoprint' has 'evaluated' argument that controls whether work is
on value of 'exprs' or on 'exprs' as given. I like the approach.
If 'E1' is an expression object,
as.call(c(quote(stopifnot), E1))
also works, without converting 'E1' to list.
I suggest to arrange "details" section in stopifnot.Rd as follows:
This function is intended ...
Since R version 3.5.0, stopifnot(exprs = { ... }) ...
stopifnot(A, B) ... is conceptually equivalent to ...
Since R version 3.5.0, expressions are evaluated sequentially ...
Since R version 3.6.0, stopifnot no longer handles potential errors or warnings
... ---not including sys.call()
Since R version 3.4.0, ... all.equal ...
sys.call()
Use of sys.call() in 'stopifnot' actually happens since R 3.5.0, as the call
included in error message produced by 'stopifnot'. In R 3.5.x, it is
sys.call(-1) , that can be NULL . In current R 3.6.0 beta, it is
sys.call(sys.parent(1L)) , only if sys.parent(1L) is not 0. The two may differ
only for 'stopifnot' that is called via 'eval' or the like.
I think it is good if the documentation also includes an example of use of
'stopifnot' inside a function, where error message from 'stopifnot' includes
call since R 3.5.0. Such an example is in
https://stat.ethz.ch/pipermail/r-devel/2017-May/074303.html .
On Mon, 1/4/19, Martin Maechler wrote:
Subject: Re: [Rd] stopifnot
Cc: r-devel@r-project.org
Date: Monday, 1 April, 2019, 8:12 PM
> Suharto Anggono Suharto Anggono via R-devel
> on Sun, 31 Mar 2019 15:26:13 + writes:
[.]
[ "eval() inside for()" not giving call in error message .]
[.]
> "Details" section of 'stopifnot' documentation in current R 3.6.0 alpha
>
(https://svn.r-project.org/R/branches/R-3-6-branch/src/library/base/man/stopifnot.Rd)
> has this.
> Since \R version 3.6.0, \code{stopifnot()} no longer handles potential
> errors or warnings (by \code{\link{tryCatch}()} etc) for each single
> expression but rather aims at using the correct
> \code{\link{sys.call}()} to get the most meaningful error message in
> case of an error. This provides considerably less overhead.
> I think part of the first sentence starting from "but rather" should be
removed because it is not true.
You are right that it is not accurate... I'll modify it,
including keeping the "considerably less overhead"
which had been one important reason for changing from 3.5.x to
the current version.
> The next paragraph:
> Since \R version 3.5.0, expressions \emph{are} evaluated sequentially,
> and hence evaluation stops as soon as there is a \dQuote{non-TRUE}, as
> indicated by the above conceptual equivalence statement.
> Further, when such an expression signals an error or
> \code{\link{warning}}, its \code{\link{conditionCall}()} no longer
> contains the full \code{stopifnot} call, but just the erroneous
> expression.
> As I said earlier
(https://stat.ethz.ch/pipermail/r-devel/2019-February/077386.html), the last
sentence above is not entirely true.
You are right to some degree: That really was true for R 3.5.x,
but is no longer entirely accurate.
It is still true currently interestingly thanks to the "eval() in for()"
behavior that the error/warning message is most of the time only
about the relevant part and not mentioning the full stopifnot(..) call.
> It may say something like:
> Further, when such an expression signals an error, stopifnot() in R 3.5.x
makes its conditionCall() the erroneous expression, but no longer since R 3.6.0.
> Is it OK that, for
> do.call(stopifnot, list(exprs =
Re: [Rd] [r-devel] integrate over an infinite region produces wrong results depending on scaling
integrate(f, xmin, xmax) will have problems when f(x) is 0 over large parts
of (xmin,xmax). It doesn't have any clues to where the non-zero regions
are. It computes f(x) at 21 points at each step and if all of those are
zero (or some other constant?) for a few steps, it calls it a day. If you
can narrow down the integration interval to the interesting part of the
function's domain you will get better results.
By the way, here is a way to see where integrate(f) evaluates f() (the
keep.xy=TRUE argument doesn't seem to do anything).
> debugIntegrate <- function(f)
{
n_calls <- 0
x_args <- list()
other_args <- list()
value <- list()
function(x, ...) {
n_calls <<- n_calls + 1
x_args[[n_calls]] <<- x
other_args[[n_calls]] <<- list(...)
v <- f(x, ...)
value[[n_calls]] <<- v
v
}
}
> str(integrate(DF <- debugIntegrate(f), -Inf, 0, numstab = sc))
List of 5
$ value : num 1.5
$ abs.error : num 0.000145
$ subdivisions: int 2
$ message : chr "OK"
$ call: language integrate(f = DF <- debugIntegrate(f), lower =
-Inf, upper = 0, numstab = sc)
- attr(*, "class")= chr "integrate"
> curve(f(x, sc), min(unlist(environment(DF)$x_args)), 0, n = 501, main =
"Scaled f", bty = "n")
> with(environment(DF), points(unlist(x_args), unlist(value)))
Bill Dunlap
TIBCO Software
wdunlap tibco.com
On Sun, Apr 14, 2019 at 5:13 AM Andreï V. Kostyrka
wrote:
> Dear all,
>
> This is the first time I am posting to the r-devel list. On
> StackOverflow, they suggested that the strange behaviour of integrate()
> was more bug-like. I am providing a short version of the question (full
> one with plots: https://stackoverflow.com/q/55639401).
>
> Suppose one wants integrate a function that is just a product of two
> density functions (like gamma). The support of the random variable is
> (-Inf, 0]. The scale parameter of the distribution is quite small
> (around 0.01), so often, the standard integration routine would fail to
> integrate a function that is non-zero on a very small section of the
> negative line (like [-0.02, -0.01], where it takes huge values, and
> almost 0 everywhere else). R’s integrate would often return the machine
> epsilon as a result. So I stretch the function around the zero by an
> inverse of the scale parameter, compute the integral, and then divide it
> by the scale. Sometimes, this re-scaling also failed, so I did both if
> the first result was very small.
>
> Today when integration of the rescaled function suddenly yielded a value
> of 1.5 instead of 3.5 (not even zero). The MWE is below.
>
> cons <- -0.020374721416129591
> sc <- 0.00271245601724757383
> sh <- 5.704
> f <- function(x, numstab = 1) dgamma(cons - x * numstab, shape = sh,
> scale = sc) * dgamma(-x * numstab, shape = sh, scale = sc) * numstab
>
> curve(f, -0.06, 0, n = 501, main = "Unscaled f", bty = "n")
> curve(f(x, sc), -0.06 / sc, 0, n = 501, main = "Scaled f", bty = "n")
>
> sum(f(seq(-0.08, 0, 1e-6))) * 1e-6 # Checking by summation: 3.575294
> sum(f(seq(-30, 0, 1e-4), numstab = sc)) * 1e-4 # True value, 3.575294
> str(integrate(f, -Inf, 0)) # Gives 3.575294
> # $ value : num 3.58
> # $ abs.error : num 1.71e-06
> # $ subdivisions: int 10
> str(integrate(f, -Inf, 0, numstab = sc))
> # $ value : num 1.5 # What?!
> # $ abs.error : num 0.000145 # What?!
> # $ subdivisions: int 2
>
> It stop at just two subdivisions! The problem is, I cannot try various
> stabilising multipliers for the function because I have to compute this
> integral thousands of times for thousands of parameter values on
> thousands of sample windows for hundreds on models, so even in the
> super-computer cluster, this takes weeks. Besides that, reducing the
> rel.tol just to 1e-5 or 1e-6, helped a bit, but I am not sure whether
> this guarantees success (and reducing it to 1e-7 slowed down the
> computations in some cases). And I have looked at the Fortran code of
> the quadrature just to see the integration rule, and was wondering.
>
> How can I make sure that the integration routine will not produce such
> wrong results for such a function, and the integration will still be fast?
>
> Yours sincerely,
> Andreï V. Kostyrka
>
> __
> 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
[Rd] [r-devel] integrate over an infinite region produces wrong results depending on scaling
Dear all, This is the first time I am posting to the r-devel list. On StackOverflow, they suggested that the strange behaviour of integrate() was more bug-like. I am providing a short version of the question (full one with plots: https://stackoverflow.com/q/55639401). Suppose one wants integrate a function that is just a product of two density functions (like gamma). The support of the random variable is (-Inf, 0]. The scale parameter of the distribution is quite small (around 0.01), so often, the standard integration routine would fail to integrate a function that is non-zero on a very small section of the negative line (like [-0.02, -0.01], where it takes huge values, and almost 0 everywhere else). R’s integrate would often return the machine epsilon as a result. So I stretch the function around the zero by an inverse of the scale parameter, compute the integral, and then divide it by the scale. Sometimes, this re-scaling also failed, so I did both if the first result was very small. Today when integration of the rescaled function suddenly yielded a value of 1.5 instead of 3.5 (not even zero). The MWE is below. cons <- -0.020374721416129591 sc <- 0.00271245601724757383 sh <- 5.704 f <- function(x, numstab = 1) dgamma(cons - x * numstab, shape = sh, scale = sc) * dgamma(-x * numstab, shape = sh, scale = sc) * numstab curve(f, -0.06, 0, n = 501, main = "Unscaled f", bty = "n") curve(f(x, sc), -0.06 / sc, 0, n = 501, main = "Scaled f", bty = "n") sum(f(seq(-0.08, 0, 1e-6))) * 1e-6 # Checking by summation: 3.575294 sum(f(seq(-30, 0, 1e-4), numstab = sc)) * 1e-4 # True value, 3.575294 str(integrate(f, -Inf, 0)) # Gives 3.575294 # $ value : num 3.58 # $ abs.error : num 1.71e-06 # $ subdivisions: int 10 str(integrate(f, -Inf, 0, numstab = sc)) # $ value : num 1.5 # What?! # $ abs.error : num 0.000145 # What?! # $ subdivisions: int 2 It stop at just two subdivisions! The problem is, I cannot try various stabilising multipliers for the function because I have to compute this integral thousands of times for thousands of parameter values on thousands of sample windows for hundreds on models, so even in the super-computer cluster, this takes weeks. Besides that, reducing the rel.tol just to 1e-5 or 1e-6, helped a bit, but I am not sure whether this guarantees success (and reducing it to 1e-7 slowed down the computations in some cases). And I have looked at the Fortran code of the quadrature just to see the integration rule, and was wondering. How can I make sure that the integration routine will not produce such wrong results for such a function, and the integration will still be fast? Yours sincerely, Andreï V. Kostyrka __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Bioc-devel] GAlignments Constructor Type Checking Error
Your strand factor only has level "+", but should have levels "+", "-", "*".
Use GenomicRanges::strand() to construct the right thing.
Martin
On 4/14/19, 3:01 AM, "Bioc-devel on behalf of Dario Strbenac"
wrote:
Good day,
Although the documentation states "Generally not used directly", I'm trying
it. A small example fails because the input is evaluated to be in the wrong
format, but it doesn't seem so when I look at the variable type of strand.
debug(GAlignments)
GAlignments("chr1", 1L, strand = Rle(factor('+')), cigar = "10M")
debug: new("GAlignments", NAMES = names, seqnames = seqnames,
start = pos, cigar = cigar, strand = strand, elementMetadata =
elementMetadata,
seqinfo = seqinfo)
Browse[2]> strand
factor-Rle of length 1 with 1 run
Lengths: 1
Values : +
Levels(1): +
Browse[2]> n
Error in validObject(.Object) :
invalid class “GAlignments” object: 'strand(x)' must be an unnamed
'factor' Rle with no NAs (and with levels +, - and *)
This looks like a false-positive to me. Also, it would increase readability
if the constructor didn't run off the edge of the PDF page in the reference
manual by using \preformatted. Also, I wonder why seqnames is automatically
converted into a factor Rle, but strand isn't. Couldn't strand also use
.asFactorRle?
--
Dario Strbenac
University of Sydney
Camperdown NSW 2050
Australia
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] deprecation guidelines
Hi Sam,
On 4/11/19 10:47, Samuela Pollack wrote:
> Dear Bioconductor,
>
> We are deprecating part of a package. I am following the guidelines in
> the "Function Deprecation Guidelines" page at bioconductor.org and I
> have a few questions:
>
> (i) Deprecating a S4 method which has the same name in another S4
> class. We have two DelayedArray backends. Functions like dim and
> dimnames are deprecated in one but not in the other. Should those
> functions be listed in the ThePkg-deprecated document? With the name
> of the backend that's being deprecated? With a note about the backend
> that is *not* being deprecated?
Before their deprecation these methods should normally already be
documented somewhere. In particular there should already be aliases and
\usage entries somewhere for them. For example if foo() is the generic,
the alias for the foo,SomeClass method is:
\alias{foo,SomeClass-method}
and the \usage entry for this method looks like this:
\S4method{foo}{SomeClass}(x, ...)
When deprecating this method, the \alias and \usage entry should be
moved to the MyPkg-deprecated man page. Note that the "Function
Deprecation Guidelines" only suggests to list the deprecated methods
(and their replacements) in the \details section, but it's fine to also
list them in a \usage section.
>
> (ii) Deprecating a S4 class. Should this look just like a function in
> ThePkg-deprecated?
Same as for a method except that, strictly speaking, there is no notion
of \usage entry for an S4 class, only for its constructor function (if
there is one). So the aliases for the class and its constructor, and the
\usage entry for the constructor, should be moved to the
MyPkg-deprecated man page.
>
>
> (iii) subscript, double-subscript, assign-to-property (property<-)
> operators. Should they be included in ThePkg-deprecated.Rd? In favor:
> they are being deprecated for the class they pertain to. Against: we
> certainly aren't deprecating the subscript operator in general.
These are methods e.g. the [,SomeClass, [[,SomeClass, and [<-,SomeClass
methods. The procedure to deprecate them is the same as for deprecating
methods in general. So them as (i).
Hope this helps,
H.
>
> thanks,
>
> - Sam
>
> ___
> Bioc-devel@r-project.org mailing list
> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=c7mY7SviNf8WObwMM13uYGQuvB87RX3qS6eV5nIZsYg=QzjewaW8MNTVLiVirE1ytWId_dqFeUjSfYL5i6US2zM=
>
>
--
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
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
[Bioc-devel] GAlignments Constructor Type Checking Error
Good day,
Although the documentation states "Generally not used directly", I'm trying it.
A small example fails because the input is evaluated to be in the wrong format,
but it doesn't seem so when I look at the variable type of strand.
debug(GAlignments)
GAlignments("chr1", 1L, strand = Rle(factor('+')), cigar = "10M")
debug: new("GAlignments", NAMES = names, seqnames = seqnames,
start = pos, cigar = cigar, strand = strand, elementMetadata =
elementMetadata,
seqinfo = seqinfo)
Browse[2]> strand
factor-Rle of length 1 with 1 run
Lengths: 1
Values : +
Levels(1): +
Browse[2]> n
Error in validObject(.Object) :
invalid class “GAlignments” object: 'strand(x)' must be an unnamed 'factor'
Rle with no NAs (and with levels +, - and *)
This looks like a false-positive to me. Also, it would increase readability if
the constructor didn't run off the edge of the PDF page in the reference manual
by using \preformatted. Also, I wonder why seqnames is automatically converted
into a factor Rle, but strand isn't. Couldn't strand also use .asFactorRle?
--
Dario Strbenac
University of Sydney
Camperdown NSW 2050
Australia
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
