Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Proposal: `ConcatenateSortingAnalyzer`

オープン
  • 何か問題がありますか？
#4,878 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
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時間
マージ済み PR（30日）
43

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

SpikeInterface/spikeinterface のほかの issue

SpikeInterface/spikeinterface の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。