Better API for specifying return data of signals
Nessuno ha ancora preso questa issue.
- Lingua principale
- Jupyter Notebook
- Stelle
- 853
- Fork
- 322
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Descrizione
The current rdrecord API is rather confusing when dealing with more complex records/signals. Namely: multi-frequency signals.
We should create a better API to allow users to:
- Specify/know the exact return types/dimensions of the signals being read
- Deal with single and multi-frequency records consistently.
In addition, the current API is also limiting when reading single-frequency records, as there is no way for users to explicitly specify whether they want 1d or 2d numpy arrays.
We current have: https://github.com/MIT-LCP/wfdb-python/blob/0d42dfb4b2946625f00cbf500d830d374a201153/wfdb/io/record.py#L1715 where the only parameter that influences the return type is: smooth_frames
We've chatted about the issue here, where I suggested a new set of params:
https://github.com/MIT-LCP/wfdb-python/pull/313#issuecomment-1058363761
What do people think of the suggestion of having two params: return_dims and smooth_frames? return_dims will apply for both single and multi-frequency signals, and smooth_frames will apply only to multi-frequency signals. Given the combination of the params, the return value of the signals will be:
(1, True): List of 1d arrays. Guaranteed to be same length.
(1, False): List of 1d arrays. Not guaranteed to be same length for multi-frequency signals.
(2, True): Single 2d array.
(2, False): Illegal combination.
Guida per i contributori
Nessuna guida per i contributori indicizzata per questo repository
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Direzione di ricerca
Leggi prima wfdb/io/record.py intorno alla riga 1715 e la discussione collegata della pull request, poiché i parametri proposti e le questioni di compatibilità sono ancora in discussione. Il lavoro è completato quando sono definite e documentate le forme dei valori restituiti per i segnali a frequenza singola e multipla rispetto a return_dims e smooth_frames, e la combinazione non valida viene gestita in modo coerente.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Valutazione
- Stack tecnologico
- numpy, python
- Ambito
- backend-api-design, data
- Tipo di issue
- Funzionalità
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Stato di attività
- Ferma
- Chiarezza
- Abbastanza chiara
- Idoneità per principianti
- 30/100