[MRG] ENH: add new property to access spike times by cell type #916
Conversation
jasmainak
force-pushed
the
spike_times_by_type
branch
from
bdef5b9 to
d38c536
Compare
| @property | ||
| def cell_types(self): | ||
| """Get unique cell types.""" | ||
| spike_types_data = np.concatenate(np.array(self.spike_types, | ||
| dtype=object)) | ||
| return np.unique(spike_types_data).tolist() |
There was a problem hiding this comment.
I think this would also include spike types that are from bursty drives. Should this filter for only the cell types? Without hardcoding one way to do this is to have a bidirectional relationship between Network and CellResponse. Similar to what matplotlib does with Figure and Axes.
There was a problem hiding this comment.
I actually want the spike times of the input drives for my work :) They are "artificial cells" ... but yeah not part of the local network. We would need the network object to know which cells are drive cells and which ones belong to the local network. Are you thinking of a net.cell and cell.net attribute? It will create complications for IO, probably more than what I want to bite for this PR
There was a problem hiding this comment.
Yeah, net.cell_reponse is already an attribute. But there's not a way to get information about the parent network at the moment.
This came up in work on the spike raster plot. Currently we hardcode the local cell type names in the plotting function. I was thinking this might not be very flexible if local cell types are ever expanded or names changed.
But now that you mention it... should that plot also include artificial cells and not just the 4 local network? Then I can just grab them all with this property and just call it a day!
There was a problem hiding this comment.
I think @ntolley may be able to answer better. But I think if you want to preserve the functionality, the cell_types (of the local network) from the default jones model may be declared somewhere as a global variable and imported where needed in the codebase ... acknowledging that it's not the best solution but we also don't want to over-engineer
There was a problem hiding this comment.
Agreed, I also think cell_types needs to be re-evaluated, but it's a big task and would need its own issue. The same goes for differentiating between drives and cells using `cell_types.
jasmainak
changed the title
|
updated what's new! |
closes #912