-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Add raw.rescale
#13018
Add raw.rescale
#13018
Conversation
On a related note, could someone who uses Visual Studio Code try to debug my newly added test? Somehow, the debugger seems to be stuck when I (1) set a breakpoint in line 1070 and (2) then debug the test. Running the test does work though! Debugging tests work in other projects, so I was assuming that it's something specific to MNE. And yes, I already removed the venv and created a new one, basically using Screen.Recording.2024-12-10.at.12.03.09.mov |
same result as you. I seem to be hitting microsoft/debugpy#1623
|
Thanks @drammock. So what do we do? The issue is half a year old and it doesn't look like it's on the top of their to do list |
IDK. I forked and patched debugpy locally, but haven't yet managed to get the debugpy extension to use the local, patched copy. In the meantime, if instead of a breakpoint you add a |
It probably is due to our treating all uncaught warnings as errors. If you add a line to our exceptions here like:
Does it work? On at least get to another warning you could ignore? |
I had tried adding to # debugpy uses deprecated matplotlib API
ignore:The interactive_bk attribute was deprecated.*:MatplotlibDeprecationWarning to conftest does change things:
not sure if that's progress or not 😕 |
I would naively expect this to be problematic because
Or similar. |
ah, of course. in the end I had to capture another similar warning too: # debugpy uses deprecated matplotlib API
ignore:The (non_)?interactive_bk attribute was deprecated.*: now the debugger works correctly. |
@cbrnr I just pushed the fix to this branch. Debugging should hopefully work correctly for you now. |
I've been hitting this issue on VSCode for a while, ignoring the error in the conftest.py is my go-to solution. I think it's present in the conftest.py of MNE-LSL for instance. |
Thanks everyone for your help, I am really happy that I can debug tests again! I've included the warning as suggested and expanded the examples prose a bit, so this should be ready. |
mne/io/base.py
Outdated
for ch_type, ch_scale in scale.items(): | ||
if ch_type not in self.get_channel_types(): |
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 structure is error-prone for interactive computing. If someone had a Raw that contained EEG but not MEG, and for some reason did this:
raw.rescale({eeg=1e-6, mag=1e-15})
then the EEG channels would get modified in place, and then the call would error when it got to the mag entry. Thinking that it didn't work, the user might then do
raw.rescale({eeg=1e-6})
with the end result that the rescaling was done twice to the EEG channels, probably without the user realizing it.
Please refactor so that the ValueError
gets raised before any channels get rescaled in-place.
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.
Good catch, I'll change this tomorrow!
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.
Done!
Co-authored-by: Daniel McCloy <[email protected]>
Co-authored-by: Daniel McCloy <[email protected]>
Co-authored-by: Daniel McCloy <[email protected]>
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.
LGTM. My only hesitation is the param name scale
, which is basically identical to what elsewhere we (I think?) consistently call scalings
. To me scale
is not obviously clearer (here or elsewhere) so its only advantage (I think?) is fewer characters. What do others think?
I do not really have a preference, but |
yeah that occurred to me, but the converse is also true (singular param name when passing a dict with multiple scaling values) |
I think |
I'll change it to |
Fixes #12111.