Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

large t value in tfce #41

Open
shz8012 opened this issue Nov 19, 2022 · 4 comments
Open

large t value in tfce #41

shz8012 opened this issue Nov 19, 2022 · 4 comments

Comments

@shz8012
Copy link

shz8012 commented Nov 19, 2022

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 I run up to line 1449 and get the statistic G, everything looks fine. However, you can find some G values (t-values) that are very large. The following figure shows the variable G:
    Snipaste_2022-11-19_17-06-45

  • When I continue to run to line 1579, which is the "Convert to z-score", something seems to go wrong. Those large G values are converted to inf. The following figure shows the variable G after conversion:Snipaste_2022-11-19_17-12-19

  • I suspect that the function palm may not work well when G is particularly large. Then I thought of a similar function spm_t2z in spm, so I used spm_t2z to get the z value, and the result looks good. The following figure is the result after using spm_t2z conversion, using tol is 10*10-15: Snipaste_2022-11-19_17-46-54

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
Copy link
Owner

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
Copy link

davidmwatson commented Feb 20, 2023

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
Copy link
Owner

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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants