Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add new record info data classes #417

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Add new record info data classes #417

wants to merge 1 commit into from

Conversation

cx1111
Copy link
Member

@cx1111 cx1111 commented Aug 31, 2022

The first step in separating out the record info from the record object itself.

sig_name: Optional[str] = None


class SignalSet:
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No unit tests for this because I need to think more about how these data classes are to be constructed.



@dataclass
class RecordInfo:
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thought about having a separate class for multi-segment headers but it seemed overkill.

Signal specification fields for one signal
"""

file_name: Optional[str] = None
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Open to suggestions about nullability/validation here.

@cx1111 cx1111 requested a review from bemoody August 31, 2022 04:46
@bemoody
Copy link
Collaborator

bemoody commented Sep 7, 2022

I have a few thoughts. To start with: are these classes supposed to be a description of the data files, or a description of the data?

Confusion between these two roles is a problem with the existing API. For example: wfdb.rdrecord sets the skew attribute if the signal file is skewed, but Record.wrsamp interprets skew as meaning that the signal array is skewed.

Something else to think about is that the test suite does a lot of checks along the lines of "are these two Record objects identical", when what we really want to ask is "do these two objects contain identical data, despite having been created in different ways?"

I would seriously consider having different classes for signal file info (filename, format, byte offset, block size) versus signal info (the rest of that stuff.)

Nullability: If applications are expected to construct a SignalInfo object then the application shouldn't have to specify a value for samps_per_frame. But when I read a record that has one sample per frame, I want samps_per_frame to be 1, not None, regardless of how it's written in the header file. I don't know if that answers the question or not.

Validation: cautiously, I'd be inclined to validate the data when you try to use it (to write a signal file) and not beforehand, especially since validation can depend on relationships between the fields. On the other hand, it might make sense to do type-checking (distinct from validation) as early as possible.

Multi-segment: a multi-segment header isn't the same type of data as a single-segment header (one contains a list of segments, the other contains a list of signals). But a multi-segment record is the same type of data as a single-segment record (the latter can be treated as a special case of the former, or the former can be transparently extended so it behaves like the latter.) The API should preferably be agnostic to the format. That doesn't answer the question of how the Python objects should be structured, because I think it depends on how these objects are going to be used in the larger API.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants