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

Kernel param for apply inverse #6609

Closed
wants to merge 27 commits into from

Conversation

DiGyt
Copy link
Contributor

@DiGyt DiGyt commented Jul 27, 2019

Reference issue

This is one step for the GSoC TFR in Source Space Project (See: Issue #6290 ).

What does this implement/fix?

This change will allow the user to decide which data fields are returned from apply_inverse_epochs.
An according if statement was already implemented, but previously assigned to an impossible if case.
If full_data=True, the full data field will be returned (as usual). If full_data=False, the stc data will instead be returned as a tuple of (kernel, sensor_data). The real data is then automatically created when calling stc.data .

Additional information

Unfortunately, this only works for fixed orientations. For free orientations, this causes problems, since data is reshaped and multiplied with noise_nn in _make_stc, steps that else need to be added when calling stc.data .

Signed-off-by: Dirk Gütlin <dirk.guetlin@stud.sbg.ac.at>
- Added test to check the full_data param

Signed-off-by: Dirk Gütlin <dirk.guetlin@stud.sbg.ac.at>
Signed-off-by: Dirk Gütlin <dirk.guetlin@stud.sbg.ac.at>
@codecov
Copy link

codecov bot commented Jul 27, 2019

Codecov Report

Merging #6609 into master will increase coverage by <.01%.
The diff coverage is 91.42%.

@@            Coverage Diff             @@
##           master    #6609      +/-   ##
==========================================
+ Coverage   89.48%   89.48%   +<.01%     
==========================================
  Files         420      420              
  Lines       75601    75621      +20     
  Branches    12382    12385       +3     
==========================================
+ Hits        67654    67673      +19     
  Misses       5139     5139              
- Partials     2808     2809       +1

mne/minimum_norm/inverse.py Outdated Show resolved Hide resolved
mne/minimum_norm/tests/test_inverse.py Outdated Show resolved Hide resolved
mne/minimum_norm/tests/test_inverse.py Outdated Show resolved Hide resolved
Signed-off-by: Dirk Gütlin <dirk.guetlin@stud.sbg.ac.at>
@DiGyt
Copy link
Contributor Author

DiGyt commented Jul 29, 2019

it should be

if delayed

delayed means delay the application of the kernel

Oops, sure! Sorry, I forgot to switch it...

-switched True/False of delayed param

Signed-off-by: Dirk Gütlin <dirk.guetlin@stud.sbg.ac.at>
@agramfort
Copy link
Member

agramfort commented Jul 30, 2019 via email

@DiGyt
Copy link
Contributor Author

DiGyt commented Jul 30, 2019

cd mne git grep ":class:" yes I sure you can be more explicit in the docstring.

OK, thanks a lot!

@DiGyt
Copy link
Contributor Author

DiGyt commented Jul 30, 2019

cd mne git grep ":class:" yes I sure you can be more explicit in the docstring.

OK, i didn't find any class that links directly to the SourceEstimate data attributes -> parameter. I was looking for something linking directly to the data explanation like :attr:`stc.data <mne.SourceEstimate>` . But if this is not possible, i'll just link the SourceEstimate.

Signed-off-by: Dirk Gütlin <dirk.guetlin@stud.sbg.ac.at>
Copy link
Member

@agramfort agramfort left a comment

Choose a reason for hiding this comment

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

do you check / test somewhere that pick_ori must be normal if delayed=True?

mne/minimum_norm/tests/test_inverse.py Outdated Show resolved Hide resolved
DiGyt and others added 2 commits July 30, 2019 13:47
Co-Authored-By: Alexandre Gramfort <alexandre.gramfort@m4x.org>
Co-Authored-By: Alexandre Gramfort <alexandre.gramfort@m4x.org>
@DiGyt
Copy link
Contributor Author

DiGyt commented Jul 30, 2019

do you check / test somewhere that pick_ori must be normal if delayed=True?

Well technically source_ori="vector" and delayed=False does not lead to an error but is just omitted, so that in this case, the full data field is still created. Should i raise an error or just write in the documentation that it will be omitted (+ maybe a warning)?

...from get_epochs to epochs

Signed-off-by: Dirk Gütlin <dirk.guetlin@stud.sbg.ac.at>
Signed-off-by: Dirk Gütlin <dirk.guetlin@stud.sbg.ac.at>
Signed-off-by: Dirk Gütlin <dirk.guetlin@stud.sbg.ac.at>
- implemented computing of delayed for vector oris
- changed docstring accordingly
- enhanced tests to vector repr.

Signed-off-by: Dirk Gütlin <dirk.guetlin@stud.sbg.ac.at>
tstep=tstep, subject=subject)
else:
return Klass(data=data, vertices=vertices, tmin=tmin, tstep=tstep,
subject=subject)
Copy link
Contributor

Choose a reason for hiding this comment

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

That's not how it works.

There should be a single return.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

oh sry, I did it because of
#6609 (comment)

But now I see what you mean. I'll change that

Copy link
Contributor

Choose a reason for hiding this comment

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

f254a95 is not what I meant. I meant to keep a single
return Klass(.. to keep the logic we wrote in #6636. The entire purpose of #6636 was to keep this one simple.

Maybe I'm missing something. I'll give it a shot.

Copy link
Contributor

Choose a reason for hiding this comment

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

Actually I already wrote it for you here #6609 (comment)

But I think that e41236f is even cleaner.

Copy link
Contributor Author

@DiGyt DiGyt Aug 21, 2019

Choose a reason for hiding this comment

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

Actually I already wrote it for you here #6609 (comment)

Yes, it just seemed to me that you'd be most in favor of:

+                stc = VectorSourceEstimate(
+                    data=(data_rot, sens_data), vertices=vertices, tmin=tmin,
+                    tstep=tstep, subject=subject
+                )
+            else:
+                stc = VectorSourceEstimate(
+                    data=data_rot, vertices=vertices, tmin=tmin,
+                    tstep=tstep, subject=subject
+                )

But anyhow, I like your solution with the sentinel (tbh I didn't know about that practice). But it gets rid of that is_kernel bool and it's compact. So, for me, that's fine!


@massich

Copy link
Contributor

Choose a reason for hiding this comment

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

The code is meant to read by people (machines executing it is secondary), and usually, the flow is: look at the definition, look at the return check whatever else afterward. If you have 2 returns or you construct the return in 2 different places (which is the same thing) I need to understand what's in the middle of the function. Most of the time when you read a function it is not for debugging purposes I just want to skim through it and get a good grasp of whats going on.

If I have a single place that returns Klass and does something at data and this is in the return, I need no further reading. This function is a factory. Based on whatever, chooses which class to construct and modifies the data accordingly.

@DiGyt this is a nice read on sentinel https://treyhunner.com/2019/03/unique-and-sentinel-values-in-python/

Copy link
Contributor

@massich massich left a comment

Choose a reason for hiding this comment

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

@DiGyt
Copy link
Contributor Author

DiGyt commented Aug 20, 2019

see https://github.com/mne-tools/mne-python/pull/6609/files#r315565439

@massich thanks for the review. I adressed your problem.

@massich
Copy link
Contributor

massich commented Aug 21, 2019

@massich massich self-requested a review August 21, 2019 16:59
@larsoner larsoner modified the milestones: 0.19, 0.20 Sep 11, 2019
alexrockhill pushed a commit to alexrockhill/mne-python that referenced this pull request Oct 1, 2019
@larsoner
Copy link
Member

larsoner commented Mar 4, 2020

Moving the milestone for this to 0.21

@larsoner larsoner modified the milestones: 0.20, 0.21 Mar 4, 2020
@larsoner larsoner modified the milestones: 0.21, 0.22 Aug 31, 2020
@larsoner larsoner modified the milestones: 0.22, 0.23 Dec 1, 2020
Base automatically changed from master to main January 23, 2021 18:26
@DiGyt DiGyt closed this Feb 22, 2021
@DiGyt
Copy link
Contributor Author

DiGyt commented Feb 22, 2021

Closed: See Issue #6290

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

Successfully merging this pull request may close these issues.

None yet

4 participants