[WIP] adding receptive field module

Just when you thought it was safe, it returns! Unnecessarily complicated API changes make a comeback in "Gitastrophe 2: Attack of the clone(d repository)"
This is a new branch off of master and a greatly simplified version of the long discussion in #2796. The basic idea is that we decided tackling the general encoding model problem is probably too much to bite off in one PR, especially when the sklearn API might change somewhat. This is a PR to add a receptive field module. It includes some (unfinished) tests, a new class, a few new functions, and an example.
LMK
@agramfort @Eric89GXL @kingjr @jona-sassenhagen

CIs are not happy

Hey all - let me know if comments are done and I can make changes. Travis isn't happy because I haven't finished uncovering bugs and writing tests. If you guys think the API (in general) is OK then I will move forward on the smaller changes and specific suggestions...

I haven't had a chance to really look into the API yet. I want to see if it's possible to make use of the more efficient routines. I wonder if it's worth making the API more restrictive to start (e.g., force just a start and stop time, instead of allowing arbitrary indices) so we can make it efficient.

If we're using sklearn under the hood, then I feel like forcing people to
use all possible lags between a tmin and tmax will make it slower (e.g. if
my sampling frequency is 10x higher, then I'll have 10x more features in
the model now). If there's a more clever way of finding the coefficients
solution, then maybe that'd work fine.
Though we are now getting back into the weeds of lots of conversations that
we had back in the franken-PR of the general encoding models stuff...
--
On Fri, Nov 4, 2016 at 6:13 PM Eric Larson<EMAIL_ADDRESS>wrote:
I haven't had a chance to really look into the API yet. I want to see if
it's possible to make use of the more efficient routines. I wonder if it's
worth making the API more restrictive to start (e.g., force just a start
and stop time, instead of allowing arbitrary indices) so we can make it
efficient.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/mne-tools/mne-python/pull/3728#issuecomment-258581534,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABwSHRq28oYVY6qRFUwQs8qBSUk07GFkks5q69hAgaJpZM4KokeM
.

would it be possible to compare this PR with this toolbox:
https://sourceforge.net/projects/aespa/files/latest/download
in terms of result and running time?

Does anybody here have experience with using this toolbox in matlab? I've already put way too much time on this PR and it'll be a while before I can do a full comparison between python / matlab code etc. If folks want to have a conversation about drawing inspiration from the mTRF toolbox, I'm down to do that.

@rkmaddox does your code do the same things as [AESPA from Lalor's lab] (https://sourceforge.net/projects/aespa/files/latest/download)?

It intends to. For the basic TRF calculation it should return the same result (when I first coded it I confirmed that it did within numerical precision, but I have not confirmed this for a couple years). The Lalor lab code does more things, I believe. My code will run significantly faster and use far less memory for the things they both do.

I'm worried this is undergoing PR rot. We have rehashed this conversation many times but it seems like there is still much disagreement both about the API and what would happen under the hood. To me these are dissociable problems (e.g. we can make a receptive field API now and then support multiple algorithms UTH via PRs in the future).
Following the old adage "premature optimization is the root of all evil", I think we should decide soon to either:

have a conversation to solidify the API and get this merged, with the goal of optimizing the algorithm etc later (assuming the inputs would be similar regardless of the backend algo)
Do 1, and then compare algorithms to do this under the hood
cut losses on this PR entirely and table this for some moment in the future

What do people think?

sorry I don't have the bandwidth to look
if you want to make this publicly available quickly I would put this in
sandbox
and it's one of the first thing we'll tackle in march during the sprint.
sounds ok to you?

To me it's not super high-priority to have out there ASAP. I was going to incorporate the MNE code into a tutorial-style paper I'm writing but it's way past the time where that would have been possible anyway. I'm mostly trying to figure out whether I should treat this PR as a sunk cost and forget about it. I guess we can hold off until March tho

sounds like a good option to me.
On 12 December 2016 at 18:02, Chris Holdgraf<EMAIL_ADDRESS>wrote:

To me it's not super high-priority to have out there ASAP. I was going to
incorporate the MNE code into a tutorial-style paper I'm writing but it's
way past the time where that would have been possible anyway. I'm mostly
trying to figure out whether I should treat this PR as a sunk cost and
forget about it. I guess we can hold off until March tho
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mne-tools/mne-python/pull/3728#issuecomment-266581647,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEp7DIEGLKHHHbAncCVdgHRrCwZykvYWks5rHdKVgaJpZM4KokeM
.

@kingjr wait until march or just forget about this PR entirely?

Make this as one of the deliverables of the sprint, it'll be a good time for Alex, Eric and I looking at it.
(I'm actually playing with your/jona's code ATM, but I had to break it down to fit my needs, I'll keep you posted as it stabilizes)

sounds good
On Mon, Dec 12, 2016 at 3:14 PM Jean-Rémi KING<EMAIL_ADDRESS>wrote:

Make this as one of the deliverables of the sprint, it'll be a good time
for Alex, Eric and I looking at it.
(I'm actually playing with your/jona's code ATM, but I had to break it
down to fit my needs, I'll keep you posted as it stabilizes)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/mne-tools/mne-python/pull/3728#issuecomment-266584341,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABwSHZQHRbpIKg41s8GH-K-eq5YWeWhHks5rHdVzgaJpZM4KokeM
.

Yeah this has been in my to-do list for a long time. Sorry it has taken so long :(

This looks 1) fairly simple (in a good way) and 2) has a pretty clean API that is 3) sklearn-consistent AFAICT.
I agree with the "premature optimization" mantra in general, but for some receptive-field use cases they are necessary for the code to even run. Fortunately I think we can probably work efficiency in later as a special case for this one class, or as a different class if we absolutely have to (which would be an annoying acceptable outcome to me).
@kingjr you are planning to use this a bit in the coming month or so, yes? If so my vote is to leave this PR open pending this usability feedback, and aim to merge before the sprint if @kingjr is satisfied, otherwise get to it at the sprint.
@choldgraf you're going to the sprint, yes? I certainly owe you some :beers: or :plate_with_cutlery: for dragging my feet on this one...
In the meantime if you are bored and want to update, I'll piggyback on some of @kingjr's feedback.

Okay I made some comments. @choldgraf if you want I can make a PR into your branch with some of the changes at some point (probably Jan)

I had a chat with @rkmaddox today and he likes the idea of a sklearn-like API even if his (potentially very) specific use case prevents him from using it. I think at the sprint I can work on implementing (a) fast cross-correlation method(s) and other speedups that could be used under the hood by this class and by him.

Cool - I'll iterate on comments tomorrow and see how people feel about the PR then. I agree that we could get the API somewhat nailed down and worry about the guts later on.

Addressing the comments in here - will also add some more tests and get them passing soon.

Ah right - forgot to mention. For this one I created an epoched version of an audio file, which I was using to extract spectral features. Is there a place I could put that file in the repo? Alternatively, is there another audio file already used in another example? I could just create arbitrary synthetic data, but it seemed more compelling to show an actual audio file :P

I'm  +1 for adding real audio on S3, especially if it matches MEG/ECoG
data. Else @Eric89GXL and I have Nima's ECoG data with audio. I think he's
ok making it public, but we'd need to clarify/ensure its licence.
On 21 December 2016 at 23:15, Chris Holdgraf<EMAIL_ADDRESS>wrote:

Ah right - forgot to mention. For this one I created an epoched version of
an audio file, which I was using to extract spectral features. Is there a
place I could put that file in the repo? Alternatively, is there another
audio file already used in another example? I could just create arbitrary
synthetic data, but it seemed more compelling to show an actual audio file
:P
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mne-tools/mne-python/pull/3728#issuecomment-268656627,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEp7DJAoucsprMEVrAMJXASPTgVjXuf4ks5rKaTngaJpZM4KokeM
.

mne-misc-data would work

so just use fetch_data and download it directly from the github repo? That'll work in tests etc?

Don't use it for testing, just for examples. See how it's done already,
it's in datasets. For testing just synthesize something minimal.

sounds good

How do I find the proper hash for the new misc push? I tried checking the release page here but the git hash wasn't the correct one...

I usually do python -c "import mne; mne.datasets.misc.data_path(force_update=True), when it fails it gives you the new hash :)

lol see sometimes the right strategy is to break things and figure out what happened after-the-fact

TDD :)

I always think of this song when somebody says TDD. They should really make a parody of this...

OK let's see if tests pass. I added the updated misc path and used some fake data for the tests. re: your point about using swapaxes in the example, I agree it's clunky. The reason is basically because the delay_time_series function appends delays such that the first dimension is shape (n_delays), while the ReceptiveField model expects the first dimension to be either features or epochs. These both seem like the right solution for their respective inputs, but I agree that it's pretty clunky to have them somewhat clash with one another. WDYT?

The reason is basically because the delay_time_series function appends delays such that the first dimension is shape (n_delays)

You could make this function delay differently or make it an option. If it's designed primarily for use with ReceptiveField it would be nice if it gave the correct outputs for that class.

Yeah, I agree w/ you. I don't think it'd be a big deal if the person was not using epochs as an input. In that case you could just use vstack on the outputs of the delayer. The challenge is that if there are epochs, there's the extra dimension in there.

Actually, instead of making delay_time_series public, can you leave it private and use np.convolve in your example instead?

could there be an "axis" flag that would cause the new dimension to exist wherever was asked?

could make it private - though I find it personally a useful function but maybe that's just me ;)
as for using convolve, my opinion is that it's a more efficient and "pure" solution but very few people understand it, so from the point of a tutorial it'd be better to make it explicit. Also would it be possible to use convolve but have the output skip samples? The reason I wrote delay_time_series the way I did was so that you could skip contiguous samples in the delays (e.g. to save memory or n_features in your model).

as for using convolve, my opinion is that it's a more efficient and "pure" solution but very few people understand it, so from the point of a tutorial it'd be better to make it explicit.

Hmm... to me the entire concept behind an encoding model is to model your output is the result of a convolution with a response function. So in my mind it's actually a cleaner conceptual representation of what's going on. I'm not sure what other concept people would rely on for this...?

Also would it be possible to use convolve but have the output skip samples?

No, but you could np.convolve with a decimated version of the response like np.convolve(h, x[::10]) or whatever. Or use a sufficiently smooth kernel, and verify that what you get out is a decimated version of it.
Users ideally shouldn't have to deal with delay_time_samples. The more numpy-like shape manipulations we put in the data, the more difficult it will be for them to get what's going on and use it in their own data. The function has issues about compatibility with how it actually interfaces with ReceptiveField. So it seems better to keep it private if we can.

re: the first point, I agree. The challenge I ran into was basically something like: "I have a signal sampled at 1000Hz, but I only want to include time lags of .05, .1, .15, .2 seconds as features to the model". So rather than doing something like toeplitz I just went with a function that'd let you do arbitrary time delays. Seems like a lot of people disagree with this though :-/
Re: the entire concept, I agree with you. Just that every time I teach people and use the word "convolution" I see people's eyes glaze over. When I say "you create a bunch of time lags of your signal and stack them on top of each other, then multiply it by weights, one for each time lag" they seem to get it. Could just be my experience tho.

Current coverage is 85.44% (diff: 93.38%)

Merging #3728 into master will decrease coverage by 0.14%

@@             master      #3728   diff @@
==========================================
  Files           347        349     +2
  Lines         61881      62015   +134
  Methods           0          0
  Messages          0          0
  Branches       9503       9515    +12
==========================================
+ Hits          52962      52986    +24
- Misses         6254       6355   +101
- Partials       2665       2674     +9

Powered by Codecov. Last update ab42e6a...0e05fa4

latest push adds a newaxis parameter, which is demoed in the tutorial now. This removes the necessity to do swapaxes etc. Maybe that works? I do see your point about convolution though. WDYT?
BTW here's the latest version of the tutorial. There is some weird output in there because I had to use force_update to get the tutorial to build with the audio data (but maybe that's not necessary anymore?)
https://3393-1301584-gh.circle-artifacts.com/0/home/ubuntu/mne-python/doc/_build/html/auto_tutorials/plot_receptive_field.html

would it be possible to have an example that reuses some data from the
toolbox of Ed Lalor?
that would make our results more comparable and we could benchmark the
speed of our
implementation against their matlab toolbox.
I am sure Ed would be fine if we reuse his data provided we add a citation
to his paper and link
to his toolbox.

That's a great idea. Know of a URL where that data lives?
On Sun, Dec 25, 2016, 5:46 AM Alexandre Gramfort<EMAIL_ADDRESS>wrote:

would it be possible to have an example that reuses some data from the
toolbox of Ed Lalor?
that would make our results more comparable and we could benchmark the
speed of our
implementation against their matlab toolbox.
I am sure Ed would be fine if we reuse his data provided we add a citation
to his paper and link
to his toolbox.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mne-tools/mne-python/pull/3728#issuecomment-269119246,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABwSHU0tpkBYxXExtPn91XRYSVHV2ipVks5rLleCgaJpZM4KokeM
.

https://sourceforge.net/projects/aespa/?source=navbar
On Sun, Dec 25, 2016 at 5:38 PM +0100, "Chris Holdgraf"<EMAIL_ADDRESS>wrote:
That's a great idea. Know of a URL where that data lives?
On Sun, Dec 25, 2016, 5:46 AM Alexandre Gramfort<EMAIL_ADDRESS>wrote:

would it be possible to have an example that reuses some data from the

toolbox of Ed Lalor?

that would make our results more comparable and we could benchmark the

speed of our

implementation against their matlab toolbox.

I am sure Ed would be fine if we reuse his data provided we add a citation

to his paper and link

to his toolbox.

—

You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub

https://github.com/mne-tools/mne-python/pull/3728#issuecomment-269119246,

or mute the thread

https://github.com/notifications/unsubscribe-auth/ABwSHU0tpkBYxXExtPn91XRYSVHV2ipVks5rLleCgaJpZM4KokeM

.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Paper http://journal-cdn.frontiersin.org/article/219245/files/pubmed-zip/versions/1/pdf
On Sun, Dec 25, 2016 at 5:52 PM +0100, "Alexandre Gramfort"<EMAIL_ADDRESS>wrote:
https://sourceforge.net/projects/aespa/?source=navbar
On Sun, Dec 25, 2016 at 5:38 PM +0100, "Chris Holdgraf"<EMAIL_ADDRESS>wrote:
That's a great idea. Know of a URL where that data lives?
On Sun, Dec 25, 2016, 5:46 AM Alexandre Gramfort<EMAIL_ADDRESS>wrote:

would it be possible to have an example that reuses some data from the

toolbox of Ed Lalor?

that would make our results more comparable and we could benchmark the

speed of our

implementation against their matlab toolbox.

I am sure Ed would be fine if we reuse his data provided we add a citation

to his paper and link

to his toolbox.

—

You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub

https://github.com/mne-tools/mne-python/pull/3728#issuecomment-269119246,

or mute the thread

https://github.com/notifications/unsubscribe-auth/ABwSHU0tpkBYxXExtPn91XRYSVHV2ipVks5rLleCgaJpZM4KokeM

.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

I threw together a quick example that creates the envelope TRF from the paper. AKA creates this figure:

Would that work? I pulled the envelope / EEG data from the repository, but AFAICT it's only downloadable as a zip file, so I couldn't just pull the data in the script w/o downloading the zip file. So should we plan to host some of that data on the MNE repo? Or is there another place to download it? LMK.

Cool
I would ask Ed if we can host a copy of his data
How fast is your implementation vs their matlab toolbox ?
On Mon, Dec 26, 2016 at 3:24 AM +0100, "Chris Holdgraf"<EMAIL_ADDRESS>wrote:
I threw together a quick example that creates the envelope TRF from the paper. AKA creates this figure:
Would that work? I pulled the envelope / EEG data from the repository, but AFAICT it's only downloadable as a zip file, so I couldn't just pull the data in the script w/o downloading the zip file. So should we plan to host some of that data on the MNE repo? Or is there another place to download it? LMK.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

not sure on speed, I've never used their toolbox and don't have a working copy of matlab on my laptop. Is that something you feel is important to have as a part of this PR? To me this PR is more about API etc and less about performance relative to other packages (w future PRs focusing on performance if needed)

Also do you have his email? I can send him a message if so. I've spoken to him in person but haven't corresponded via email.

(latest push has the example added, but it won't work until we figure out where to put the data)

Can we just have our downloader fetch the zip from sourceforge as a new
dataset (possibly with license confirmation like for bst)?

we could though it's large-ish (like 60mb or so). I think it'd be best if
we could fetch just the data that we want from there, since that's much
smaller.
On Mon, Dec 26, 2016 at 3:25 PM Eric Larson<EMAIL_ADDRESS>wrote:

Can we just have our downloader fetch the zip from sourceforge as a new
dataset (possibly with license confirmation like for bst)?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mne-tools/mne-python/pull/3728#issuecomment-269242793,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABwSHeJoeblFbMWUTIzjQWi68tfRgtgjks5rMDDIgaJpZM4KokeM
.

At 60MB it would probably be our smallest mne.datasets member, actually.
What does it contain other than the data? Model outputs, code, ...?

Ah fair enough - In that case, I'll go the opposite direction and say it seems a bit overkill to have a whole new section in the mne.datasets module for this. It's just a couple of data files from different tasks, not a full-fledged suite of data. Would that be on par with the data that's already there?

I think it's better to use (and make easy access to) an existing public
dataset where possible. But perhaps we should hear from others to see what
they think.

(The overhead for maintaining a new dataset is very small, and if the link
ever breaks we can easily recreate it fairly easily.)

Cool - do you just write some functions under the hood that do, e.g., the
unzipping etc?
On Tue, Dec 27, 2016 at 3:53 PM Eric Larson<EMAIL_ADDRESS>wrote:

(The overhead for maintaining a new dataset is very small, and if the link
ever breaks we can easily recreate it fairly easily.)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mne-tools/mne-python/pull/3728#issuecomment-269387903,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABwSHV8hWexa7LdDY5d8A_CSAa-EDkoyks5rMYjUgaJpZM4KokeM
.

OK I'll try to find it.
On Tue, Dec 27, 2016, 4:03 PM Alexandre Gramfort<EMAIL_ADDRESS>wrote:

Ed's email should be easy to find. We should ask him before making a new
dataset. I doubt he will object.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mne-tools/mne-python/pull/3728#issuecomment-269389033,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABwSHSs5SDDYpfFajvs4KcGviGhHiiFqks5rMYstgaJpZM4KokeM
.

I think we already have unzipping and such built in. Hopefully just need to
set URL, hash, paths, etc. properly

ok cool, I'll try to get that working and will send an email. I'm also gonna try to spend some time getting my ECoG data released from the paper I just put out. The challenge is that since it's patient data, I need to re-create the audio from the sentence WAV files and insert them at the proper times, since I can't use the actual recorded audio. Not sure how long it'll take to figure that out / if it will work properly :P

I'm working on adding an mtrf module to datasets, but having a hard time getting the data_path function to work. It's giving me this error:
/Users/choldgraf/Dropbox/github/forks/python/mne-python/mne/utils.pyc in _get_http(url, temp_file_name, initial_size, file_size, verbose_bool)
   1818     total_size += initial_size
   1819     if total_size != file_size:
-> 1820         raise RuntimeError('URL could not be parsed properly')
   1821     mode = 'ab' if initial_size > 0 else 'wb'
   1822     progress = ProgressBar(total_size, initial_value=initial_size,

RuntimeError: URL could not be parsed properly

Looking at the code it seems total_size becomes slightly larger than file_size and then throws the error. Any thoughts on how to debug this?
I'll push the latest version of this code so folks can take a look at it.

This could be some SourceForge URL problem. Do you have a partially downloaded file that you can delete and try again?
If it ends up being a SourceForge problem, then we can (with Ed's permission) host a copy on FigShare or (last resort) our AWS server.

... if the SourceForge ZIP that you download does not have a consistent MD5sum, which is also possible, then we should also host the ZIP elsewhere like FigShare.

Ah ok - clearing out all temp files etc got it working. So now it's downloading fine and returning a path string, but there's no data at that path. I can see a tmp file being downloaded, but then it looks like that file gets deleted and nothing comes to replace it. The data is in.zip format...is that a problem? Or is there anything special I should be doing to make it unzip / place itself somewhere?
Here's a link to the mtrf module:
https://github.com/mne-tools/mne-python/pull/3728/files#diff-ead8c27211018f41d1d84b18f1a8b492

(also it seems that the data is being initially downloaded to the examples folder because there's no global variable for the path to ~/mne_data. Not sure where that variable gets set...I tried making the proper changes to utils.py etc.

Apparently this is our first .zip file, all others are gz or bz2. I'll make a PR into your branch soon

got it working by using the zipfile module actually...next push will include that and you can tell me what I messed up :)

ok latest push adds a check for zip and unzips it properly. Modified the example accordingly so it should look correct now. I still couldn't figure out how to get it to unzip to mne_data instead of the examples folder tho. Let's see if the example runs on circle...

You probably need to rename the expected folder to whatever it actually is
in the zip, mTRf_1.5 or so. It's okay that it deviates from the MNE-
standard since it's not packaged by us anyway.

mmk here's the example:
https://3402-1301584-gh.circle-artifacts.com/0/home/ubuntu/mne-python/doc/_build/html/auto_examples/decoding/plot_receptive_field.html
LMKWYT!

(I know the paper uses jet in the figure but I couldn't bring myself to do it)

On mobile so will look deeper later. In the meantime, use RdBu_r for
divergent colormap (positive and negative values with meaningful zero), fix
axis labels (tight layout call?), and your reference and at the top is
broken. If possible please add links to the corresponding paper figures
where you recreate them. But looks like the right direction to me!

In that circle link, the mean model coefficients y label is invisible and x
is cut off
Also modify circle.yml to be consistent with other datasets (it will remove
the download trace from the example) and also _download_all_example_data or
whatever it is called in datasets utils if you haven't already. And I guess
we can roll back the misc dataset changes?

sounds good - how can I get it to download to mne_data instead of the examples folder?

and yeah that's a good point about misc_data since there's a spectrogram in that dataset as well. Lemme see if I can re-do the tutorial using that spectrogram instead :)

hmmm, just realized they do have different shapes. the data in misc is a collection of epochs, whereas the spectrogram in the mtrf data is just a continuous 16 channel spectrogram...

I would say get rid of the old epochs example for now, we can add a better
one with real data later. Perhaps the mtrf example is a good enough start.
Do you have an MNE_DATA config entry? It is probably outdated. Either that
or MNE_DATASETS_MTRF entry is outdated. examples used to be the default,
now it should be mne_data.

If you really want to keep the epochs one, a (crop and) reshape of the
continuous spectrogram would work

I can try it with the crop etc of epochs, tho the spectrogram only being 16 channels kinda sucks. However it'll still be illustrative of the functionality and we can update it when there's a more rich dataset for this kind of thing available

Updated version of the tutorial is here:
https://3408-1301584-gh.circle-artifacts.com/0/home/ubuntu/mne-python/doc/_build/html/auto_tutorials/plot_receptive_field.html
The estimated STRF is a bit blurrier, I think because of smaller number of frequencies and sampling rate of the spectrogram. LMK.

I updated the tutorial to include an extra section that visualizes the effects of multiple ridge parameters. I figure this distinguishes it a bit more from the example and is also a bit more "tutorial"-esque. Link below. Other than that all the tests are passing so LMK.
https://3412-1301584-gh.circle-artifacts.com/0/home/ubuntu/mne-python/doc/_build/html/auto_tutorials/plot_receptive_field.html

latest push should have these resolved...let's see if tests pass. LMKWYT if so!

latest tutorial here:
https://3414-1301584-gh.circle-artifacts.com/0/home/ubuntu/mne-python/doc/_build/html/auto_tutorials/plot_receptive_field.html#id4

I will look closer in a bit. In the meantime, now that we are using samples, we could only allow slices for lags. It gives clean start/stop/step, makes clear what sorts of aliasing could be going on, and I can't think of a good reason to allow non-uniform steps, at least at first. So better to make the API more restrictive in that regard. WDYT?

hmmm, so instead of a single lags parameter, have a start, stop, and step parameter? I think I prefer having a single lags parameter, but I think the parameters you propose would be more MNE consistent. I guess the question is whether it's cleaner to do:
lags = range(-10, 10, 2)
rf = ReceptiveField(lags)

or
rf = ReceptiveField(-10, 10, step=2)

yeah? If you feel strongly about it then I can go w/ number 2. LMK

As we've discussed before, I think tmin, tmax, decim are much more MNE-like. If at all, an explicit lags param should be optional.

No I mean:
ReceptiveField(lags=slice(-10, 10, 2))

I can live with tmin/tmax/decim, I guess it is more consistent. I'm 50/50 between that and a simple slice. Maybe we should get opinions from others before you change it @choldgraf.

I think I'd prefer start stop and step to using a slice. IMO it's better to call it start/stop rather than tmin/tmax since in other parts of the MNE API tmin/tmax are in seconds, no?

I think consistency across MNE > perfect single function pattern.
Also, we sadly have an inconsistency within MNE in general - some functions take floats for tmin/tmax and interpret it as seconds, others take integers and interpret them as msec.

hrmmm, well then perhaps tmin and tmax are fine if we don't care so much about consistency there. We can force them to be ints and make it clear that they're in samples in the documentation.

but I'll hold off on making any changes until we agree on something. I agree that it's unlikely someone will want non-uniformly-spaced lags.

I like slice, but tmin, tmax and decim are ok too. But tmin and tmax should be floats (in seconds) - it would be confusing otherwise (many high-level mne functions use this pattern). decim on the other hand is usually an int (so maybe having an optional lags param might be helpful).

I think the only places we still use ms are in plotting functions and I
wish we didn't.
We definitely don't want to call it tmin and mean samples, we'd need to
call it start or use slice if using samples. So tmin/tmax/decim (float sec,
float sec, int) with required float sfreq might be the best way to go like
Jona suggested.

I'm still iffy on using a decim parameter instead of a step parameter. To me calling it decim would imply that we're decimating the data, which isn't true, we're only decimating in terms of the number of new features we create, but not actually shrinking the amount of data.
In the last iteration of this PR, we ended up having an object that accepted either a tmin/tmax parameter, or a lags parameter. But IIRC it was decided this was too complex of an API, no?

To me calling it decim would imply that we're decimating the data, which
isn't true, we're only decimating in terms of the number of new features we
create, but not actually shrinking the amount of data.
Your model only ends up trying to use every nth sample to create the
output, right? This might be very similar to decimating the original data.
I'd have to look at the math. I suspect either way you're going to alias
unless data are lowpassed, for example.

Your model only ends up trying to use every nth sample to create the
output, right? This might be very similar to decimating the original data.
I'd have to look at the math. I suspect either way you're going to alias
unless data are lowpassed, for example.

Not in its current implementation. It is actually decimating the features note the samples. AKA given your start/stop/decim API, it'd first create all time lags between start and stop, so now the output would be shape (n_features, n_lags). Then it would decimate the features, so it'd be (n_features, n_lags / decim). The sampling frequency of the data itself would remain the same.

so you're basically just decreasing your resolution in the timelag dimension in order to cut back on the number of features in the model.

So in other words, decim=4 model coefficients are equivalent decim=1 model
coefficients that has been decimated by 4 after the fact? Then I'd say we
shouldn't have decim at all, at least to start.

yeah, so if you have a sampling frequency of 1, and you want time lags from -5 to 5, then decim=1 lags would give you lags of [-5, -4, -3, -2, -1, 0, 1, 2, 3, 4 ,5]. If you used decim=2, it'd give you lags of [-5, -3, -1, 1, 3, 5]. I was having users just explicitly define lags to avoid the confusion w/ decimating in time.

I'm pretty sure that fitting a full model and decimating the result can
lead to aliasing. Consider a two-lag model that responds to Nyquist,
decimating by a factor of two would make it respond to DC, which is not
good (but is probably what you'd if you decimated the data the first place).
Can we get away with no decimation to start? It seems like it's mostly used
cosmetically currently.

I'm pretty sure that fitting a full model and decimating the result can
lead to aliasing. Consider a two-lag model that responds to Nyquist,
decimating by a factor of two would make it respond to DC, which is not
good (but is probably what you'd if you decimated the data the first place).

My usecase is generally a situation where I've got a sampling frequency that is higher resolution  than the lags I care about.
e.g. I have sfreq = 100 and I want lags from -400 to 100ms. But if I just take all possible lags (e.g. decim=1) that means the model will have 50 time lags, which might make the number of the features in the model fit too large (e.g. if I am using 100 input features, I now have 50 * 100 total model features). So the idea of letting users specify custom lags (or giving a decim parameter) is to let them decouple the number of features in the model from the sampling frequency of the data.
Consider the extreme example if you had a signal sampled at 1KHz with 10 features. If you wanted lags from -1s to 0s, then you'd get 1000 * 10 input features to the model which would be too much.

So the idea of letting users specify custom lags (or giving a decim parameter) is to let them decouple the number of features in the model from the sampling frequency of the data.

Hmmm... from what I understand, you can only safely decouple features of interest (think of them as "weighted samples") from the sample rate of your data via decimation if the data are sufficiently low-passed -- otherwise you alias. If the data are low-passed, then you might as well decimate your data before or during the input stage rather than in the model coefficients after the fact. Doing it in a decimate-then-fit order seems cleaner than fit-then-decimate as it will force people to consider aliasing. As a nice side effect, it should also be computationally more efficient.

If you wanted lags from -1s to 0s, then you'd get 1000 * 10 input features to the model which would be too much.

This is really a side point, but why is this too much? You mean conceptually the model fitting will be invalid, or that computationally it's intractable? Conceptually I suspect sometimes this would be too much, and other times it would be appropriate. If you have data with frequency content spanning DC to hundreds of Hz for all 10 channels and you expect up to 1 second system memory, this sounds like a good model. (With regularization I suspect it would work even for low-passed data.) Computationally, perhaps sklearn couldn't handle it, but for Ridge+regularization at least I'm pretty sure there are ways to make this tractable. The number of lags (even thousands), assuming it stays small relative to the input data size (which it really should to be valid) actually has a small impact on the auto/cross-correlation speed for frequency-domain methods, for example.

... in other words, if it makes it a lot easier to use to have decim I think it's fine to include it with suitable warnings, but we might as well decimate the inputs when we get them rather than decimating the model after it's computed.

re: your second point, in my experience I've used decimation for computational purposes, not for conceptual ones. If I'm fitting 300 electrodes w/ 3 models each and many iterations of CV each, then it saves a significant amount of time if I can cut the number of features in half.
re: aliasing I see your point, though to me I feel like it'd be an issue if the "true" receptive field has important temporal structure that has finer detail than the lags you're choosing (e.g. if there's important STRF structure from seconds .0001 to .0002, and you've got lags from .01 to .02). In reality I think most (STRF) models think of the "true" receptive field as some kind of "blob" in feature / lag space (e.g. the blobs in the tutorial example). So by choosing lags that have slightly larger spacing (aka decimating them), you're just reducing the temporal resolution with which those blobs are recovered. Maybe I'm off in my logic here though? I do see how this would be a problem if you expected some kind of periodic structure in your STRF weights, but I don't generally see this kinda structure in the literature. If you think it's easier to talk through this stuff by skyping or something I'm happy to do so.

(tomorrow) :)

I think that we're both in agreement about the pitfalls of decimating your model features, I think the difference is that I was just going to let users make those mistakes for themselves rather than not allowing them to decimate model features. It sounds like your solution also has support of @jona-sassenhagen and as you said, it wouldn't be hard to add a decim parameter in the future. So I why don't I just do start, stop and leave it at that. Is that OK?

That's not quite it -- you want to decimate the model after fitting to all
data, I want to decimate the input data itself.

In my case technically I'd be decimating the model before fitting the data (e.g. fitting with N / 2 parameters instead of N parameters). In my use case that's the whole point - to save time in model fitting without changing the number of samples you feed into the model.

That makes sense. Unfortunately I'm not sure if that approach is better,
worse, or equivalent to decimating the inputs. I think until we sort that
out, I agree we probably should just leave decim out. By that renders the
code useless to you doesn't it?

it does make the code much less useful from a computational efficiency standpoint for me, ya. But I agree that it's not clear what is the "right" way to do it.
My personal preference is to make people be explicit about the parameters they're including in the model (by making them explicitly define time lags), do some straightforward checks for them (e.g. make sure a time lag isn't repeated), and then if they make modeling mistakes it's on them and not MNE.
But. it doesn't seem to me that this is as favored w/ the group, and it's not a point that I feel strongly enough about to keep holding up the PR, as I've written and re-written this code several times now.

My vote is to scrap decim for now and come back to it in a follow-up PR then. It sounds like the consensus is to use tmin/tmax/sfreq to define the bounds.
BTW while testing the decimation stuff (I'm pretty sure the two are not equivalent) I found a little bug. I can pass X.shape[-1] != y.size in fit and get a NumPy boolean mask shape mismatch warning, but really this should raise an error at the MNE end.

Cool - I'll push a commit w/  this API then. Do you want me to use
tmin/tmax and have sfreq default to 1. then? Or use start/stop and force
them to be in samples?
I was thinking of adding in one extra feature that lets you define a
pre-defined time mask for each epoch (have a mask of shape (n_epochs,
times)). Then each item of boolean array would be applied to its respective
epoch before fitting. This way if you have epochs where the inputs are of
differing lengths, you can only include "active" timepoints in the model
(e.g. if you have 2 sentences, one is 4 seconds long, one is 2 seconds
long, you'd need tmax to be 4, but on the shorter sentence there'd by 2
seconds of silence included in the model...this tries to deal with that).
Does that sound useful? It shouldn't be too complicated.
On Fri, Dec 30, 2016 at 3:38 PM Eric Larson<EMAIL_ADDRESS>wrote:

My vote is to scrap decim for now and come back to it in a follow-up PR
then. It sounds like the consensus is to use tmin/tmax/sfreq to define
the bounds.
BTW while testing the decimation stuff (I'm pretty sure the two are not
equivalent) I found a little bug. I can pass X.shape[-1] != y.size in fit
and get a NumPy boolean mask shape mismatch warning, but really this should
raise an error at the MNE end.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mne-tools/mne-python/pull/3728#issuecomment-269825000,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABwSHcP_AqFacQ7oALqzNiaiptjNitIlks5rNXm6gaJpZM4KokeM
.

Do you want me to use tmin/tmax and have sfreq default to 1. then? Or use start/stop and force
them to be in samples?

It's probably best to make all three sfreq, tmin, tmax required. It makes people think a bit more about what they are doing. I don't think we default sfreq=1. anywhere else. We can also add it later if people use it a lot (but I suspect they won't).

I was thinking of adding in one extra feature that lets you define a pre-defined time mask for each epoch

Not in this PR please :) It will require another API discussion, since we already have some similar issues going on with epochs of different lengths, raw annotations, etc.

sounds good, will push something soon

latest tutorial
latest example
LMK

2 quick things:

I notice some periodic-looking structure in the STRFs now. They get exacerbated if I don't decimate the signal before fitting. It only shows up in the tutorial so I wonder if this is some kind of artifact I'm introducing when simulating the signal. LMK if it looks fishy to you.
The output for downloading mtrf is still showing up. I thought I changed the right code (here) but LMK if I need to change that...

I'll have a few superficial comments, but overall both the tutorial and the example look very nice.

cool - I just realized I missed some of @Eric89GXL 's comments anyway so I'll take a look and will push later tonight

You'll need to modify circle.yml to fix the download. See what we do with
other datasets

The API should probably match ReceptiveField

For my other comment, I meant both new public things should be added to python_reference.rst

LMK if that looks OK now. Also rebased.
Thanks for clarifying and hanging in there w/ me

OK I think I addressed @kingjr 's comments...take a look and LMK. I'm pretty sure the failing test is unrelated to this PR (it's a megsim url timeout)

OK I think I addressed @kingjr 's comments...take a look and LMK. I'm pretty sure the failing test is unrelated to this PR (it's a megsim url timeout)

I think the difference with respect to Crosse, M. J., Di Liberto, G. M., Bednar, A. & Lalor, E. C. (2016). should be stated somewhere: here L2 penalty is used by default, while the cited paper uses regularization enforcing smoothness in time - the penalty is of form:

Citing the authors:

Tikhonov regularization (Equation 5) reduces overfitting by
smoothing the TRF estimate in a way that is insensitive to
the amplitude of the signal of interest. However, the quadratic
approach (Equation 6) reduces off-sample error whilst preserving
signal amplitude (Lalor et al., 2006). As a result, this approach
usually leads to an improved estimate of the system’s response (as
indexed by MSE) compared to Tikhonov regularization.

I think the difference with respect to Crosse, M. J., Di Liberto, G. M., Bednar, A. & Lalor, E. C. (2016). should be stated somewhere: here L2 penalty is used by default, while the cited paper uses regularization enforcing smoothness in time - the penalty is of form:

Citing the authors:

Tikhonov regularization (Equation 5) reduces overfitting by
smoothing the TRF estimate in a way that is insensitive to
the amplitude of the signal of interest. However, the quadratic
approach (Equation 6) reduces off-sample error whilst preserving
signal amplitude (Lalor et al., 2006). As a result, this approach
usually leads to an improved estimate of the system’s response (as
indexed by MSE) compared to Tikhonov regularization.

I think the difference with respect to Crosse, M. J., Di Liberto, G. M., Bednar, A. & Lalor, E. C. (2016). should be stated somewhere: here L2 penalty is used by default, while the cited paper uses regularization enforcing smoothness in time - the penalty is of form:
penalty matrix

Yes, we briefly discussed this by email. I think it's an important distinction. My intuition is that this ad-hoc regularization is, in practice, equivalent to smoothing the data: since fitting regression coefficient is basically finding the MAP, influencing the prior or the evidence will have a similar impact. The advantage is that comparing different regularization parameters needs not filtering the data multiple times.

Would adding the smoothness in time criterion to the regularization term help with estimating colinear problems though? (Here filtering the data wouldn't help.)

My 2 cents is that mentioning or adding an extra regularization term should be done in a subsequent PR2 could implement a model='quadratic' option and do comparisons w/ 'ridge' in an example.
As a general rule I prefer to go with vanilla models + regularizers etc unless it's really clear why a non-standard approach is better. I'd be interested in a conversation about enforcing smoothness in time w/ you all, perhaps at the sprint in march. obv the world of encoding models is vast and interesting :)

I agree with Chris here!

Yes, I also agree. So overall: LGTM :)

Would adding the smoothness in time criterion to the regularization term help with estimating colinear problems though? (Here filtering the data wouldn't help.)

My 2 cc: the Ridge regression is a Tikhonov regularization with a spherical Gaussian prior: i.e. the features are considered to be independent with equal variance. This kind of priors allows solving the colinearity issue in terms of fitting - IMO, this is different from solving the colinearity issue all together (i.e. disambiguating correlated features), which is a much deeper issue.
FWIU - but I would need to actually read the paper - the smoothness prior "includes" the spherical Gaussian prior, because instead of using the identity matrix I as a prior (in beta  = (X^TX + lambda I)^-1 X^T y), you pass a smoothing covariance A which includes the diagonal (i.e. beta  = (X^TX + lambda A)^-1 X^T y, where A = [[1, 2, 1, 0 ...], [0, 1, 2, 1, 0 ...] ..., [... 0, 1, 2, 1]]).

My 2 cents is that mentioning or adding an extra regularization term should be done in a subsequent PR2 could implement a model='quadratic' option and do comparisons w/ 'ridge' in an example.

+1

I'd be interested in a conversation about enforcing smoothness in time w/ you all, perhaps at the sprint in march.

+1

ok let's keep it for a future discussion/PR
On 1 January 2017 at 19:31, Chris Holdgraf<EMAIL_ADDRESS>wrote:

@choldgraf commented on this pull request.
In tutorials/plot_receptive_field.py
https://github.com/mne-tools/mne-python/pull/3728:

+X_train = X[train]
+X_test = X[test]
+y_train = y[train]
+y_test = y[test]

+# Model the simulated data as a function of the spectrogram input
+alphas = np.logspace(-4, 0, 10)
+scores = np.zeros(len(alphas))
+models = []
+for ii, alpha in enumerate(alphas):

mod = ReceptiveField(tmin, tmax, sfreq, freqs, model=Ridge(alpha))
mod.fit(X_train, y_train)

Now make predictions about the model output, given input stimuli.

y_pred = mod.predict(X_test).squeeze()
scores[ii] = r2_score(y_pred, y_test[~mod.mask_remove])

I had a conversation w/ Frederic the other day about this. I think there
are pros and cons to both. Maybe we can discuss at the sprint about whether
we want to standardize this for all examples in the future?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mne-tools/mne-python/pull/3728, or mute the thread
https://github.com/notifications/unsubscribe-auth/AEp7DC038U-tcuJ807NrwVBaVABLGSkxks5rOEV_gaJpZM4KokeM
.

lets see if these tests pass, I think I addressed all of the above

Hey all - most of @agramfort's comments addressed though there are still a few points to discuss which I'll summarize below in the hopes we get more broad discussion:

Right now the input shape is [n_epochs], n_channels, n_times. AKA, it is not sklearn-style (which would be n_samples, n_channels. I did it this way to be consistent with MNE style, since I thought folks wanted it that way. I could make n_samples the first dimension of inputs, but, it would make supporting epochs-like shapes difficult. I think it's important to let people fit models on subsets of their full dataset (e.g. epochs, or a pre-defined mask of times). Would love feedback on this point.
@agramfort brought up the question of how CV would be handled. The goal of this PR was to simplify from the last EncodingModel implementation and not support CV within the object itself, since the last time we did this there was consensus that the class was getting too beefy. Thoughts on this? And best ways to handle this? I am concerned that these two points are non-trivial to implement properly so I'd love to see some productive discussion :)

Right now the input shape is [n_epochs], n_channels, n_times. AKA, it is not sklearn-style (which would be n_samples, n_channels.

You could pass n_channels to the class, for example here ? If I remember correctly, 3D arrays work fine with Pipeline but not cross_validation_score, right?

I did it this way to be consistent with MNE style, since I thought folks wanted it that way. I could make n_samples the first dimension of inputs, but, it would make supporting epochs-like shapes difficult. I think it's important to let people fit models on subsets of their full dataset (e.g. epochs, or a pre-defined mask of times). Would love feedback on this point.

See above. Reshape if n_channels is not None ... do you think this might work?
Disclaimer: I haven't followed the rest of the discussion, so maybe I'm missing something!

Right now the input shape is [n_epochs], n_channels, n_times. AKA, it is not sklearn-style (which would be n_samples, n_channels. I did it this way to be consistent with MNE style, since I thought folks wanted it that way. I could make n_samples the first dimension of inputs, but, it would make supporting epochs-like shapes difficult. I think it's important to let people fit models on subsets of their full dataset (e.g. epochs, or a pre-defined mask of times). Would love feedback on this point.

IMO, the API should have the samples first because the fitting algorithm is blind to the epoch structure - unlike the classic cases, epochs would not be statistical repetitions, and would only exist in the eye of the experimenter. I would recommend having X, shape(n_times, n_epochs, n_channels) for epochs or X shape(n_times, n_channels) for raw, such that n_times is always the first dimension and is adjacent to the epochs dimension.

@agramfort brought up the question of how CV would be handled. The goal of this PR was to simplify from the last EncodingModel implementation and not support CV within the object itself, since the last time we did this there was consensus that the class was getting too beefy. Thoughts on this? And best ways to handle this? I am concerned that these two points are non-trivial to implement properly so I'd love to see some productive discussion :)

My understanding is that Alex brought up the issue of GridsearchCV for optimizing the regularization parameter. This is to be distinguished from the more general issue of CV in temporally ordered and inter-independent measurements.

The former is solvable by using Gridsearch with the ReceptiveField estimator (e.g. ReceptiveField(estimator=GridSearchCV(RidgeCV, alpha=[.1, 1., 10]))).

The latter is complex because the fitting is based on (the order of) non independent samples. I believe the correct API for this is to make a time-informed CV such that we can directly do cross_val_score(ReceptiveField(Ridge()), X, Y, cv=TimeCV(n_splits=10)). I.e. let's not make the same mistake that we did for TimeDecoding which handles the CV internally, and thus prevents pipelines likes cross_val_score(make_pipeline(SpatialFilter(PCA()), TimeDecoding())).

Ultimately, we can hope to add a parameter in the future like ReceptiveField(cv=5) to facilitate the user's work, but this can be addressed in a subsequent PR.

How do folks feel about supporting inputs of shape n_times, n_epochs, n_channels?
re: GridSearch etc, good point @kingjr, I think I missed @agramfort 's point. I also would like to see this compatible with something like gridsearch, just wasn't working on this in the current go because I thought people found forcing a sklearn-style API to be too much. If folks are +1 on this, I can re-configure this PR to see how it feels using that API. You'd have to use a fair amount of swapaxes in scripts etc, think that's OK?

I'm actually not sure that simple epoch concatenation is the right thing to
do. You might need to zero pad the duration of your model lags before
concatenation to avoid possible artifactual acausal or excessively late
responses.
Can we do epochs in a separate PR or is it an essential feature?
On Jan 2, 2017 12:13 PM, "Chris Holdgraf"<EMAIL_ADDRESS>wrote:

How do folks feel about supporting inputs of shape n_times, n_epochs,
n_channels?
re: GridSearch etc, good point @kingjr https://github.com/kingjr, I
think I missed @agramfort https://github.com/agramfort 's point. I also
would like to see this compatible with something like gridsearch, just
wasn't working on this in the current go because I thought people found
forcing a sklearn-style API to be too much. If folks are +1 on this, I can
re-configure this PR to see how it feels using that API. You'd have to use
a fair amount of swapaxes in scripts etc, think that's OK?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mne-tools/mne-python/pull/3728#issuecomment-269998088,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACQZXpWh2LP4egQfirpGrfxdpv6zBKcuks5rOTArgaJpZM4KokeM
.

not an essential feature, but I think that the ability to fit a model on subsets of time is (in the long run). People shouldn't fit encoding models (or at least they shouldn't score encoding models) on long stretches of time where there is no stimulus...
re: padding I agree. I think this is dealt with in the code, because it time lags each epoch first, then removes the times that don't have data for all possible lags (with mask_pred_), and then it concatenates across epochs.

sorry I don't have much bandwidth to think deeply into the issue. I wanted
to raise some API concerns when ready the example on real data.
can we wait for the sprint in March to finally sort this out? this PR will
be a perfect start on the monday.

Hmm, so put this on hold again until March then? If you guys think that's the right thing to do then I'm OK with it. OTOH I think it's good to do the most with momentum that's already been built on this PR in the last few days, so if there are some non-controversial things to be done etc, let me know and I can implement things up to the point where it's better to discuss in person.

I agree with chris, we're finally nearly there. Waiting would imply a new cognitive investment.

I think that the ability to fit a model on subsets of time is (in the long run). People shouldn't fit encoding models (or at least they shouldn't score encoding models) on long stretches of time where there is no stimulus...

It seems like the fitting step would be unaffected because the stimulus would be zero in the unused region, so the auto and cross-correlations would be unchanged. Regarding scoring, the same might be true. Have you tried doing it both ways, i.e. "masked" raw and epochs-based? I'm pushing the point because in the long term I suspect we'd gain a lot of code change simplicity from only supporting raw.

I agree with @kingjr and @choldgraf that it would be good to get this in before the sprint, if possible, since people have been thinking about it a lot.
How about we work on cutting an MNE-Python release next week, then have this PR as the first thing in 0.15-dev? Then any improvements we make in March are within a release cycle.
@agramfort FWIW given the current API, I think I can write a (restrictive) sklearn-style estimator that uses Ross's optimized code for Ridge regression during the sprint, if that's one of your concerns.

It seems like the fitting step would be unaffected because the stimulus would be zero in the unused region, so the auto and cross-correlations would be unchanged. Regarding scoring, the same might be true. Have you tried doing it both ways, i.e. "masked" raw and epochs-based? I'm pushing the point because in the long term I suspect we'd gain a lot of code change simplicity from only supporting raw.

In linear_regression_raw, time points where all predictors are zero are simply removed to make the resulting matrices, but if you skip that stage, the results are the same.
XDAWN internally stacks epochs to make fake raw data from epochs and it has perfectly usable code for that, actually. (Gentle reminder this module is the 3rd time we're implementing essentially the same procedure.)
Reusing this code base would be a decent way of handling the epochs case.

(Gentle reminder this module is the 3rd time we're implementing essentially the same procedure.)

So it sounds like a good action item for the sprint would be massive refactoring of these algorithms as much as possible. @jona-sassenhagen can you check if the current API for ReceptiveField lends itself well to refactoring with XDAWN/ linear_regression_raw? If the existing two related algorithms support epochs-based processing, then ReceptiveField might as well, too.
I'll have to think about how to make the efficient algorithm work with the Epochs case. It will be more annoying but should be doable.

So it sounds like a good action item for the sprint would be massive refactoring of these algorithms as much as possible. @jona-sassenhagen can you check if the current API for ReceptiveField lends itself well to refactoring with XDAWN/ linear_regression_raw? If the existing two related algorithms support epochs-based processing, then ReceptiveField might as well, too.

The MNE version of XDAWN supports only epochs (original is Raw based, but Alex G convinced Alex B to make it Epochs-based). linear_regression_raw is, well, Raw :)
There is already a PR for refactoring together XDAWN and linear_regression_raw, the blocker right now is what algorithm to use for building the predictor array; eventually, we will have to benchmark all 3 methods for various use cases, maybe at the sprint.

I'll have to think about how to make the efficient algorithm work with the Epochs case. It will be more annoying but should be doable.

In the original rERP implementation, Nathaniel Smith reports an incremental method that supposedly works great with subepochs - fast and memory saving. (You don't have to build the full predictor array). Not sure it works with standard CV approaches though. Maybe you still want to have a look.
linear_regression_raw and XDAWN also have ways of returning the coefs by the way.

... so in other words, this PR's API should be no worse for refactoring than what we already have to deal with (both epoch-based and raw-based)? :)

I fear/hope so.

It seems like the fitting step would be unaffected because the stimulus would be zero in the unused region, so the auto and cross-correlations would be unchanged. Regarding scoring, the same might be true. Have you tried doing it both ways, i.e. "masked" raw and epochs-based? I'm pushing the point because in the long term I suspect we'd gain a lot of code change simplicity from only supporting raw.

I think on the fitting side the effect may not be too big (but I suspect it depends on the SNR of the data). As a general rule I feel like it's just good to avoid feeding "noise" (well not really noise, but times when the signal of choice isn't driving your system) into the fitting algorithm.
On the scoring side, I think that including timepoints where there is no stimulus may bias the score upwards. E.g., if you plotted a scatterplot of model predictions against their true values, you'd want to show that the "blob" has a linear shape to it. If you include a bunch of stimulus==0 timepoints, then you might instead be creating two blobs - one corresponding to "stim on" timepoints, and the other corresponding to "stim off" timepoints. In that case, if you did something like correlation between predicted / actual values, then it would be skewed upwards because it would pick up the difference between the two blobs, instead of the details within the "stim on" blob. It's a subtle point and it may not matter in some circumstances, but I've seen it bias my model scores upwards in the past for some datasets.
re refactoring: I think that's a great idea. Happy to work with you guys on this at the sprint. At that point we could have 3 implementations of model fitting etc, but none of them yet being in a full MNE release, so we can mix and match as needed :)

ok latest push has first dimension as time + corresponding edits to the examples etc. I changed the way that time delaying worked because I realized there was an unnecessary extra operation in there.
Now that time is first dimension, is it worth adding a score method so that this would work with GridSearchCV? Or is that better done in a different PR?

Now that time is first dimension, is it worth adding a score method so that this would work with GridSearchCV? Or is that better done in a different PR?

This sounds like a separable feature to me, so +1 for separate PR, for which I've created #3884

cool - should I also rename it to "Multivariate statistics - Decoding and
encoding"?
On Thu, Jan 5, 2017 at 1:18 PM Eric Larson<EMAIL_ADDRESS>wrote:

@Eric89GXL commented on this pull request.
In tutorials/plot_receptive_field.py
https://github.com/mne-tools/mne-python/pull/3728#pullrequestreview-15394154
:

@@ -0,0 +1,227 @@
+"""

You need to add this to tutorials.rst, currently it isn't in any list here
https://3441-1301584-gh.circle-artifacts.com/0/home/ubuntu/mne-python/doc/_build/html/tutorials.html
Although for reviewing purposes it currently is here
https://3441-1301584-gh.circle-artifacts.com/0/home/ubuntu/mne-python/doc/_build/html/auto_tutorials/plot_receptive_field.html
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mne-tools/mne-python/pull/3728#pullrequestreview-15394154,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABwSHfmpJ9XVIQ9w74EwyFhctuhuL9F8ks5rPV4FgaJpZM4KokeM
.

Last set of gripes from me. And please set to MRG if it's ready to go from your end and you have addressed all comments

I'll set to MRG once we figure out how to link directly to the figures w/o going over the line limit, and if nobody else has comments. Then I can update whats_new as well.

So the noqa does prevent travis from getting angry, but it makes the anchor link not work properly. It still goes to the right page but not the right section within the page. Maybe not a big deal?

OK @Eric89GXL check the latest push, I think that the folding in method w/ links in the description works. IMO it actually makes the raw text more readable as well, it seems like hyperlink anchors naturally would go underneath the references in the description anyway:
https://3451-1301584-gh.circle-artifacts.com/0/home/ubuntu/mne-python/doc/_build/html/auto_examples/decoding/plot_receptive_field.html
Maybe worth suggesting this in the doc contributor guidelines as well?

Maybe worth suggesting this in the doc contributor guidelines as well?

Sure, but this is a bit of a corner case really. If we add all suggested practices / ideas to the dev docs, we risk making it too dense and long, and then people will ignore them. We could add an "advanced" separate page and put it there?
I actually think a similar split might be good for the Python install instructions to make that page shorter.

I'm all for splitting longer pages into modular, shorter ones. re: edge case, it seems that this would come up any time someone wanted an external link in their tutorial / example. I guess that isn't common? It seems like it'd be quite useful in many cases.

(the docs comment was meant for a different PR / discussion anyway, just a thought!)  for this PR, let me know if there's anything else I should take a look at. Or LMK when I can set to MRG and edit whats_new

Feel free to set to MRG if it's ready from your end. FYI the plan is to merge after releasing this month but in the meantime MRG will tell people to look if they have time. And then I can set MRG+1 :)

Sounds good - I'll set to MRG but I'll wait to edit whats_new until the next release, so that we don't merge conflicts. that work?

OK I updated the code to add a scoring method, and changed the example / tutorial accordingly. Predict no longer masks any data, only creates the mask attribute. Score uses that attribute before passing data to score. I should write some extra tests for score / predict now, which I'll do next if the code looks OK to you all.

Also would it be appropriate to add a reference for my paper that just came out? If so then better to have it either in the tutorial or in the docstring of the ReceptiveField class? It's an ECoG STRF paper basically. Or if better to not include it, that is totally fine too since it's not really a "methods" paper.
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5187445/

I think it's fine to add a reference to your paper. Even better if you
figure out the data sharing issues so you can recreate a published figure
eventually :)

That is the goal eventually but it'll take some time to sort out the
details. Then I want to create an example :-)
On Sat, Jan 7, 2017, 1:24 PM Eric Larson<EMAIL_ADDRESS>wrote:

I think it's fine to add a reference to your paper. Even better if you
figure out the data sharing issues so you can recreate a published figure
eventually :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mne-tools/mne-python/pull/3728#issuecomment-271111214,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABwSHWfScqnHQ-Q9LlDDcwWKKTu3UG_aks5rQAKbgaJpZM4KokeM
.

OK I think the tests are passing again with the score method.
On Sat, Jan 7, 2017, 1:33 PM Chris Holdgraf<EMAIL_ADDRESS>wrote:

That is the goal eventually but it'll take some time to sort out the
details. Then I want to create an example :-)
On Sat, Jan 7, 2017, 1:24 PM Eric Larson<EMAIL_ADDRESS>wrote:
I think it's fine to add a reference to your paper. Even better if you
figure out the data sharing issues so you can recreate a published figure
eventually :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mne-tools/mne-python/pull/3728#issuecomment-271111214,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABwSHWfScqnHQ-Q9LlDDcwWKKTu3UG_aks5rQAKbgaJpZM4KokeM
.

ok looks like tests passing, LMK if you'd like me to make any other changes. Otherwise I won't plan on any action taken on this until the next release happens

ok, I haven't followed the last commits. Is there a need for another full
review, or can we merge?
On 9 January 2017 at 15:31, Chris Holdgraf<EMAIL_ADDRESS>wrote:

ok looks like tests passing, LMK if you'd like me to make any other
changes. Otherwise I won't plan on any action taken on this until the next
release happens
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mne-tools/mne-python/pull/3728#issuecomment-271398766,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEp7DPsx19y3xNgUSB5ECaaAYboZLuTfks5rQpkFgaJpZM4KokeM
.

We're going to wait until the next release cycle to merge, but if it's fresh in your mind it's good to look now. Hopefully it's the first thing we merge after release, and the only thing that will need to change is the whats_new.rst.

just to let you know, besides the hacking of the montage object, I like the new example on the real data API wise :) #everythingispossible

Excellent, sounds like we should be good to merge after release, then. We can fix the Montage bits in a separate PR. Okay @agramfort?

I need to review the numerics but API wise I am happy

@choldgraf one more thing. Looks like you need a rebase because of a conflict. But also, new datasets should be documented in doc/manual/datasets_index.rst, so please add an entry there (make sure you rebase first because I made a bunch of changes to that file yesterday).

OK, I'll plan on rebasing etc in general after the new release and then I
can make these changes
On Thu, Jan 12, 2017 at 9:03 AM Eric Larson<EMAIL_ADDRESS>wrote:

@choldgraf https://github.com/choldgraf one more thing. Looks like you
need a rebase because of a conflict. But also, new datasets should be
documented in doc/manual/datasets_index.rst, so please add an entry there
(make sure you rebase first because I made a bunch of changes to that
file yesterday).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mne-tools/mne-python/pull/3728#issuecomment-272220703,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABwSHfzKk5mLZS85i3gxLtfJ5aTp95B8ks5rRlz2gaJpZM4KokeM
.

LGTM +1 for merge
@choldgraf has rebased. Updated example and tutorial:
https://4056-1301584-gh.circle-artifacts.com/0/home/ubuntu/mne-python/doc/_build/html/auto_examples/decoding/plot_receptive_field.html
https://4056-1301584-gh.circle-artifacts.com/0/home/ubuntu/mne-python/doc/_build/html/auto_tutorials/plot_receptive_field.html

Updated this PR so that ReceptiveField accepts a floating point value that will be passed to Ridge right now, in the future @Eric89GXL will implement a fancy shmancy Ridge that is more efficient

ok

+1
more explicit than a squeeze

ok latest push privatizes the delay function and does the manual delaying in the example. Also added some tests for custom scorers and renamed the input to scoring. LMK how that looks.
If @agramfort is still happy with the current state, perhaps @kingjr can take a look.

ok this version only allows for one of two string inputs, r2 or corrcoef.

Let's save the vectorize for later, assume YAGNI for now

ok so if travis is happy then I (think) it's +1 from both @Eric89GXL and @agramfort ... @kingjr do you wanna take a look? And then once you guys are all done I can just delete this PR and start from scratch for kicks.

@choldgraf can you update what's new
then +1 for MRG when CIs are happy !

ok I think @kingjr 's comments are addressed, now I'm coming for 🍻 !

Thanks @choldgraf


Import from URL (Sharepoint or Onedrive)

Is it possible to Import xls from a Sharepoint site?  The -Path statement does not seem to allow a direct url to an xls stored on Sharepoint.   I am not sure if there is a different formatting I need to use for the path statement.

I don't know SharePoint. So I'm not sure. I think if you can open it from the file manager, this ought to work but I've never tried it.

I'm interested in going the other way:  Using Excel Services on SP, use PS to assemble the data and update one or more sheets in a workbook.  There will also be analysis and other macros, which I want to persevere in the workbook.  I can provide a public sharepoint site for testing.


Help whit spawn, please response quickly!

Hi Multiverse-core team, can you help me whit the /mvtp?
My problem is what when i use /mvtp I am teleported not where i was, but where there is the default spawn. This is a big problem for a vanilla server. How can i fix it?
Sorry for my english but i'am italian.
Thank you and goodbye,
A multiverse core user!!

Pleaseeeeee responseeeeeeeeee

When teleporting between worlds, the default behavior is to go to the spawn of the world. This can be changed; however, it's not perfect. You'll require Multiverse-Inventories (same version as your MV-Core). Once installed, you'll need to toggle last_location on by doing /mvinv toggle last_location. Keep in mind this forces last location for ALL worlds, there is currently no way to only use this function for specific worlds.


Update refined, refined-scalacheck to 0.11.1

About this PR
📦 Updates

eu.timepit:refined
eu.timepit:refined-scalacheck

from 0.9.29 to 0.11.1
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "eu.timepit" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "eu.timepit" }
}]

labels: library-update, early-semver-major, semver-spec-minor, commit-count:1

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (26ab88a) 84.88% compared to head (c58a54a) 84.95%.

:exclamation: Current head c58a54a differs from pull request most recent head 07717a9. Consider uploading reports for the commit 07717a9 to get more accurate results

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@                Coverage Diff                @@
##           series/0.14.x    #2231      +/-   ##
=================================================
+ Coverage          84.88%   84.95%   +0.07%
=================================================
  Files                 76       76
  Lines               2739     2739
  Branches             360      360
=================================================
+ Hits                2325     2327       +2
+ Misses               414      412       -2

Flag
Coverage Δ

2.12.18
84.78% <ø> (+0.03%)
:arrow_up:

2.13.11
84.93% <ø> (-0.04%)
:arrow_down:

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

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Allow "cdef inline" with default values in .pxd

A cdef inline implemented in a .pxd with default values does not work as expected:
cdef inline int my_add(int a, int b=1, int c=0):
     return a + b + c

gives default values cannot be specified in pxd files, use ? or *
This pull request fixes that.

Looks good, thanks.


Es5 integration

restructured pyramid, now contains 2 modules: core, phrase-count-plugin

Nice job, Jinpeng! Is it possible to keep the pyramid package name as it is? It feels to me that the module names "core" does not need to appear again in the package name. I am following elasticsearch naming convention here:
https://github.com/elastic/elasticsearch/blob/master/core/src/main/java/org/elasticsearch/client/Client.java

Sure, I'll remove it.


Debug Service Continues to Fail (Refer to issue #2110)

Type: Bug
Connect to IBM i system > Start the debug server > Attempt to start the debug service in which the issue occurs at this step. It is affecting my entire team who use this tool, we all receive the same error message as well.

Opened new issue as I did not see any option to re-open the old one. The first suggestion in #2110 was to wipe the certs and generate new ones and that did not fix the problem. The second troubleshooting step had an unrelated error message to mine. Seeing if anyone has any other suggestions.
Extension version: 2.10.1
VS Code version: Code 1.90.0 (89de5a8d4d6205e5b11647eb6a74844ca23d2573, 2024-06-04T19:33:54.889Z)
OS version: Windows_NT x64 10.0.19045
Modes:

System Info

Item
Value

CPUs
AMD Ryzen 5 PRO 7530U with Radeon Graphics      (12 x 1996)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: enabled_ondirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okskia_graphite: disabled_offvideo_decode: enabledvideo_encode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabledwebgpu: enabled

Load (avg)
undefined

Memory (System)
15.31GB (5.00GB free)

Process Argv
--crash-reporter-id f363ceb0-20c6-49c7-80ad-3a25bbb3f05d

Screen Reader
no

VM
0%

A/B Experiments
vsliv368cf:30146710
vspor879:30202332
vspor708:30202333
vspor363:30204092
vscoreces:30445986
vscod805cf:30301675
binariesv615:30325510
vsaa593cf:30376535
py29gd2263:31024239
c4g48928:30535728
azure-dev_surveyone:30548225
a9j8j154:30646983
962ge761:30959799
pythongtdpath:30769146
welcomedialog:30910333
pythonidxpt:30866567
pythonnoceb:30805159
asynctok:30898717
pythontestfixt:30902429
pythonregdiag2:30936856
pythonmypyd1:30879173
2e7ec940:31000449
pythontbext0:30879054
accentitlementst:30995554
dsvsc016:30899300
dsvsc017:30899301
dsvsc018:30899302
cppperfnew:31000557
dsvsc020:30976470
pythonait:31006305
jchc7451:31067544
chatpanelc:31048052
dsvsc021:30996838
bdiig495:31013172
pythoncenvpt:31062603
a69g1124:31058053
dvdeprecation:31068756
pythonprt:31056678
dwnewjupytercf:31046870
26j00206:31048877

Two questions for you:

What does this query returns when run on your system?

With JAVA_PTF_GROUP as (
  SELECT PTF_GROUP_TARGET_RELEASE OS,
  Case PTF_GROUP_TARGET_RELEASE
    When 'V7R4M0' Then 'SF99665'
    When 'V7R3M0' Then 'SF99725'
    When 'V7R2M0' Then 'SF99716'
    When 'V7R1M0' Then 'SF99572' End PTF_GROUP
FROM QSYS2.GROUP_PTF_INFO
WHERE PTF_GROUP_DESCRIPTION = 'TECHNOLOGY REFRESH'
AND PTF_GROUP_STATUS = 'INSTALLED'
LIMIT 1)
Select Max(OS) OS,
PTF_GROUP_NAME,
Max(PTF_GROUP_LEVEL) "CURRENT LEVEL"
From  QSYS2.GROUP_PTF_INFO
Inner Join JAVA_PTF_GROUP On PTF_GROUP = PTF_GROUP_NAME
Group by PTF_GROUP_NAME;

What's the output of java -version when run in batch?

Return of query:

The system is running 11.0.8 but JAVA_HOME that the debugger is referencing is java version 1.8.0_341

This links seems like it may be useful https://www.ibm.com/support/pages/support-hmacpbesha256-algorithm-app-connect-enterprise. Will investigate this to see if it will assist.

I looked into this a bit and every time, it boils down to "Java doesn't support this algorithm". I would understand if the keystore was generated by Java, but we use openssl to generate it; and it worked fine on every LPAR I tried it on (i.e. Java 8 had no issue opening the keystore).
What's the output of these commands for you?
openssl version

which openssl

IBM i Debug v2.0.1 was just released. Debug v2 uses Java 11 instead of Java 8. This Java 8 specific error is unlikely to happen in Java 11.

Nice, when the system is back up I will give this a go! Updates to come.

I've updated to IBM i Debug v2.0.1 but, when I boot up the system and such the debugger still says 1.0.0:

Any way to get it to use the new version?

I've updated to IBM i Debug v2.0.1 but, when I boot up the system and such the debugger still says 1.0.0:

Any way to get it to use the new version?

You need to install the host update too to get Debugger v2.

And now that I think about it, the debug service configuration will have to be updated to use Java 11, too.

Noted, I will look into getting the new PTF next week, and will also change the debugger config. Updates to come.
Nice! To update the configuration, open it from the Debugger view:

Then scroll down and update the JAVA_HOME variable

Change it to:
JAVA_HOME=/QOpenSys/QIBM/ProdData/JavaVM/jdk11/64bit

Save the configuration and you should be good to go.
Alternatively, you can delete the existing certificate and let Code for IBM i create a new one; it will update the configuration as well.

@sebjulliand to answer your question:

I looked into this a bit and every time, it boils down to "Java doesn't support this algorithm". I would understand if the keystore was generated by Java, but we use openssl to generate it; and it worked fine on every LPAR I tried it on (i.e. Java 8 had no issue opening the keystore).
What's the output of these commands for you?
openssl version

which openssl

Openssl version: OpenSSL 3.0.10 1 Aug 2023 (Library: OpenSSL 3.0.10 1 Aug 2023)
which openssl: /QOpenSys/usr/bin/openssl
Our system hardware was upgraded and there has been some issues, so for the time being I am not able to apply the new PTF to allow me to use the new debugger (2.0). Would be nice if I could get version 1.0 working while I wait.

Maybe the output from which openssl is a good hint. Your openssl version seems OK but which points to /QOpenSys/usr/bin instead of /QOpenSys/pkgs/bin.
Can you check your PATH variable?
echo $PATH

I assume that /QOpenSys/usr/bin must appear before /QOpenSys/pkgs/bin. If it's the case, then try to put /QOpenSys/pkgs/bin in first position in the .bashrc file in your home directory.
Then re-open a shell session and check that which openssl answers /QOpenSys/pkgs/bin/openssl this time.
Then generate the certificate again.
If it still doesn't work, I'll have one more trick up my sleeve (or maybe two...).

echo $PATH ouput: /usr/bin:.:/QOpenSys/usr/bin
And when I check my .bashrc in the following directory home/myProfileName it has the current contents:
Generated by Code for IBM i
export PATH=/QOpenSys/pkgs/bin:$PATH
So it seems like it is already setup how it should be?

Try this now:

Download this zip
Unzip it
Install the vsix found inside. It's a special build that includes the -legacy flag when openssl is invoked to generate the PKCS12 file.
Connect to your LPAR
Delete any existing certificate
Generate a new one
Start the debug service

I tried it on my system and it worked (with or without the -legacy flag).
Let me know how it goes for you after you generated a certificate with this 2.11.4-dev.0 build.

I installed the vsix file and removed the certificates. When trying to re-generate them I get this error (where the blacked out portion is the DNS for our system):

After having a close look, it turns out your PATH makes you use openssl provided by yum instead of /QOpenSys/usr/bin/openssl. This causes some issues, obviously 😅
Here is another vsix generated from this PR: https://github.com/codefori/vscode-ibmi/pull/2151
code-for-ibmi-2.11.5-dev.0.vsix.zip
It will force the use of /QOpenSys/usr/bin/openssl when generating the certificates. This should take care of your issue once and for all.
Let me know how it goes!

Installed it and while the certificates could be generated this time. The original error still persists (I do enjoy how you added the output of the error message to VS Code!):

I'll need to check two thing related to your environment:

The content of your /QOpenSys/QIBM/ProdData/JavaVM/jdk80/64bit/jre/lib/security/java.security file
The output of the env command when run in a PASE terminal

Also, while we're at it, from a PASE terminal, run this:
/QOpenSys/usr/bin/openssl genrsa -out test_cert.key 2048 && /QOpenSys/usr/bin/openssl req -new -key test_cert.key -out test_cert.csr -subj '/CN=localhost' && /QOpenSys/usr/bin/openssl x509 -req -in test_cert.csr -signkey test_cert.key -out test_cert.crt -days 1095 -sha256 -req && /QOpenSys/usr/bin/openssl pkcs12 -export -out test_keystore.pfx -inkey test_cert.key -in test_cert.crt  -password pass:password && rm test_cert.*

This will create a test_keystore.pfx file in the current directory on the IFS. Please retrieve it, put it in a zip file and attach it in a reply.
Thanks!

Java Security Contents.pdf
Env Command: (blacked out company/personal info)

test_keystore.zip

Any updates on this @sebjulliand?

No...I compared your file with the ones I have on two LPAR running the service and couldn't spot any difference.
Nothing useful in the env output either.
The only thing I can say is that on the 7.3 box that runs the service, current level is 28:

If you can, ask to update SF99725 to the latest level. It shouldn't hurt and it may solve this issue.

Also, if you can, attach these files if they exist.
Debug service log:
/QIBM/UserData/IBMIDEBUGSERVICE/DebugService_log.txt
Debug service Eclipse instance log:
/QIBM/UserData/IBMIDEBUGSERVICE/startDebugService_workspace/.metadata/.log
Thanks!

I will look into upgrading the version you mentioned. I did not see anything for the Debug Service Log but here is the other .log file: .log

Yeah our team can't really apply any PTFs right now, so upgrading the version won't be possible currently. When we are able to apply PTFs I will get the ones that allow me to use V2 of the debugger.


Add --script-root option to host start

resolves #264
@ahmelsayed unfortunately this is more hacky than I want it to be.
The main issue is that ISecretsManager is created via the Autofac container registry, but I need to configure it with the proper script root path to search for AppSettingsFilePath.
With the way the actions are set up, I don't know that there's a good way to use autofac's lambdas or provider patterns in order to supply the scriptRoot argument to the secrets manager - I'd love any input you have on that.
One possibility is that we could ignore ISecretsManager altogether and use local.settings.json that exists on the cwd, not the ScriptRoot. This might be more reasonable, will revisit tomorrow.
TODO: reapply defaults from hostSettings

@mamaso,
Thanks for having already signed the Contribution License Agreement. Your agreement was validated by .NET Foundation. We will now review your pull request.
Thanks,
.NET Foundation Pull Request Bot

yeah I forgot about that :/
I can think of 2 potential ways, but I'm not sure how viable they are. one way is to intercept that argument early in here similar to how --pause-on-error is handled. Then actions would just ignore it as the parser ignores arguments that haven't been setup. (you may need to make the container an Action<IContainer> if autofac gives you too much grief)
the other option I could think of is to maybe have an event that secretsManager (and other objects that care about workingDir) subscribes to, then any action that wants to change the workingDirectory should fire it before it does. however since events are asynchronous, not sure how to avoid potential race conditions.
I'm leaning more towards the first approach, as you'd be handling that before any of the complicated logic of ConsoleApp kicks in, so everything else should continue to work as is. What do you think?

closed in favor of #266


Add PULL REQUEST Template

@suman-kr this looks good but can we move the file inside .github directory? That way we can have multiple pull-request template 😓 and our root directory will also not be cluttered.
REF: https://docs.github.com/en/free-pro-team@latest/github/building-a-strong-community/creating-a-pull-request-template-for-your-repository


Do we want to keep maintaining this meta-package?

I personally don't, what do you think @facundominguez, @mboes, @qnikst ?

In the age of Stackage, this package has outlived its usefulness for users. It's only useful for developers, to pull in all core CH packages in one go and define a common stack.yaml to hack on them. If you all agree, perhaps we should update the README to that effect.

+1

Bump... I really think it might be worth getting rid of this repo. It's a maintenance overhead nobody really has time for, and doesn't serve much purpose from what I can see...
Thoughts...?

There may be a bit of use for development reasons, as you can keep a single stack.yaml, cabal.project file and pull all the relevant versions automatically during development. But in this case, this repo should be actually a single stack.yaml and cabal.project file without subrepos. However, this leads to a huge maintenance burden that counterweight anything good this project brings.
So let's go for that and archive this repo.

Thanks @qnikst


Does Vina-GPU support Flexible Sidechain Docking?

Trying to use GPU to accelerate processes like these

Hi, sorry the current version of Vina-GPU does not support Flexible Sidechain Docking


Skip unsupported kinds

Some resource kinds known to flux may not be supported or could have been administratively disabled; skip over them silently.

Some resource kinds known to kured

kured?

kured ?

Fixed!


Qualified Relation subclasses?

It looks like in the vocab, the preferred method of defining types of (in this case) relations is to create a subclass which then becomes part of the vocabulary.  @elf-pavlik has examples: Membership (elf Pavlik member of Social WG), Following (elf Pavlik following Amy Guy).
My question is what to do with the proliferation of subclasses which can occur, and which in our case are user defined.  Some examples:

In w3c, more specifically, elf Pavlik invited expert of Social WG.  Would InvitedExpertMembership or something similar be created as a subclass of Membership?

We work with a local network of herbalists and farmers, and they have defined the following relationship types between agents (people or organizations) (partial list): Advisor, Owner, Supplier, Drying Site, Harvesting Site, Trainer, Harvester, FarmResponsibility.

We know a network of software developers who have defined: Mentorship, Stewardship, both between 2 people.  The also have Members and Contributors, between a person and an organization.

Our software could spit out the vocabulary that is defined by users, maybe as a vocab specific to the installation (to handle conflicts), but that is far short of a carefully documented vocabulary.  So, if we do that, should we spit out the new user-defined relationships as subclasses of Qualified Relation? Or is some other alternative acceptable that would just have a different qualification without being a new subclass?
P.S. I like the option to use Qualified Relation or a simple object property to express a relationship/role, seems like a very positive direction.

Another way to do it is to have actions or activities with types (or subclasses) and the result could be many things - new relationship formed (e.g. follows), new item created, tag added, etc. Alex Passant and PM Champin did some work on mapping Activity Streams to SIOC Actions five years ago, see http://www.slideshare.net/mobile/pchampin/s-5112062 and http://rdfs.org/sioc/actions
John
http://Bresl.in

On 30 Apr 2015, at 19:57, Lynn Foster<EMAIL_ADDRESS>wrote:
It looks like in the vocab, the preferred method of defining types of (in this case) relations is to create a subclass which then becomes part of the vocabulary. @elf-pavlik has examples: Membership (elf Pavlik member of Social WG), Following (elf Pavlik following Amy Guy).
My question is what to do with the proliferation of subclasses which can occur, and which in our case are user defined. Some examples:
In w3c, more specifically, elf Pavlik invited expert of Social WG. Would InvitedExpertMembership or something similar be created as a subclass of Membership?
We work with a local network of herbalists and farmers, and they have defined the following relationship types between agents (people or organizations) (partial list): Advisor, Owner, Supplier, Drying Site, Harvesting Site, Trainer, Harvester, FarmResponsibility.
We know a network of software developers who have defined: Mentorship, Stewardship, both between 2 people. The also have Members and Contributors, between a person and an organization.
Our software could spit out the vocabulary that is defined by users, maybe as a vocab specific to the installation (to handle conflicts), but that is far short of a carefully documented vocabulary. So, if we do that, should we spit out the new user-defined relationships as subclasses of Qualified Relation? Or is some other alternative acceptable that would just have a different qualification without being a new subclass?
P.S. I like the option to use Qualified Relation or a simple object property to express a relationship/role, seems like a very positive direction.
―
Reply to this email directly or view it on GitHub.

@elf-pavlik also mentioned about schema:Role  in #1
http://blog.schema.org/2014/06/introducing-role.html

Do these subclasses have additional properties? If not I would suggest to consider using a SKOS property of the superclass instead.

@akuckartz I like your point about keeping in mind if potential subtypes of QualifiedRelation/N-aryRelation class have any custom properties, even sub properties which specialize other properties. e.g. http://schema.org/participant

@akuckartz Thanks! These subclasses can be grouped broadly based on properties (which we haven't nailed down yet), but beyond that they do not have additional properties.  Will see if I can figure out how to use SKOS properties.  If you have a quick example and time, could you post it?
@parklize Yes, thanks.  I think schema:Role has the same issue of proliferating subclasses, correct me if I'm wrong.  And I don't know which existing structure is best, didn't mean to emphasize QualifiedRelation.  Just trying to see how to deal with user defined roles or types.  And happy that we have something that can have properties, is not just the relation.
@elf-pavlik  Interesting example (participant).  I can see we may need to distinguish between actions that don't really imply an ongoing relationship between agents, and explicit definitions of ongoing relationships.  I think this is part of where you were going with your follows examples, which I now can't quickly find, but liked.  :(  In our case, we are giving people a way to record the shape of their network(s) in agent relationships.


Change default repeat_distance for point feature labels

The default repeat_distance for labels has always been 256px across the board. This is a sensible default for cases such as street labels (the original use case for repeat label culling) and road shields, but can generate unexpected results particularly when applied to point labels.
For example, when labelling data with a property that has a finite set of values, such as category names ("bar", "restaurant", "hardware store", etc.) or numeric values, it's often surprising/undesirable that only a few labels are plotted.
This branch changes this behavior such that:

For labels generated from point features, the default repeat_distance is 0px.
For all other labels, including those generated from line or polygon features (e.g. street names, road shields, park names, etc.), the default repeat_distance continues to be 256px. Note that in these examples, the labels themselves may still be point labels -- it is the underlying geometry type that matters, e.g. road shields are point labels generated from line geometries.

This example illustrates the difference in point geometry behavior:
        draw:
            points:
                color: red
                size: 4px
                collide: false
                text:
                    text_source: function(){ return 1 }
                    font:
                        color: white
                        stroke: { color: black, width: 4px }

In the prior behavior, only a few point labels are shown, and in the new behavior, all points are rendered:

@matteblair @meetar @nvkelso we talked about this a few months ago... finally getting around to it.

LGTM!


[TIC-14] Fix unnecessary rendering of RequiredAuthProvider

Background
When rendering the RequiredAuthProvider, there were unnecessary renders whenever a child component was rendering. Typically, this behavior should not effect a parent component, especially if none of the props/context values have changed. However, as seen in this example project, the rendering happened on each re-render of a child component.
The Issue
As standard React practices go, it is very important to avoid declaring and initializing React components inside of other components, as each time the parent is rendered, all of its components inside will be redeclared. This causes bugs with the React lifecycle for the nested component and the outer component, even if there are no render-related changes. This change can actually be seen in this code, as provided to show a workaround for teh RequiredAuthProvider, but with a caveat:
export default function App({Component, pageProps}: AppProps) {
    return (
        <AuthProvider
            authUrl={
                process.env.NEXT_PUBLIC_AUTH_URL ?? ""
            }
        >
            <RequireAuth>
                <Wrapper>
                    <Component {...pageProps} />
                </Wrapper>
            </RequireAuth>
        </AuthProvider>
    );
}

type RequireAuthProps = {
    children: React.ReactNode
} & WithLoggedInAuthInfoProps

const RequireAuth = withRequiredAuthInfo(({children}: RequireAuthProps) => {
    return <>{children}</>
})

As seen here, there are no nested components, but there is no capabilities for the displayWhileLoading or displayIfLoggedOut props.
The Solution
Since we still need the displayWhileLoading and displayIfLoggedOut props for the provider, we instead need to add it to the context of the AuthProvider. This way, we can avoid nesting a component while having these values. As such, the values will be useless unless used with withRequiredAuthInfo, as this function accounts for them. They can now be passed as props to the RequiredAuthProvider without any component nesting. Tests have been added to display the behavior of this new flow.

This has been moved to be rebased on top of main: https://github.com/PropelAuth/react/pull/44