[Bioc-devel] VariantAnnotation::VRanges() & defunct ifelse method for Rle objects in devel IRanges
Robert Castelo
robert.castelo at upf.edu
Thu Oct 22 09:37:11 CEST 2015
Michael, Hervé,
thanks for your enlightening discussion about proper overload of base::
methods. I guess you're going to take action on the S4Vectors package
(and not IRanges, as I wrongly put on the subject), right?
i'm afraid i lack a full understanding of what are the best practices
when overloading base:: methods and this could be also the case for
other developers. So, maybe a few bullet points about this subject could
be added to the developers tab of the web site at the page
http://www.bioconductor.org/developers/how-to
best regards,
robert.
On 10/22/2015 03:53 AM, Michael Lawrence wrote:
> Ok, thanks. That's what R (in my working copy) basically does now. Since
> internal sub-assignment is vector-based, it just calls as.vector(). That
> vector may be subsequently "promoted" given the type of "x" and "value"
> (like integer to real, real to character, etc). So it could be
> optimized, but it was a simple change and base::ifelse() works on Rle.
> We should keep the ifelse generic, with a signature on "test", so that
> we can dispatch on LogicalList.
>
> Michael
>
> On Wed, Oct 21, 2015 at 6:38 PM, Hervé Pagès <hpages at fredhutch.org
> <mailto:hpages at fredhutch.org>> wrote:
>
> On 10/21/2015 03:36 PM, Michael Lawrence wrote:
>
> That sucks. I was thinking we could easily make R smarter about
> sub-assignment, so that base::ifelse would just work with value
> Rle, as
> would [<- in general. The C code would just call as.vector() on the
> object. The problem is that S4 objects are seen by that code as
> "scalar"
> and are wrapped in a list when sub-assigned into one:
>
> > l <- list()
> > l[1] <- Rle(3:1)
> > l
> [[1]]
> integer-Rle of length 3 with 3 runs
> Lengths: 1 1 1
> Values : 3 2 1
>
> But that behavior is inconsistent within the base package, because
> lapply(), mapply() etc assume an S4 object is vector-like. I'm
> interested in your opinion. Should we deprecate the list
> sub-assignment
> behavior?
>
>
> I think list sub-assignment should just call as.list() on the right
> value if the value is not already a list. That way base R doesn't have
> to choose whether S4 objects should be seen as "scalar" or as
> "vector-like". This decision is now in the hands of the author of the
> S4 class: if s/he chooses to have the "as.list" method for his/her
> objects to just wrap the object in a list then s/he'll get the current
> behavior (object treated as a scalar). If s/he chooses to have the
> "as.list" method return a list parallel to the object then s/he'll get
> list sub-assignment treat his/her objects as vector-like.
>
> This principle can be extended to sub-assignments in general, not just
> list sub-assignments: if the class of the right value in 'x[i] <- value'
> doesn't extend the class of 'x', then 'value' should first be coerced
> to the class of 'x':
>
> if (!is(value, class(x))
> value <- as(value, class(x))
>
> Note that this is what the "[<-" method for Vector objects (defined
> in S4Vectors) does (thru the default method for
> normalizeSingleBracketReplacementValue).
>
> Thanks,
> H.
>
>
> Michael
>
>
> On Wed, Oct 21, 2015 at 11:14 AM, Hervé Pagès
> <hpages at fredhutch.org <mailto:hpages at fredhutch.org>
> <mailto:hpages at fredhutch.org <mailto:hpages at fredhutch.org>>> wrote:
>
> Hi Michael,
>
> On 10/21/2015 07:09 AM, Michael Lawrence wrote:
>
> News to me. Why was this deprecated? Why can't the ifelse()
> method just do
> what it is now telling the user to do? Is it to make the
> inefficiency of
> the implementation more obvious?
>
>
> There was some discussion about this here:
>
> https://support.bioconductor.org/p/70871/
>
> I should probably have brought this to bioc-devel before
> making that
> change, sorry. I'll be happy to bring these methods back if
> there is a
> way to preserve the semantic of base::ifelse() (which
> relies on delayed
> evaluation of the 'yes' and 'no' arguments).
>
> H.
>
> The goal with Rle was to make it behave as
> conveniently and as vector-like as possible.
>
>
>
> On Wed, Oct 21, 2015 at 6:50 AM, Robert Castelo
> <robert.castelo at upf.edu <mailto:robert.castelo at upf.edu>
> <mailto:robert.castelo at upf.edu <mailto:robert.castelo at upf.edu>>>
>
> wrote:
>
> hi,
>
> one of the recent changes in the devel IRanges has
> been to
> defunct the
> 'ifelse' method for 'Rle' objects. This was warned during
> the previous
> devel cycle and so it does with current release.
>
> One of the affected functions is the VRanges object
> constructor,
> 'VRanges()'. Since I use this function within my package
> VariantFiltering,
> this is now precluding it to build.
>
> I would like to ask whether you could fix the VRanges
> constructor to
> comply with the new requirement on the 'ifelse'
> method for
> 'Rle' objects.
>
> please find below a reproducible example for
> release and
> devel with
> corresponding session information.
>
> thanks!!
>
> robert.
>
> ============================================
>
> This is what happens in current release:
>
> library(VariantAnnotation)
>
>
> VRanges()
> VRanges object with 0 ranges and 0 metadata columns:
> seqnames ranges strand ref
> alt
> totalDepth
> refDepth altDepth sampleNames
> softFilterMatrix
> <Rle> <IRanges> <Rle> <character> <characterOrRle>
> <integerOrRle>
> <integerOrRle> <integerOrRle> <factorOrRle> <matrix>
> -------
> seqinfo: no sequences
> hardFilters: NULL
> Warning messages:
> 1: The "ifelse" methods for Rle objects are
> deprecated.
> Please use
>
> as(ifelse(test, as.vector(yes),
> as.vector(no)), "Rle")
>
> instead.
> 2: The "ifelse" methods for Rle objects are
> deprecated.
> Please use
>
> as(ifelse(test, as.vector(yes),
> as.vector(no)), "Rle")
>
> instead.
>
> sessionInfo()
> R version 3.2.2 (2015-08-14)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: Fedora release 12 (Constantine)
>
> locale:
> [1] LC_CTYPE=en_US.UTF8 LC_NUMERIC=C
> LC_TIME=en_US.UTF8
> LC_COLLATE=en_US.UTF8 LC_MONETARY=en_US.UTF8
> [6] LC_MESSAGES=en_US.UTF8 LC_PAPER=en_US.UTF8
> LC_NAME=C
> LC_ADDRESS=C LC_TELEPHONE=C
> [11] LC_MEASUREMENT=en_US.UTF8 LC_IDENTIFICATION=C
>
> attached base packages:
> [1] stats4 parallel stats graphics
> grDevices utils
> datasets
> methods base
>
> other attached packages:
> [1] VariantAnnotation_1.16.0 Rsamtools_1.22.0
> Biostrings_2.38.0
> XVector_0.10.0 SummarizedExperiment_1.0.0
> [6] Biobase_2.30.0 GenomicRanges_1.22.0
> GenomeInfoDb_1.6.0
> IRanges_2.4.0 S4Vectors_0.8.0
> [11] BiocGenerics_0.16.0 vimcom_1.2-3
> setwidth_1.0-4
> colorout_1.1-0
>
> loaded via a namespace (and not attached):
> [1] AnnotationDbi_1.32.0 GenomicAlignments_1.6.0
> zlibbioc_1.16.0
> BiocParallel_1.4.0 BSgenome_1.38.0
> tools_3.2.2
> [7] DBI_0.3.1 lambda.r_1.1.7
> futile.logger_1.4.1
> rtracklayer_1.30.0 futile.options_1.0.0
> bitops_1.0-6
> [13] RCurl_1.95-4.7 biomaRt_2.26.0
> RSQLite_1.0.0
> GenomicFeatures_1.22.0 XML_3.98-1.3
>
>
>
>
> This is what happens in current devel:
>
> library(VariantAnnotation)
>
> VRanges()
> Error: The "ifelse" methods for Rle objects are
> defunct.
> Please use
>
> as(ifelse(test, as.vector(yes),
> as.vector(no)), "Rle")
>
> instead.
> sessionInfo()
> R Under development (unstable) (2015-10-14 r69514)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: Fedora release 12 (Constantine)
>
> locale:
> [1] LC_CTYPE=en_US.UTF8 LC_NUMERIC=C
> LC_TIME=en_US.UTF8
> [4] LC_COLLATE=en_US.UTF8 LC_MONETARY=en_US.UTF8
> LC_MESSAGES=en_US.UTF8
> [7] LC_PAPER=en_US.UTF8 LC_NAME=C
> LC_ADDRESS=C
> [10] LC_TELEPHONE=C
> LC_MEASUREMENT=en_US.UTF8
> LC_IDENTIFICATION=C
>
> attached base packages:
> [1] stats4 parallel stats graphics
> grDevices utils
> datasets
> methods base
>
> other attached packages:
> [1] VariantAnnotation_1.17.0 Rsamtools_1.23.0
> Biostrings_2.39.0
> [4] XVector_0.11.0
> SummarizedExperiment_1.1.0
> Biobase_2.31.0
> [7] GenomicRanges_1.21.32 GenomeInfoDb_1.7.0
> IRanges_2.5.1
> [10] S4Vectors_0.9.2 BiocGenerics_0.17.0
> vimcom_1.0-0
> [13] setwidth_1.0-4 colorout_1.0-3
>
> loaded via a namespace (and not attached):
> [1] AnnotationDbi_1.33.0 GenomicAlignments_1.7.0
> zlibbioc_1.17.0
> BiocParallel_1.5.0
> [5] BSgenome_1.39.0 tools_3.3.0
> DBI_0.3.1
> lambda.r_1.1.7
> [9] futile.logger_1.4.1 rtracklayer_1.31.0
> futile.options_1.0.0
> bitops_1.0-6
> [13] RCurl_1.95-4.7 biomaRt_2.27.0
> RSQLite_1.0.0
> GenomicFeatures_1.23.3
> [17] XML_3.98-1.3
>
> _______________________________________________
> Bioc-devel at r-project.org <mailto:Bioc-devel at r-project.org>
> <mailto:Bioc-devel at r-project.org <mailto:Bioc-devel at r-project.org>>
> mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
>
> [[alternative HTML version deleted]]
>
> _______________________________________________
> Bioc-devel at r-project.org <mailto:Bioc-devel at r-project.org>
> <mailto:Bioc-devel at r-project.org <mailto:Bioc-devel at 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: hpages at fredhutch.org <mailto:hpages at fredhutch.org>
> <mailto:hpages at fredhutch.org <mailto:hpages at fredhutch.org>>
> Phone: (206) 667-5791 <tel:%28206%29%20667-5791>
> <tel:%28206%29%20667-5791>
> Fax: (206) 667-1319 <tel:%28206%29%20667-1319>
> <tel:%28206%29%20667-1319>
>
>
>
> --
> 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: hpages at fredhutch.org <mailto:hpages at fredhutch.org>
> Phone: (206) 667-5791 <tel:%28206%29%20667-5791>
> Fax: (206) 667-1319 <tel:%28206%29%20667-1319>
>
>
--
Robert Castelo, PhD
Associate Professor
Dept. of Experimental and Health Sciences
Universitat Pompeu Fabra (UPF)
Barcelona Biomedical Research Park (PRBB)
Dr Aiguader 88
E-08003 Barcelona, Spain
telf: +34.933.160.514
fax: +34.933.160.550
More information about the Bioc-devel
mailing list