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

*Bugfix and improvements to dimensionality estimation #150

Merged
merged 2 commits into from
Nov 11, 2019

Conversation

glasserm
Copy link
Contributor

This pull request improves the accuracy and stability of dimensionality estimation for MR+FIX and related code. In particular, the pca_dim.m function now aligns with the implementation in melodic, dimensionality is now estimated using the full set of normalized eigenvalues, rather than just the left most when using multiple Wishart distributions (i.e. the left most eigenvalues >1 are padded with ones to match the original number of eigenvalues), and when using multiple Wishart distributions a single overall Wishart distribution is fit to the estimated null eigenvalues for the purposes of the pca_dim.m estimation. Also, two new modes of convergence are now available for icaDim.m including -1, which converges when the incremental change in dimensionality estimate is less that 0.25, and numbers > 3, which just run the specified number of iterations and compute the average estimated dimensionality from this number.

@glasserm glasserm requested review from mharms and coalsont October 21, 2019 17:57
Copy link
Member

@coalsont coalsont left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't entirely follow things, and I wouldn't reuse the same internal variable for both an iterations count and a floating point threshold, but I guess as long as it works...

@@ -5,7 +5,17 @@
%Variables
Out.VNDIM=VN; %Variance Normalization Dimensionality initially set to 1
lnb = 0.5; %Lower noise bound for Golden Section Search
stabThresh = Iterate; %How many iterations meeting dimThresh criterion (1 for VNDIM=1 results, 2 for converged results)
stabThresh = Iterate; %How many iterations meeting dimThresh criterion (1 for VNDIM=1 results, 2 for legacy converged results, -1 for new converged results, >3 for fixed iterations)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be helpful if there was a brief explanation of all the inputs immediately following the function definition.

Copy link
Contributor

@mharms mharms left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also didn't try to follow all the details. It would be helpful if you could add to the PR a brief summary of the implication of the cumulative changes, along the lines of what you explained to me verbally, to capture that within the PR itself.

I would suggest not merging this quite yet though, until we are ready to re-compile the matlab to go along with the changes.

@glasserm
Copy link
Contributor Author

This needs to be merged so that a collaborator can use it. FIX with compiled matlab is currently unsupported by FIX anyway.

@glasserm glasserm merged commit 08978ab into master Nov 11, 2019
@mharms
Copy link
Contributor

mharms commented Nov 11, 2019

Well the FIX issue with compiled matlab should be resolved within a day or so, as Matthew and I now have a working version. We definitely don't want to tag a new HCPpipelines release until we have the matlab re-compiled that goes with this PR. (FWIW, your collaborator could have simply used your branch, thus avoiding the need to merge into the master before the matlab was re-compiled).

@glasserm
Copy link
Contributor Author

If we cannot support compiled matlab, we shouldn't support it. For example, I don't think we should use that in Qu|Nex container.

@coalsont
Copy link
Member

@glasserm what? You seem to be suggesting something pretty drastic. Outputs from compiled matlab should be the same as results from interpreted matlab, while octave might have some differences (someone mentioned differences in ill-conditioned matrix handling).

@glasserm
Copy link
Contributor Author

Well if we cannot keep the compiled matlab in sync with interpreted matlab/Octave, we shouldn't support it. We cannot have the interpreted code "locked in" by problems with keeping the compiled matlab code up to date.

@coalsont
Copy link
Member

coalsont commented Nov 11, 2019

As long someone with push access to the pipelines has the right version of matlab installed, they just have to run the compile script to update the compiled code (and new matlab files have to be added to the compile script when first created). Saying that we "can't" keep them in sync is wrong.

@glasserm
Copy link
Contributor Author

If it is that easy, then it shouldn't hold up this pull request.

@mharms
Copy link
Contributor

mharms commented Nov 11, 2019

It should be relatively easy going forward once @junilc does it once (thanks to the compile scripts that TimB left behind). Right now the hold-up is trying to get a R2017b license. My main point was that your collaborator could have easily used the branch (rather than the master) for the time-being.
And, yes, @coalsont, I really think we want the Qu|Nex container to be using compiled matlab rather than Octave.

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

Successfully merging this pull request may close these issues.

3 participants