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

cluster labels should become dictionaries #23

Open
btel opened this issue Feb 18, 2012 · 4 comments
Open

cluster labels should become dictionaries #23

btel opened this issue Feb 18, 2012 · 4 comments

Comments

@btel
Copy link
Owner

btel commented Feb 18, 2012

No description provided.

@cpcloud
Copy link
Contributor

cpcloud commented Apr 19, 2012

Can you give the location in the code where this needs to happen, and maybe a more specific description of what you want done?

@btel
Copy link
Owner Author

btel commented Apr 23, 2012

Most datastructures in spike_sort such as spike waveforms, features, spike times are dictionaries with at least one key data. In addition, some can also include extra keys such as is_valid, which allows to mask some of the spikes. However, spike labels are pure numpy dictionaries making it hard to apply a mask and append new attributes.

All clustering functions in spike_sort.core.cluster should return dictionaries. Plotting functions should accept the dictionaries in place of numpy arrays. Finally some commponents should be updated, such as ClusterAnalyser.

Before we do that we should make sure to have an unit tests for each affected function.

@belevtsoff
Copy link
Collaborator

Because this will require changing a lot of code (I just "grep"ed the tree: tests, plotting. extracting, and components of course), it will be better to do this in a separate branch and closer to the release date, after we fix the rest of the stuff

@btel
Copy link
Owner Author

btel commented Feb 5, 2013

Because this will require changing a lot of code (I just "grep"ed the tree: tests, plotting. extracting, and components of course), it will be better to do this in a separate branch and closer to the release, after we fix the rest of the stuf

Actually, I don't see a point now in doing it now. The intention was to be able to add properties, and for consistency with other data structures (features, spikes etc. are all dictionaries). We might well, switch it to next release.

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

No branches or pull requests

3 participants