-
Notifications
You must be signed in to change notification settings - Fork 10
Adding unit test for oneepoch #337
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
Conversation
Update to latest NDI ndr reader
Unless I'm doing something wrong, the int16 issue seems to still exist.
NDI-matlab/+ndi/+daq/+reader/mfdaq.m Line 752 in 59568d2
|
Still need to reorganize test structure.
Still finishing up documentation and organization of unittest
@stevevanhooser I'm still wrapping this up, but the unittest revealed an interesting bug. When the data is created in
|
@stevevanhooser I've completed this draft of a OneEpochTest. I'm not sure if I've maintained all the best practices (it seems difficult to find literature on this), but I used fixtures that will be reusable and included some parameterization of test parameters. The unittest still fails while checking the class of the oneepoch elements as mentioned in my previous comment. |
oneepoch_data = oneepoch.readtimeseries(1,-Inf,Inf); | ||
testCase.verifySize(oneepoch_data,size(probe_data),... | ||
'OneEpoch does not return the expected number of samples.') | ||
testCase.verifyClass(oneepoch_data,class(probe_data),... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is failing for me, too, for unknown reasons. When I went into the debugger, oneepoch_data is in fact a double. So somehow the command isn't working, I don't quite understand.
But I think a better test might be:
testCase.assertEqual(a, b_expected, ...
'Values should be equal, treating NaNs as equal.', ...
'TreatNaNsAsEqual', true);
This not only tests the class and the size but also whether the values are equal (allowing NaNs to be equal as well; by default any NaN makes equal false).
Does that make sense?
That makes sense, though may fail if global time is used and epochs are
non-continuous.
However, shouldn’t oneepoch_data be int16 since white matter data is int16
(and thus probe_data is int16)?
…On Wed, Apr 30, 2025 at 4:27 PM Steve Van Hooser ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In tests/+ndi/+unittest/+element/OneEpochTest.m
<#337 (comment)>:
> + probe_et = probe.epochtable;
+ oneepoch_et = oneepoch.epochtable;
+ testCase.verifyEqual(oneepoch_et.epoch_clock,probe_et(1).epoch_clock,...
+ 'OneEpoch clock type(s) do not match those of the original timeseries.')
+ testCase.verifySize(oneepoch_et,[1,1],...
+ 'OneEpoch epoch table does not contain a single epoch.')
+
+ % Get data
+ probe_data = [];
+ for j = 1:numel(probe_et)
+ probe_data = cat(1,probe_data,probe.readtimeseries(j,-Inf,Inf));
+ end
+ oneepoch_data = oneepoch.readtimeseries(1,-Inf,Inf);
+ testCase.verifySize(oneepoch_data,size(probe_data),...
+ 'OneEpoch does not return the expected number of samples.')
+ testCase.verifyClass(oneepoch_data,class(probe_data),...
This is failing for me, too, for unknown reasons. When I went into the
debugger, oneepoch_data is in fact a double. So somehow the command isn't
working, I don't quite understand.
But I think a better test might be:
testCase.assertEqual(a, b_expected, ...
'Values should be equal, treating NaNs as equal.', ...
'TreatNaNsAsEqual', true);
This not only tests the class and the size but also whether the values are
equal (allowing NaNs to be equal as well; by default any NaN makes equal
false).
Does that make sense?
—
Reply to this email directly, view it on GitHub
<#337 (review)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AJDALDOEPTVEDJZSJ7MK6PD24FL5ZAVCNFSM6AAAAAB37ODJGCVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDQMBYHAYTIMZQHE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Oh I see. oneepoch_data will be double because I think it is stored by addepoch as double when it is written to the binary file: vhsb can use other datatypes but we haven't engaged them (we'd have to pass those parameters with name/value pairs). So I guess it won't be equal, although you could cast the directly-read probe data to double and then test, since you know element_epochs will be double. Instead of testing the entire epoch, you could pick a few values that are easy to calculate. If you can easily calculate the value of samples 1500, 1550, 2500, 10000, for example, then you could only test those values, and you might not have to rebuild the whole one epoch vector again from the probe epochs (with the fill-in). |
@stevevanhooser okay! That makes sense. I'll update that code. |
Is this ready to be merged? |
Almost. I need to fix the verifyClass issue. I’ll have this done today and
will send you a notification.
…On Mon, May 5, 2025 at 11:45 AM Steve Van Hooser ***@***.***> wrote:
*stevevanhooser* left a comment (VH-Lab/NDI-matlab#337)
<#337 (comment)>
Is this ready to be merged?
—
Reply to this email directly, view it on GitHub
<#337 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AJDALDIIQRQAUVSPMVOOP7T246WVHAVCNFSM6AAAAAB37ODJGCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQNJRHE4TKMRVGY>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
@stevevanhooser this should be ready to merge now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! Works on my end
@stevevanhooser having some problems with ingestion of white matter data...
+ndi/+daq/+reader/+mfdaq/ndr.m
and+ndi/+daq/+reader/mfdaq.m
(see quick fixes in changed files on this branch).int16
data. Try running theOneEpochTest
. It breaks onS.ingest()
due to issues in+ndi/+daq/+reader/mfdaq.m
starting withunderlying_datatype()
.