ENH: add reader for NeuroElectrics .nedf files

[tstenner]

This PR adds a reader for the NeuroElectrics .nedf file format.

Compared to the NEPy package, it's about 70 times faster (due to vectorized reading with numpy.fromfile) and correctly handles (at least) the NEDF 1.3 and 1.4 files.

Once the sample data file (mne-tools/mne-testing-data#80) has been added, I'll add a unit test.

[larsoner]

I'll went ahead and merged the testing dataset so that you can add tests -- if we need more data or documentation for the testing file we can always add it later

[larsoner]

0.113 hash when I downloaded it was ce114ad6d5e3dbed06119386e6b1ce0c

[larsoner]

Looks good! See comments about STIM channels and potential preload support

[larsoner]

Okay pushed commits to:

1. Add _test_raw_reader
2. Remove assert_equal in favor of plan pytest assert a == b
3. Remove assert_raises from NumPy in favor of pytest.raises with more targeted matches
4. Change handling of stim channels to create STI 014 out of the stim data
5. Add non-preload support
6. Handle last samples properly (previous version discarded the last 3 samples of data because they didn't fit evenly into the 5-sample standard)

Feel free to take a look and see if it makes sense @tstenner ! Happy to talk through / explain any changes, or fix things that you see are wrong with what I did

[larsoner]

Also @tstenner can you add your name/URL to doc/changes/names.inc and update doc/changes/latest.inc ? Otherwise LGTM +1 for merge

[tstenner]

Much appreciated, it's been a while since I've seen the insides MNE-Python.

Remove assert_equal in favor of plan pytest assert a == b

Ah, good to know. I saw a bunch of assert_equals in the BrainVision reader tests so I adopted this style.

Handle last samples properly (previous version discarded the last 3 samples of data because they didn't fit evenly into the 5-sample standard)

I'm not sure if it's needed. Most of our in-house readers ignore the last nsamples%5 samples, because it's at most 4 samples, i.e. 8 ms and there's always more data at the end than needed because the recording has to be stopped manually. I'd rather have a somewhat simpler implementation (without allocating space for and copying the whole data in 4/5 cases), but that's just my opinion.

[larsoner]

I'm not sure if it's needed. Most of our in-house readers ignore the last nsamples%5 samples, because it's at most 4 samples, i.e. 8 ms and there's always more data at the end than needed because the recording has to be stopped manually. I'd rather have a somewhat simpler implementation (without allocating space for and copying the whole data in 4/5 cases), but that's just my opinion.

Indeed it's probably overkill in most situations, but if we can read the data correctly rather than omitting some samples 80% of the time I think we might as well do it. This code's one job is to pull/convert the right set of samples from disk, it's a shame to do it for all but the last few :) And ultimately the code to handle it did not end up being too complex.

If efficiency is a concern we can always make the code more efficient in the future, but I'd rather do that later if we find the copy/concatenate pattern to be a limiting factor in real use cases.

[larsoner]

Thanks @tstenner !