Write onsets and durations with more decimal digits #72
Conversation
| # Modify it to have a start time with high precision | ||
| edf_high = @set edf.signals[end].records[1][2].onset_in_seconds = 1e-7 | ||
| @test edf_high.signals[end].records[1][2].onset_in_seconds == 1e-7 | ||
| py = mne_read(edf_high) |
There was a problem hiding this comment.
this errors on main (or rather, on #71) because we hit the failed to fit number into EDF's 8 ASCII character limit path in _edf_repr here when going through EDF.write. On this branch it does not error because we just write it out with all digits, even if MNE will round them down later.
|
I've realized this totally contradicts the docstring of |
| @@ -81,7 +81,7 @@ const DATADIR = joinpath(@__DIR__, "data") | |||
| [TimestampedAnnotationList(4.0, nothing, String[""]), TimestampedAnnotationList(2.5, 2.5, ["type A"])], | |||
| [TimestampedAnnotationList(5.0, nothing, String[""])]] | |||
| @test all(signal.records .== expected) | |||
| @test AnnotationsSignal(signal.records).samples_per_record == 16 | |||
| @test AnnotationsSignal(signal.records).samples_per_record == 20 | |||
There was a problem hiding this comment.
more bytes per TAL (since more digits) means a higher number here, IIUC
|
This does not help with my actual bug (#74) although I do think we should make sure small durations / onsets are supported. IMO that doesn't need to write them in full precision like this PR though. |
|
I incorporated this into #75, there choosing 100ms precision matching EDFlib. But we could allow more precision there too. |
https://www.edfplus.info/specs/edfplus.html#tal
We are currently subjecting our onsets and durations to the strict 8-char limitation of EDF headers, but that does not seem necessary.
Note this is mostly orthogonal to #70, since that PR does not use scientific notation in TALs anyway (but it does allow underflow-to-zero there, which we can get rid of this way).