question about epochs.next()

I was puzzled today why this works...

for ix, _ in enumerate(epochs):
    new_epoch = epochs[ix].crop(tmin, tmax, copy=True)

... but this does not:

for epoch in epochs:
    new_epoch = epoch.crop(..., copy=True)

AttributeError: 'numpy.ndarray' object has no attribute 'crop'

According to the docs, Epochs.next() is supposed to return an instance of
the epochs object, but it doesn't: looking at the code, it actually returns
something like self._data[self._current]. I would have expected it to
return something like self.__get_item__(self._current). So are the docs
wrong, or is the definition of Epochs.next() implemented wrong?

Daniel McCloy
http://dan.mccloy.info/
Postdoctoral Research Associate
Institute for Learning and Brain Sciences
University of Washington
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.nmr.mgh.harvard.edu/pipermail/mne_analysis/attachments/20160405/5deac3a3/attachment.html

I've used iteration vs. indexing in different points in my codebase since
sometimes it's more useful to return arrays. But I agree, looking at the
docs it seems that `next` should return an instance of Epochs.

sometimes it's more useful to return arrays.

Sure, but that's why there is a get_data method, right? IMO the docstring
reflects how I expected it to work before even reading the docstring, so my
vote would be to make .next() actually do that, rather than changing the
docstring to reflect what it does currently. Issue created:

Hi Dan,

Since you are iterating over single epochs, it might make more sense to use
the iterator which returns an evoked object. You can do something like:

for ev in epochs.iter_evoked()
    ev.crop(tmin, tmax)

Does this help? Fix to the docs is more than welcome.

Best regards,
Mainak

thanks Mainak, but my use case is a little strange, and I don't think
iter_evoked will help. I need potentially different crop windows for each
event type (same length, but different start/end points), but I need to
keep the individual epochs (not averages) because they're getting fed into
a classifier. I'm happy to do a PR to change the docs if the consensus is
that it is indeed the docs that should change, not the implementation of
next().

Sorry if I wasn't clear but iter_evoked() gives you a single epoch -- not
an average. It has nave=1.

Mainak

I see. Sounds like that would work, I'll give it a try. thanks.

FWIW, from the POV of a new mne-python user, the examples quite prominently
use "evoked" to mean "average of epochs" (e.g.,
http://martinos.org/mne/dev/auto_tutorials/plot_introduction.html?highlight=evoked).
I probably missed the Epochs.iter_evoked method() on the basis of its name
(because I didn't want averages, and it wasn't immediately obvious that
"nave=1" meant "n_epochs_to_average=1", i.e., no averaging).

So now I'm doubly-puzzled: why does Epochs.next() not return a single
epoch, and why does Epochs.iter_evoked() not return an average of epochs?
I understand the need to preserve some backwards-compatibility, but the
naming conventions here seem very ad-hoc to me and worth changing prior to
a 1.0 release. Until then, I guess I'll just change the docstrings to
match what these methods actually do.

I see. Sounds like that would work, I'll give it a try. thanks.

FWIW, from the POV of a new mne-python user, the examples quite
prominently use "evoked" to mean "average of epochs" (e.g.,
http://martinos.org/mne/dev/auto_tutorials/plot_introduction.html?highlight=evoked).
I probably missed the Epochs.iter_evoked method() on the basis of its name
(because I didn't want averages, and it wasn't immediately obvious that
"nave=1" meant "n_epochs_to_average=1", i.e., no averaging).

well point taken. The rationale for this comes from the realtime code where
epochs arrive as a stream and we want to add them with "+" to compute an
online average. This '+' operator is only offered by the Evoked class.

if the iter_* function returns Epochs with a single epoch then you need to
call average to get an Evoked. In this case you need to make 2 copies of
the measurement info to avoid weird bugs due to inplace changes. It was
also my performance driven decision to have iter return the data and not
Epochs as it requires no new copy of the measurement info.

What this discussion tells me is that the iterator on the data should be
more explicit eg.

epochs.iter_data()

let's continue this discussion at :

Alex

So now I'm doubly-puzzled: why does Epochs.next() not return a single
epoch, and why does Epochs.iter_evoked() not return an average of epochs?
I understand the need to preserve some backwards-compatibility, but the
naming conventions here seem very ad-hoc to me and worth changing prior to
a 1.0 release. Until then, I guess I'll just change the docstrings to
match what these methods actually do.

Sorry if I wasn't clear but iter_evoked() gives you a single epoch -- not
an average. It has nave=1.

Mainak

thanks Mainak, but my use case is a little strange, and I don't think
iter_evoked will help. I need potentially different crop windows for each
event type (same length, but different start/end points), but I need to
keep the individual epochs (not averages) because they're getting fed into
a classifier. I'm happy to do a PR to change the docs if the consensus is
that it is indeed the docs that should change, not the implementation of
next().

Hi Dan,

Since you are iterating over single epochs, it might make more sense to
use the iterator which returns an evoked object. You can do something like:

for ev in epochs.iter_evoked()
    ev.crop(tmin, tmax)

Does this help? Fix to the docs is more than welcome.

Best regards,
Mainak

sometimes it's more useful to return arrays.

Sure, but that's why there is a get_data method, right? IMO the
docstring reflects how I expected it to work before even reading the
docstring, so my vote would be to make .next() actually do that, rather
than changing the docstring to reflect what it does currently. Issue
created: Epochs.next() docs don't match behavior · Issue #3099 · mne-tools/mne-python · GitHub

I was puzzled today why this works...

for ix, _ in enumerate(epochs):
    new_epoch = epochs[ix].crop(tmin, tmax, copy=True)

... but this does not:

for epoch in epochs:
    new_epoch = epoch.crop(..., copy=True)

AttributeError: 'numpy.ndarray' object has no attribute 'crop'

According to the docs, Epochs.next() is supposed to return an
instance of the epochs object, but it doesn't: looking at the code, it
actually returns something like self._data[self._current]. I would have
expected it to return something like self.__get_item__(self._current). So
are the docs wrong, or is the definition of Epochs.next() implemented wrong?

Daniel McCloy
http://dan.mccloy.info/
Postdoctoral Research Associate
Institute for Learning and Brain Sciences
University of Washington

_______________________________________________
Mne_analysis mailing list
Mne_analysis at nmr.mgh.harvard.edu
Mne_analysis Info Page

The information in this e-mail is intended only for the person to
whom it is
addressed. If you believe this e-mail was sent to you in error and
the e-mail
contains patient information, please contact the Partners Compliance
HelpLine at
MyComplianceReport.com: Compliance and Ethics Reporting . If the e-mail was sent to
you in error
but does not contain patient information, please contact the sender
and properly
dispose of the e-mail.

--
_____________________________________

PhD Candidate in Neuroscience | UC Berkeley <http://hwni.org/&gt;
Editor and Web Director | Berkeley Science Review
<http://sciencereview.berkeley.edu/&gt;
_____________________________________

_______________________________________________
Mne_analysis mailing list
Mne_analysis at nmr.mgh.harvard.edu
Mne_analysis Info Page

The information in this e-mail is intended only for the person to
whom it is
addressed. If you believe this e-mail was sent to you in error and
the e-mail
contains patient information, please contact the Partners Compliance
HelpLine at
MyComplianceReport.com: Compliance and Ethics Reporting . If the e-mail was sent to
you in error
but does not contain patient information, please contact the sender
and properly
dispose of the e-mail.

_______________________________________________
Mne_analysis mailing list
Mne_analysis at nmr.mgh.harvard.edu
Mne_analysis Info Page

The information in this e-mail is intended only for the person to whom
it is
addressed. If you believe this e-mail was sent to you in error and the
e-mail
contains patient information, please contact the Partners Compliance
HelpLine at
MyComplianceReport.com: Compliance and Ethics Reporting . If the e-mail was sent to
you in error
but does not contain patient information, please contact the sender
and properly
dispose of the e-mail.

_______________________________________________
Mne_analysis mailing list
Mne_analysis at nmr.mgh.harvard.edu
Mne_analysis Info Page

The information in this e-mail is intended only for the person to whom
it is
addressed. If you believe this e-mail was sent to you in error and the
e-mail
contains patient information, please contact the Partners Compliance
HelpLine at
MyComplianceReport.com: Compliance and Ethics Reporting . If the e-mail was sent to you
in error
but does not contain patient information, please contact the sender and
properly
dispose of the e-mail.

_______________________________________________
Mne_analysis mailing list
Mne_analysis at nmr.mgh.harvard.edu
Mne_analysis Info Page

The information in this e-mail is intended only for the person to whom
it is
addressed. If you believe this e-mail was sent to you in error and the
e-mail
contains patient information, please contact the Partners Compliance
HelpLine at
MyComplianceReport.com: Compliance and Ethics Reporting . If the e-mail was sent to you
in error
but does not contain patient information, please contact the sender and
properly
dispose of the e-mail.

_______________________________________________
Mne_analysis mailing list
Mne_analysis at nmr.mgh.harvard.edu
Mne_analysis Info Page

The information in this e-mail is intended only for the person to whom it
is
addressed. If you believe this e-mail was sent to you in error and the
e-mail
contains patient information, please contact the Partners Compliance
HelpLine at
MyComplianceReport.com: Compliance and Ethics Reporting . If the e-mail was sent to you
in error
but does not contain patient information, please contact the sender and
properly
dispose of the e-mail.

_______________________________________________
Mne_analysis mailing list
Mne_analysis at nmr.mgh.harvard.edu
Mne_analysis Info Page

The information in this e-mail is intended only for the person to whom it
is
addressed. If you believe this e-mail was sent to you in error and the
e-mail
contains patient information, please contact the Partners Compliance
HelpLine at
MyComplianceReport.com: Compliance and Ethics Reporting . If the e-mail was sent to you in
error
but does not contain patient information, please contact the sender and
properly
dispose of the e-mail.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.nmr.mgh.harvard.edu/pipermail/mne_analysis/attachments/20160406/ef66d9cd/attachment.html