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

Refactor expDesign #84

Merged

Conversation

marcobarilari
Copy link
Collaborator

@marcobarilari marcobarilari commented Jul 3, 2021

This refers to the function in use for MT+ localizer (nb: MT/MST has its own design function for the moment)

TO DO:

Refactoring

Features improvements

Annex

  • improve doc in README
  • Improve doc in the function
  • unit test

@marcobarilari marcobarilari self-assigned this Jul 3, 2021
@marcobarilari marcobarilari added enhancement New feature or request good first issue Good for newcomers help wanted Extra attention is needed priority 1 High priority labels Jul 3, 2021
@codecov
Copy link

codecov bot commented Jul 3, 2021

Codecov Report

Merging #84 (50e6683) into dev (6854071) will not change coverage.
The diff coverage is 0.00%.

❗ Current head 50e6683 differs from pull request most recent head 1a9573c. Consider uploading reports for the commit 1a9573c to get more accurate results
Impacted file tree graph

@@          Coverage Diff          @@
##             dev     #84   +/-   ##
=====================================
  Coverage   0.00%   0.00%           
=====================================
  Files         12      14    +2     
  Lines        220     224    +4     
=====================================
- Misses       220     224    +4     
Flag Coverage Δ
unittests 0.00% <0.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
subfun/expDesign.m 0.00% <0.00%> (ø)
subfun/expDesignMtMst.m 0.00% <ø> (ø)
subfun/getDesignInput.m 0.00% <0.00%> (ø)
subfun/setBlocksConditions.m 0.00% <0.00%> (ø)
subfun/setDirections.m 0.00% <0.00%> (ø)
subfun/setFixationTargets.m 0.00% <0.00%> (ø)
subfun/setSpeedTargets.m 0.00% <0.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4f379d8...1a9573c. Read the comment docs.

marcobarilari and others added 18 commits July 3, 2021 22:51
…te a matrix of zeros (ergo no change of fixation to show)
@Remi-Gau
Copy link
Contributor

added some tests.

do you want to also refactor the MT MST one ? It should be fairly straight forward now, no? (famous last words)

assertEqual(speeds, ones(20, 12) * 28);

% try when the target are just for the fixation cross
cfg.target.type = {'fixation_cross'};
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

why fixation targets here?

Copy link
Contributor

Choose a reason for hiding this comment

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

if there are only fixation cross as targets then setSpeedTargets must return only zeros.

So it is a second test.

Will break it down into 2 to avoid confusion

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Ok here I have "updated" the test meaning that now, being WIP, the two tests are checking for the same results (a matrix full of ones).

Added a reminder in #89

@marcobarilari
Copy link
Collaborator Author

Hey sorry for being late on the reply here.

do you want to also refactor the MT MST one ? It should be fairly straight forward now, no? (famous last words)

I am tempted to do that in a new PR cause I suspect that a separate design for MT_MST might be useless now and with few 'if/switch' statements we can do the trick.

Also, I see that in some functions the copyright tag has been moved below the function [out] = myFunc(in) call. The style used 'everywhere' is to put it in the very first line, isn't it?

I am a bit confused by the test for the speed task because I see code related to the fixation task there. So my idea is to use setSpeedTargets to implement a task where the subj has to detect the eg 'faster dots trial'. The output matrix is full of values that are multiplicators of cfg.dot.speed = 15; so that if the matrix reports a 1, then it has the set speed (no change in speed), if eg 2 for a given trial then that speed will be doubled. I know it is hard to get from the code as it is right now but it is because it is WIP and to implement when someone will need that.
The idea is also the possibility to have >1 task in the same experiment if needed, as fixation target && dot faster speed target

@Remi-Gau
Copy link
Contributor

Remi-Gau commented Aug 3, 2021

Also, I see that in some functions the copyright tag has been moved below the function [out] = myFunc(in) call. The style used 'everywhere' is to put it in the very first line, isn't it?

Until recently miss_hit only allowed the top line, but that would mess up using the "help" command on Octave and very few matlab codebases put the copyright there.

So this has changed and we can now use the more conventional "copyright at the end of the help section".

No need to change all functions now, but if you run into a function where it is still in the top line, put it at the end of the help section.

@Remi-Gau
Copy link
Contributor

Remi-Gau commented Aug 3, 2021

I am tempted to do that in a new PR cause I suspect that a separate design for MT_MST might be useless now and with few 'if/switch' statements we can do the trick.

Agreed

@Remi-Gau
Copy link
Contributor

Remi-Gau commented Aug 3, 2021

I am a bit confused by the test for the speed task because I see code related to the fixation task there. So my idea is to use setSpeedTargets to implement a task where the subj has to detect the eg 'faster dots trial'. The output matrix is full of values that are multiplicators of cfg.dot.speed = 15; so that if the matrix reports a 1, then it has the set speed (no change in speed), if eg 2 for a given trial then that speed will be doubled. I know it is hard to get from the code as it is right now but it is because it is WIP and to implement when someone will need that.

Ah OK I get it now: I was not sure what was expected so I sort of made a wild guess: then the code and test need to be updated.

Comment on lines +8 to +17
if ismember('speed', cfg.target.type)
[~, nbEventsPerBlock, ~, nbBlocks] = getDesignInput(cfg);
speeds = ones(nbBlocks, nbEventsPerBlock) * cfg.dot.speedPixPerFrame;

% Outputs an "empty" matrix in case no speed task is required
else
[~, nbEventsPerBlock, ~, nbBlocks] = getDesignInput(cfg);
speeds = ones(nbBlocks, nbEventsPerBlock) * cfg.dot.speedPixPerFrame;

end
Copy link
Contributor

Choose a reason for hiding this comment

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

I know what confused me on this function.

At the moment both sides of the if block do exactly the same thing, so I thought either the If block is not necessary or the else part must be doing something different from the rest.

Do you see what I mean ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yes you are totally right, kind of impossible to guess. My bad.

Let's say that now the function has the structure for future developments. Let me add some "warnings" here and there to make sure it is clear

Copy link
Contributor

Choose a reason for hiding this comment

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

just a couple of words below the [WIP] will do. :-)


% Set to 1 for a visualtion of the trials design order
if nargin < 2 || isempty(displayFigs)
displayFigs = 0;
Copy link
Collaborator Author

@marcobarilari marcobarilari Aug 3, 2021

Choose a reason for hiding this comment

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

Here, I think it is very important to keep mock input in order to run a trial of the design outside the experiment. Important to understand what it is doing and in case of further development to see if the tasks and trials are arranged as needed. See also #69

Copy link
Contributor

Choose a reason for hiding this comment

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

no worries: I basically took all the mocked content and created the getTestConfig function with it.

We can just rename it ("get mock input"or something ) and move it into the design folder and make a call to that function in the expDesign function.

Makes sense?

Copy link
Collaborator Author

@marcobarilari marcobarilari Aug 4, 2021

Choose a reason for hiding this comment

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

Yes it makes sense, will also improve the doc related to this. Thanks

@marcobarilari
Copy link
Collaborator Author

marcobarilari commented Aug 4, 2021

I moved the left "to do" to new issues and brought back the mock configuration inside expDesign. Apologies if I push for this but it is a time saver for me and also might help future users to understand how it works and what are the inputs there (hope the new comments are clear).

Also added more info about the WIP situation of setSpeedTargets both in the readme and inside the function. Let me know if the test works after this or it needs a fix.

@marcobarilari
Copy link
Collaborator Author

Merging this one

@marcobarilari marcobarilari merged commit 38710ba into cpp-lln-lab:dev Sep 7, 2021
@marcobarilari marcobarilari deleted the marco_streamline-expdesign branch September 7, 2021 14:32
marcobarilari added a commit that referenced this pull request Sep 7, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers help wanted Extra attention is needed priority 1 High priority
Projects
None yet
2 participants