Slice Probe and ProbeGroup by stable identifiers, not positional integers

Aperta
#447 2 commenti 1 reazione 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
30/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Tranquilla
Stack tecnologico
python
Ambito
backend-api-design, data

Direzione di ricerca

Start by reviewing get_slice and the Probe and ProbeGroup APIs, then read the linked discussions and PRs #429 and #446. The work is complete when a stable-identifier-based public selection API and the ProbeGroup identifier behavior have been agreed and implemented for both object types.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Currently get_slice's argument is array-based: selection is positional indices or a boolean mask. I think this is a bad pattern, and I'd like to either change it or add a method that doesn't rely on it, select_contacts, mirroring SpikeInterface's select_channels. I think this should be the blessed public API for sub-selecting contacts of both Probe and ProbeGroup.

Why? Our libraries merge results from different sources (the recording, the probe, and probably headstage information later), and a positional index keeps an implicit "position i here is position j there" map that collides when those sources are combined and goes stale the moment one of them is sliced or reordered. That is how users get bitten, see the reorder-on-attach case in SpikeInterface #4565. The standard solution in the field is to do what databases do: identify a record by a stable primary key rather than by its position. That is, we create object identifiers that are independent of the internal representation.

Using that in SpikeInterface, for example, would solve the metadata propagation bugs related to slicing, grouping and aggregating #4545, #4546, and #4547. It would also remove the need to solve the annotation feature on the array-like slicing, which does not have natural semantics #446.

Finally, I think it is semantically appropriate for the domain. Probes are not arrays, and we should not have a method that assumes they are.

Note that if you think this idea is good we would require #429 (auto-generate contact_ids when not explicitly set). The ProbeGroup unique identifier is an implementation detail that we can discuss if we think this idea is sound.

Lingua principale
Python
Stelle
85
Fork
49
Merge medio
13h 47m
PR unite (30g)
3

Guida per i contributori

Nessuna guida per i contributori indicizzata per questo repository

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di SpikeInterface/probeinterface

Tutte le issue di SpikeInterface/probeinterface

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.