Phase-slope index using spectral_connectivity_time instead of spectral_connectivity_epochs?

[seqasim]

Describe the problem

Currently, the function for computing phase-slope index is hard-coded to be computed over epochs to produce time-resolved PSI, and there's no option for computing the phase-slope index over time to produce PSI per epoch. This would be useful if you think the average directionality between two signals over the entire timecourse is informative. You could compute this by binning your trials into categories (i.e. good trials v. bad trials) and then computing PSI, but there's no way to compute PSI per epoch and relate it to continuous trial-level predictors. This should be possible unless I'm missing something

Describe your solution

1. Add a _cohy function to mne_connectivity.spectral.time by removing the absolute value from _coh

2. Mimic conditional statements for coh for cohy in _pairwise_con and _parallel_con

3. Create a new function phase_slope_index_time that mimics phase_slope_index but utilizes our new computation of cohy using spectral_connectivity_time instead of spectral_connectivity_epochs

Does this sound reasonable or am I missing some obvious reason not to do this? If so, I'm happy to implement this and test and make a pull request.

[adam2392]

This seems reasonable to me. IIUC, the original PR just didn't add cohy to ere on the side of simplicity.

@tsbinns any thoughts?

[tsbinns]

I don't see any problems. With #163 merged spectral_connectivity_time can return complex values, would just need to list the new cohy method here alongside cacoh:

mne-connectivity/mne_connectivity/spectral/time.py

Lines 563 to 569 in 2af1398

	for m in method:
	# CaCoh complex-valued, all other methods real-valued
	if m == "cacoh":
	con_scores_dtype = np.complex128
	else:
	con_scores_dtype = np.float64
	conn[m] = np.zeros((n_epochs, n_cons, n_freqs), dtype=con_scores_dtype)

[adam2392]

SG. Feel free to submit a PR @seqasim

[seqasim]

Sorry for the delay - created a PR here: #210

[seqasim]

Also, I believe the same logic can be applied to dPLI?

[tsbinns]

Also, I believe the same logic can be applied to dPLI?

Seems like it. Perhaps that's worth a fresh PR to reduce individual diffs?