-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
DOC: switch pylab example mri_with_eeg.py
to OO interface + cosmetick fixes
#7192
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
DOC: switch pylab example mri_with_eeg.py
to OO interface + cosmetick fixes
#7192
Conversation
# NB: one uses "if 1:" to break up the different regions of code visually | ||
fig = plt.figure("MRI_with_EEG") | ||
|
||
if 1: # Load the 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.
I really dislike this syntay. Can we get rid of this? It is using python code for documentation purposes.
Having comments should be enough to break the different regions of the code visually.
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.
I pushed a new commit (d06e572) that get rid of this idiom.
ax2.set_yticklabels(['PG3', 'PG5', 'PG7', 'PG9']) | ||
|
||
ax2.set_xlabel('Time (s)') | ||
""" |
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.
I am sorry, but I still don't like this. This is also python code, meant for a specific purpose. Can you switch to comments?
@afvincent @NelleV maybe it is better to convert these branches to functions like |
@Kojoley that would make the example slightly harder to follow. I am pretty sure it would be quite easy to make the blocks stand out just with comments and approrpiate blank lines. We have many examples that are more complex than this one in the documentation, and are yet very readable. |
@Kojoley In this particular case, I am not sure that converting everything into functions is worth the extra overhead, as there is nothing really repeating itself among the different parts of the script. @NelleV I switched to simple comment lines: I hope it is closer to what you had in mind. By the way, here is what the picture looks like with this PR: |
That looks really cool :) |
mri_with_eeg.py
to OO interface + cosmetick fixesmri_with_eeg.py
to OO interface + cosmetick fixes
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.
A few minor things.
ax1 = fig.add_subplot(2, 2, 2) | ||
im = np.ravel(im) | ||
im = im[np.nonzero(im)] # Ignore the background | ||
im = im / (2**15) # Normalize |
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.
So this is how it was originally, but I'm not sure if it's right. The intensities go over 1 and a uint16
should have a maximum of 2**16, but maybe this just how MRIs are defined? I don't know, but it seems odd.
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.
ping @matthew-brett our resident expert on MRI :)
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.
I agree that this normalization seemed weird to me too but I did not feel comfortable changing it to (2**16 - 1) as I do not know anything about MRI. PS: anyway, currently there are no units for the MRI...
numSamples, numRows = 800, 4 | ||
eegfile = cbook.get_sample_data('eeg.dat', asfileobj=False) | ||
print('Loading EEG %s' % eegfile) | ||
data = np.fromstring(open(eegfile, 'rb').read(), float) |
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.
Leaky open
; can use np.fromfile(eegfile, float)
instead
fig = plt.figure("MRI_with_EEG") | ||
|
||
# Load the MRI data (256x256 16 bit integers) | ||
dfile = cbook.get_sample_data('s1045.ima.gz') |
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 file should be closed.
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.
get_sample_data
should probably be deprecated and replaced with something with a sane interface.
In any case, python will close that file automatically at the end of the script without problems considering it is a read-only file.
While waiting for more info on what to do about the normalization, the commit c8388f9 takes care of the leaky |
@NelleV Looking at the files in the |
Either is fine to me. I can also review it and readapt my +1 whether the patch seems satisfying or not. I have started on the integration of sphinx-gallery yesterday, so I may have new specific requests on how to document examples (It is basically a docstring with a title, and a description - nothing fancy). |
"""Displays a set of subplots with an MRI image, its intensity histogram and | ||
some EEG traces. | ||
|
||
NB: ones uses the imshow command instead of pcolor which *is much faster*. |
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.
Delete this comment line. Even mentioning pcolor here is confusing. I suspect the line dates back to the very earliest days, when imshow was first added to mpl.
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.
You were right (see 6721163). I have removed it.
Finally I have normalized the MRI data in @NelleV The next two commits (db3d206 and 96ff817) fix the similar example ( Edit: added a picture. |
@afvincent I am not happy with what sphinx-gallery requires (there is a small incoherence IMO between the way you write a title) so I am opening a bug on the sphinx-gallery issue tracker.
If the title is written in rst format, then sphinx-gallery also displays it as the figure name in the gallery (instead of the file name as it is right now in our gallery). Last element, we'll have to rename examples that plot a figure into |
Never mind… It does seem to require a header and a text at all times. I don't know how I manage to compile the documentation before… |
It's a little late, but I will raise the question anyway: is there any point in keeping mri_demo, given that its contents are repeated in mri_with_eeg? |
@efiring That's an excellent questions. I've going through the examples lately, and there are a lot of repeats with slight variations. Writing up a bit of documentation on these examples will probably help identifying duplicates and reduce our examples size. |
I really wish that the old comments got folded again 😞 |
DOC: switch pylab example `mri_with_eeg.py` to OO interface + cosmetic fixes
Backported to v2.x as 17fab80 |
mri_with_eeg.py
to OO interface + cosmetick fixesmri_with_eeg.py
to OO interface + cosmetick fixes
The first commit switch the script to pyplot OO interface. The next ones perform some minor cosmetick adjustements, either in the plot layout or the doctsrings and the comments.
If the added MultipleLocator is too much, then I think that at least one should not force negative xticks as former l. 32 did: they are no negative values in the MRI data.
Additional remark: I am not a big fan of the
blocks. I wonder if simple
would not be as well OK visually and more semantically correct.