Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

Proposal: `ConcatenateSortingAnalyzer`

未关闭
  • 哪里不对？
#4,878 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
35/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
活跃
技术栈
python
领域
data

调研方向

Start by reading the existing SortingAnalyzer and analyzer extension APIs to understand how extensions expose data. Then identify how child analyzers, matching unit maps, and shared recording channels should be represented; the proposal does not name specific files or tests. Done means a read-only concatenated analyzer can expose compatible extension data across its constituent analyzers and save a minimal JSON representation.

由索引模型根据 Issue 内容生成。

描述

chronic discussion

For very long recordings, or recordings made at different times over many days, you might not want a single SortingAnalyzer. For example, it might be helpful to consider metrics as time varying measures of unit quality: if your firing rate is consistent for 3 days, then drops significantly, this might be a sign that your recoridng device can no longer record the unit. More practically, on many systems it is difficult to parallelize a post-processing computation on a 300 hour analyzer. Whereas making 300 one hour computations might be much easier. For unit matching, you almost certaintly want to sort and postprocess each session seperately, but might want a framework to compare sortings.

After discussions with Alessio, I propose to add a ConcatenateSortingAnalyzer class along these lines. Some of these we discussed, some are mine:

  • ConcatenateSortingAnalyzer does not inherit from SortingAnalyzer (there are too many methods we don't need), but mimics the extension structure.
  • ConcatenateAnalyzerExtensions inherits from AnalyzerExtenions
  • We do not touch the SortingAnalyzer class
  • It is primarily a data reader of many analyzers => you cannot compute/modify the constituent analyzers
  • The input is a dict(?) of analyzers
  • Demand that recording channels are the same
  • Demand that parameters (e.g. peak_sign), extensions and extension parameters are the same. Many properties are then just equal to the property of any child analyzer.
  • Keep complexity of data wrangling in the get_data method of each extension, which can now accept an analyzer_index (or analyzer_key) argument. Keep in mind that in the future, we might want to slice the concatenated analyzers.
  • The sparsity of the concatenated analyzer's units is the intersection of sparsities of each individual unit
  • The user can provide maps to match units. Keep in mind that in the future, we might want to algoithmically generate these.
  • It's ok that main_channel_indices can vary between analyzers. These are used primarily for computation of the sparsity and computation of metrics.
  • save just saves a minimal json representation of the underlying analyzers

What do people think? Thought/suggestions welcome!

主要语言
Python
星标
866
派生
285
平均合并
2 天 7 小时
30 天内合并 PR
43

环境准备

这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

SpikeInterface/spikeinterface 的其他 Issue

查看 SpikeInterface/spikeinterface 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。