Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unexpected behaviour with stretching w/o anchor #49

Closed
mschubert opened this issue Jul 31, 2018 · 11 comments
Closed

Unexpected behaviour with stretching w/o anchor #49

mschubert opened this issue Jul 31, 2018 · 11 comments
Labels

Comments

@mschubert
Copy link

Hi,

I'm trying to stretch a genomic region using different anchoring. I also tried without anchoring, which yielded the (unexpected) result below:

> x = makeGRangesFromDataFrame(data.frame(
    seqnames=1:2, start=c(10,100), end=c(200,300), strand=c('+','-')))

> x
      seqnames     ranges strand
         <Rle>  <IRanges>  <Rle>
  [1]        1    10-200      +
  [2]        2   100-300      -

> stretch(x, 2)
      seqnames     ranges strand
         <Rle>  <IRanges>  <Rle>
  [1]        1   104-106      +
  [2]        2   199-201      -

Why does it change the regions this way? (anchored stretching works as expected)

Using IRanges_2.14.10 and plyranges_1.0.3 (current Bioconductor release).

@sa-lee
Copy link
Collaborator

sa-lee commented Jul 31, 2018

It looks like the default is to stretch out from the centre, , which is not what my documentation says, so this is at least unexpected in that regard.

What output would expect here? Stretching by 2 away from the start and end?

> x %>% mutate(start = start - 2L, end = end + 2L)
GRanges object with 2 ranges and 0 metadata columns:
      seqnames    ranges strand
         <Rle> <IRanges>  <Rle>
  [1]        1     8-202      +
  [2]        2    98-302      -
  -------
  seqinfo: 2 sequences from an unspecified genome; no seqlengths

@lawremi
Copy link
Collaborator

lawremi commented Jul 31, 2018

Probably should behave however the start<-(), end()<- etc setters behave now.

@sa-lee
Copy link
Collaborator

sa-lee commented Jul 31, 2018

mutate uses those setters behind the scenes so the behaviour should be consistent.

@sa-lee
Copy link
Collaborator

sa-lee commented Jul 31, 2018

wondering if we could refactor here to have stretch just work inside mutate like we have been discussing in #47

@mschubert
Copy link
Author

@sa-lee I would expect stretch(., 0) to be a no-op, positive numbers to increase the overall range and negative to decrease overall range.

Personally, I wouldn't mind an error (or warning + default anchor) if the interval is not anchored.

@lawremi
Copy link
Collaborator

lawremi commented Aug 1, 2018

Agreed, I would have expected stretch_center() (the internal function corresponding to this case) to be like the +,Ranges() in IRanges: it would add half the amount to each end.

@sa-lee sa-lee added the bug label Aug 1, 2018
@mschubert
Copy link
Author

Note that this also happens for:

> stretch(anchor_center(x), 2)
      seqnames     ranges strand
         <Rle>  <IRanges>  <Rle>
  [1]        1   104-106      +
  [2]        2   199-201      -

(start, end, 5p, 3p anchors work as expected)

@sa-lee
Copy link
Collaborator

sa-lee commented Aug 7, 2018

Okey I'll change the default/centering to be like +, Ranges for now. I am also leaning towards your suggestion of having stretch throw a warning for no anchoring.

@mschubert
Copy link
Author

I didn't realize at before, but I'm also confused about anchor_end:

> stretch(anchor_end(x), 2)
      seqnames     ranges strand
         <Rle>  <IRanges>  <Rle>
  [1]        1    12-200      +
  [2]        2   102-300      -

This seems to shorten rather than stretch?

mschubert added a commit to mschubert/mad2-transposon that referenced this issue Aug 7, 2018
@sa-lee
Copy link
Collaborator

sa-lee commented Aug 7, 2018

Yep that looks wrong to me too. It should go the the other way. Turns out there was a wayward + in that code.

sa-lee pushed a commit that referenced this issue Aug 7, 2018
@sa-lee sa-lee closed this as completed Sep 11, 2018
@mschubert
Copy link
Author

🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants