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

Use a class-based/OOP approach for pixel and cell clustering process #576

Closed
alex-l-kong opened this issue May 31, 2022 · 1 comment
Closed
Labels
enhancement New feature or request

Comments

@alex-l-kong
Copy link
Contributor

Is your feature request related to a problem? Please describe.

NOTE: this is a long-term project that should only be completed once we've fleshed out the vast majority of the pixel and cell clustering issues and requests.

Currently, the pipeline is completely functional in its approach. There are a few problems with this:

  • Excessive parameter passing: we often have to pass the names of intermediate files, and it gets cumbersome having to keep track of all of these in one notebook.
  • Resource management: because we have to save intermediate files for many variables, it becomes difficult to keep track of all the main and intermediate data we create. We would like to keep some of this info stored in one shared resource, which a class allows us to do. Additionally, this may help remove the need to save a few intermediate files.
  • Experiment tracking: once we start addressing this, it will be easier to use an OOP approach for computing metrics and storing previous parameters. It may play better with model-saving libraries such as joblib.

Describe the solution you'd like

We should create two classes: PixelCluster and CellCluster, that serve as hubs for each experiment. Each class should include their respective functions.

Ideally, we would piggyback off of sklearn.BaseEstimator, which includes functions such as fit, transform, and fit_transform. However, since the training is done in R and it doesn't follow a traditional Pythonic approach, we may need to think of a different approach.

@alex-l-kong alex-l-kong added the enhancement New feature or request label May 31, 2022
@ngreenwald
Copy link
Member

This was mostly addressed in the recent refactor.

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

No branches or pull requests

2 participants