andersonwinkler / PALM

PALM: Permutation Analysis of Linear Models
69 stars 28 forks source link

large t value in tfce #41

Open shz8012 opened 1 year ago

shz8012 commented 1 year ago

HI. I am using PALM(alpha119) for group comparisons with surface-level fMRI data in MATLAB, and I want to get tfce-corrected results. Here is the code I used:

'palm 
-i /.../*.func.gii 
-s /*/*.L.midthickness_MSMAll.32k_fs_LR.surf.gii 
-d /.../designMatrix.mat 
-t /.../contrast.con 
-o tfce_test 
-n 100 -accel gamma 
-T  
-tfce2D
-C 3.29 -Cstat extent -twotail -saveuncorrected -savemask -saveparametric -savemax'

After running PALM with no errors reported, I found all the values in *_tstat_fwep_c1.gii were nan and the rest of the results look fine. Then I was ready to run the palm_core.m to find out what the problem was. Eventually I found that the t-value was so large that it could not be converted well to Z-value (actually converted to inf).

Here is how the problem was found:

When the value of t is small, there is little difference between the results of the two functions, but when the value of t is large, there is a large difference between the two functions. I suspect that the value of z is so large that these differences may not have an effect on the subsequent results.

Finally, I would like to ask what should be done about the large t-values?

Thank you.

andersonwinkler commented 1 year ago

Hi,

Thanks for the detailed input. This shouldn't happen, and in fact, in past tests, palm_gtoz was giving more accurate results than spm_t2z and the equivalent functionality in fslmaths. Are you using Octave by any chance? If so, which version?

Thanks!

Anderson

davidmwatson commented 1 year ago

I've been having a similar problem (large t-values get converted to Inf, which then breaks things like TFCE and cluster corrections). In my case, I think the problem was the test statistic being passed to the palm_gtoz.m function was being stored at single precision, which I presume was in turn because the data were being stored at single precision.

Editing the palm_gtoz.m function to include a forced conversion to double precision (i.e. placing G = double(G); at the top of the function) seemed to solve the problem for me. I'm not sure if this will have any unintended consequences elsewhere, but everything seemed to run okay for me after this. Presumably converting the data to double precision before calculating the test statistic would also work.

andersonwinkler commented 1 year ago

Thanks David.

PALM has an option "-precision" that can be used to force the precision to be single or double. I can't be sure this is the cause of the problem until I see a dataset in which the problem is happening. If you could share yours, please send me an email. My address is like my username here, at gmail.

Thanks!

Anderson

davidmwatson commented 1 year ago

Hi Anderson,

Thanks for that - it looks like using that flag to force double precision also fixes the problem for me. Sure, happy to share the data - I'll send it over later.

Thanks, David