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

Different semantics of groupBy and fcol #195

Closed
lgatto opened this issue Feb 17, 2017 · 2 comments
Closed

Different semantics of groupBy and fcol #195

lgatto opened this issue Feb 17, 2017 · 2 comments
Assignees

Comments

@lgatto
Copy link
Owner

lgatto commented Feb 17, 2017

fcol generally stands for a feature variable from which to extract to vector/factor, while groupBy expects a vector/factor. This lead to a problem in combineFeatures (which expects the latter) calling nFeautres (expecting the former).

Revise this behaviour, making sure that the two are supported interchangeably.

@lgatto lgatto self-assigned this Feb 17, 2017
@sgibb
Copy link
Collaborator

sgibb commented Feb 20, 2017

Generally I like and prefer the groupBy argument because it is very flexible and don't depend on values stored in an MSnSet object. But for most users the fcol argument would be easier to understand and in most cases more than enough flexibility.

We could provide both and rewrite all groupBy/fcol functions as follows:

combineFeatures <- function(object, groupBy, fcol) {
  if (missing(groupBy)) {
    groupBy <- fData(object)[, fcol, drop=FALSE]
  }
  # ...
}

(or wrap that in a .groupBy <- function(object, groupBy, fcol) function)

Or we take the length and type of the argument: if groupBy is of length == 1 and type character treat it as fcol and otherwise as groupBy (but that would be less clear for the user and more error prone than the approach with both arguments above).

@lgatto
Copy link
Owner Author

lgatto commented Feb 20, 2017

I agree that groupBy is flexible, by I don't see any reason for not adding that vector/factor as a feature variable for improved traceability.

Or we take the length and type of the argument: if groupBy is of length == 1 and type character treat it as fcol and otherwise as groupBy.

That's what I had in mind. In addition, we would need to make sure that length(groupBy) == nrow(object) and fail with informative error messages if either case/conditions are not met. I thought of a function that would do all that and that we could call in combineFeature (and possibly in other functions).

I also like the other option with two arguments, groupBy and fcol. That would be a direct and good solution for combineFeatures, but I am thinking that it would be good to generalise supporting both options, and a helper function is the way to go. I would still consider two arguments to combineFeatures to harmonise the way this is done in MSnbase and pRoloc (generally through fcol rather than groupBy), but I would need review the code to make sure I am right.

@lgatto lgatto closed this as completed in 9c902c5 Jan 11, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants