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

Generalised reader #2

Open
achilleas-k opened this issue Sep 13, 2016 · 0 comments
Open

Generalised reader #2

achilleas-k opened this issue Sep 13, 2016 · 0 comments

Comments

@achilleas-k
Copy link
Member

achilleas-k commented Sep 13, 2016

Copied from G-Node/python-neo-nixio#35

I'm opening this issue to request comments about a general purpose reader.

The main question is whether the reader should handle arbitrary NIX files. In other words, should the reader assume that the NIX file was written by the writer and expect to find a structure and, more importantly, attribute values that the reader sets?

This essentially boils down to whether the reader will be used to read data in existing NIX files, or whether the intended use case for the reader is simply to read files that were created by the writer.

The first draft of the reader is not general. For certain objects (e.g., DataAarrays), it assumes that the type attribute indicates the original Neo type. It also assumes that DataArrays which represent signals are grouped by a metadata section.

A generalised reader could infer the appropriate Neo data type from the dimensions of a DataArray or MultiTag, though I can imagine some issues with the latter (is a MultiTag which holds a series of timestamps an Event or a SpikeTrain?).

Response from twachtler on original issue

It would be very nice to have a truly general reader, but as you indicate this would require a lot of heuristics. For the time being, I'd recommend focusing on reading just appropriately typed data, at least until we have the first working writer-reader.

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

No branches or pull requests

1 participant