Skip to content

dirorder: Exhaustive search#1800

Merged
jdtournier merged 3 commits intodevfrom
dirorder_exhaustive
Nov 20, 2019
Merged

dirorder: Exhaustive search#1800
jdtournier merged 3 commits intodevfrom
dirorder_exhaustive

Conversation

@Lestropie
Copy link
Member

Encountered this internal limitation while writing a script for generating acquisition schemes. Details in 3593415.

Execution is still way faster than other related commands, so that's no issue.

Also considered altering the optimisation of order by calculating the SH condition numbers for prospective addition of individual remaining directions; but undecided as to whether or not it's worth the effort yet.

Rather than randomly selecting the first direction and then determining the best order of the remaining directions, derive the optimal order separately for every possible choice of first direction, and then select the ordering for which the overall truncation data conditioning is best (assessed as the sum of SH transform condition numbers for all possible truncation lengths).
@Lestropie Lestropie requested a review from jdtournier November 11, 2019 01:02
@Lestropie Lestropie self-assigned this Nov 11, 2019
@jdtournier
Copy link
Member

I don't see any problem with your proposal, but I'm just trying to get my head around the motivation for it. Can I just check what the 'internal limitation' was exactly? I'm struggling to see how this would have a massive impact on the quality of the scheme. Sure, it might give slightly better looking values for the cost function, but then the cost function is itself relatively arbitrary, and since we're talking about relatively random circumstances that will likely also imply serious issues with the quality of the data that has been acquired, I'm not sure what the problem was that you needed to complement this with an exhaustive search...

Maybe it's the randomness of the first volume that's the issue? I can see that with your proposal, the output is at least deterministic.

@Lestropie
Copy link
Member Author

"Internal limitation" was in reference to dirorder using a random first volume, not anything external to such. Can be a pretty decent variation in SH condition number upon truncation depending on which volume is selected as the first. If data quality upon truncation were to be too serious to warrant concern, then dirorder would lose its purpose; if it's going to exist & be used, might as well get it right.

@jdtournier
Copy link
Member

OK, all makes sense. Must admit I haven't looked into how much variation there is based on first volume, so if it's substantial, that makes sense. 👍

If data quality upon truncation were to be too serious to warrant concern, then dirorder would lose its purpose; if it's going to exist & be used, might as well get it right.

Agree on the principle, but in my opinion this is a case of making sure it's good enough, given the range of likely associated issues. But I guess that's irrelevant if it's cheap to get it right anyway, which given your changes, seems to be case...

@jdtournier jdtournier merged commit f495851 into dev Nov 20, 2019
@jdtournier jdtournier deleted the dirorder_exhaustive branch November 20, 2019 13:00
Lestropie added a commit that referenced this pull request Feb 2, 2021
Downstream of #1800, which introduced the functionality of determining the optimal reordering of directions for all possible selections of first volume, and choosing the optimal reordering from that set. Algorithm produces a segmentation fault if fewer than six input directions. This change forces the first volume in the input to be the first volume in the output in such scenarios (as there is no objective criterion by which to determine which direction is best to use first in this scenario).
@Lestropie Lestropie mentioned this pull request Feb 2, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants