Differences in PTE values when different scouts were used

Hi,

I'm trying to do PTE connectivity based on more than one pair of scouts, and I found that when I used different scouts, such as 5 scouts vs. 10 scouts, the output PTE value (whether or not it was normalized) is slightly different. Is that possible? What is the reason behind it?

Here's the screenshot of my operation:
5 scouts 11 scouts

Best
Duan

I am not familiar with this function, but it seems unlikely that the PTE between two scouts would depend on the values estimated for another pair of scout.
Whether you compute the PTE for scouts A/B or for scouts A/B/C, you should obtain the same interaction A/B.

@MartinC Is this correct?

@duanjipeng Please be more specific. How did you get to observe that the values are "slightly different"? If this is something you can reproduce, could you please describe precisely how we can reproduce your observations? (If possible based on the TutorialIntroduction protocol, so that you don't have to send us any data)

Hi Francois,

Thanks for your quick reply.

The specific steps I took were:

  1. Drag and drop reconstructed sources data (a total of 10 scouts were project to each file) from 2 subjects (for testing purposes) in Process1 tab.

  2. Click on [Run] to open the Pipeline editor.

  3. Run the process: Connectivity > Phase Transfer Entropy NxN. Then I chose all 10 scouts and two frequency bands (15-18Hz & 18-21Hz) to do PTE connectivity.
    11 scouts

  4. By running the process function, the PTE value can be displayed in a 10x10 matrix.

Then I repeated the 4 steps above. At step 3, I replaced 10 scouts with 5 scouts. Eventually, I got a 5x5 matrix.
5 scouts

When comparing the results of these two operations on the same subject and same frequency band, I found that the PTE value between scout A & B is slightly different. For example:
output10

output5

I tried several times, but always came to the same conclusion.

Have I described my problem clearly? What is the reason behind this?

Duan
Best

Indeed, I could reproduce this behavior, with only one file, and 2 or 3 scouts, independently from any other options in the process. The function PhaseTE_MF behaves differently for 2 or 3 signals.

Examples at line 577 in bst_connectivity:
[dPTE, PTE] = PhaseTE_MF(permute(DataAband, [2 1]));

Two examples for DataAband (for the second figure, the 3rd signal was removed):
image image

PTE1 = 
         0    0.2320    0.1752
    0.1587         0    0.1992
    0.5978    0.5174         0

PTE2 =
         0    0.1394
    0.2450         0

@MartinC @hossein27en @Marc.Lalancette @Sylvain
Is this expected?

Dear all,

Thanks for Francois's prompt responses. This is not an urgent issue, but it has been bothering me for quite a long time and I am really looking forward to your early reply. Thank you very much.

Best,
Duan

@duanjipeng
I checked the function and the paper it refers to.

I guess the paper just talks about a bivariate case but some part of the code when it wants to find the "delay?" for each channel, it checks the "phase" with all other channels, so when you have more channels somehow that changes. I'm not very familiar with PTE but that's where the difference happens. So we need to see whether PTE is a multivariate metric or not.

Dear Francois

I would like to know in your example the row of the PTE table are which colors( which signals) ?

My question is about that in PTE results are from ROIs to ROIs or vise versa ?

I don't remember, this is the typical order of colors in Matlab when displaying multiple lines.
This is a result you can easily reproduce with extracting 2 or 3 scouts from any source file. Which is what you've done in your example.

The question of importance is the one @hossein27en asked:
is this a bivariate or a multivariate metric?
=> @MartinC and @Sylvain are the authors of this method, it would be nice to hear from them.

@Samiee might be able to help us as well?

I asked this issue from Arjan Hillebrand , whose code is used in Brainstorm for measuring PTE.

His answer is

PTE is a bivariate measure.

A single delay is computed across time and channels. So if you change the number of included channels, the delay may change.

This explains why results may vary when changing the number of channels.

All the best,

Arjan

2 Likes

Thank you all for your help and efforts on this.

Sorry, I have just seen the topic. Happy that it is solved! :slight_smile: