You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There was some general confusion about this during the talk/workshop at Bioc2018. People felt it was not intuitive that the anchoring is dropped after a mutate call and that anchoring decorates a GRanges object. There was a suggestion of making anchoring act like dplyr's scoped variants so something like:
gr %>% mutate_at_anchor(..., anchor = "start")
could be a possibility. I think I need to think about this a bit more though.
The text was updated successfully, but these errors were encountered:
Since there are only three possible anchors (five for stranded), we could just enumerate: mutate_with_fixed_start(), mutate_with_fixed_end(). Another idea is kinda like ascending() in dplyr. Just cast the width assignment:
That's attractive because it doesn't cause explosion in the verb names, and it localizes the anchor aspect to the width manipulation, where it actually matters. There's no decoration of the GRanges although there is a virtual decoration of the expression, but that's not a big deal.
I like that, I think the code would look more like dplyr if you set width outside the call to anchor_* and there's no confusion for how update columns using mutate()
There was some general confusion about this during the talk/workshop at Bioc2018. People felt it was not intuitive that the anchoring is dropped after a mutate call and that anchoring decorates a GRanges object. There was a suggestion of making anchoring act like dplyr's scoped variants so something like:
could be a possibility. I think I need to think about this a bit more though.
The text was updated successfully, but these errors were encountered: