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

Function for aligning continuous variables to trial by trial events #8

Open
alexpiet opened this issue Feb 12, 2024 · 12 comments
Open
Labels
enhancement New feature or request

Comments

@alexpiet
Copy link
Collaborator

  • We need a function that takes a tidy data frame of behavioral events, and a tidy data frame of a continuous variable (neural data, or video extracted behavioral variables), and returns the continuous variable in a window (+/- some seconds) around each event.
  • For example, give me the value of the pupil diameter in the 0.2 seconds before and after each go cue
  • The output is a a table with rows as behavioral events (which is sometimes one per trial), and the column is a list of that behavioral variable.
  • We should include the option to interpolate the continuous variable onto common timestamsp
  • We should grab a lot of useful code from this repository, but maintain our own:
@alexpiet
Copy link
Collaborator Author

Common time stamps rate should be given as an input. Default value should be the continuous variable rate.

@rachelstephlee
Copy link
Collaborator

Use mindscope_utilties, event_triggered_response, use the commit af2b70a

@rachelstephlee
Copy link
Collaborator

I have a first pass running through this, but there are some data that have missing activity during the event_times. should we ignore those events ?

@alexpiet
Copy link
Collaborator Author

If we have missing data around an event, I think we should return the aligned data for that event as NaN where it is missing. The NaN could be the entire, or part of, the window for a specific event.

@rachelstephlee
Copy link
Collaborator

Coverage only passes the unit test if all functions are in a class. Would you want that or should we skip on the src files?

Not sure if it'll fit with how you want this to be lightweight.

@jsiegle
Copy link

jsiegle commented Feb 29, 2024

Since this will be such a widely used utility function, I would propose putting this in a different repo that is shared across projects. I think the MindScope utilities version is a good starting point, but we should move it to a package we maintain. See the latest version of the planning document for my proposed division of functionality.

@rachelstephlee
Copy link
Collaborator

We should meet once Alex is back then-- he envisioned something more lightweight than multiple packages, each specified for a type of data or for behavior.

@jsiegle
Copy link

jsiegle commented Mar 1, 2024

Happy to chat about it! It may make sense to implement this initially in dynamic-foraging-analysis, but eventually it will need to be reused across many projects

@alexpiet
Copy link
Collaborator Author

alexpiet commented Mar 4, 2024

Coverage only passes the unit test if all functions are in a class. Would you want that or should we skip on the src files?

Not sure if it'll fit with how you want this to be lightweight.

Seems unnecessary to have all functions in a class. I'm not familiar with the tests, so can we disable that requirement?

@alexpiet
Copy link
Collaborator Author

alexpiet commented Mar 4, 2024

Happy to chat about it! It may make sense to implement this initially in dynamic-foraging-analysis, but eventually it will need to be reused across many projects

My concern is creating a repository that has so many people using it that it becomes impossible to update (AllenSDK). This function is obviously something that other projects will use, but we should be very intentional about what goes in a shared repo.

@jsiegle
Copy link

jsiegle commented Mar 5, 2024

My inclination to divide things across multiple repos also stems from my experience with the AllenSDK. If all analysis code lives in one package, it starts to develop idiosyncrasies that make it difficult for others to reuse/contribute to. The biggest problem with the AllenSDK was probably the fact that numerous pinned dependencies made it impossible to install in an existing environment, but a tangential problem was that its monolithic nature meant that very few people inside the Institute actually used it as a starting point for exploratory analysis. Obviously we are not trying to create something on the same scale, but I think it's important to plan for the type of code ecosystem we want to end up with before investing significant time building shared packages.

Looking forward to chatting more about this!

@hanhou hanhou added the enhancement New feature or request label Mar 6, 2024
@rachelstephlee rachelstephlee removed their assignment Jun 14, 2024
@alexpiet
Copy link
Collaborator Author

alexpiet commented Aug 5, 2024

  • need to add testing functions
  • check mindscope_utilities for other useful functions
  • add documentation for alignment, especially interpolation step

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

4 participants