Created
April 7, 2010 15:50
-
-
Save chrisgorgo/359040 to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Case 1 | |
| SubjectSource ->['4D.nii']->Spm.Realign->'4D.nii'->FSL.Smooth->'4D.nii' | |
| in contrast to: | |
| SubjectSource ->['4D.nii']->Spm.Realign->['4D.nii']->FSL.Smooth->'4D.nii' | |
| Case 2 | |
| SubjectSource ->['4D.nii']->Spm.Realign->'4D.nii'->SPM.Smooth->'4D.nii'->FSL.Bet | |
| even thou SPM.Smooth also accept lists | |
| in contrast to: | |
| SubjectSource ->['4D.nii']->Spm.Realign->['4D.nii']->SPM.Smooth->['4D.nii']->FSL.Bet |
internally for something like spm Realign, one would need to support (at the end of the day):
Any(List(List(File(exists=True, type='3d'))), List(File(exists=True, type=['3d','4d'])), File(exists=True, type='4d'))
the only addition here is the last one (for user simplicity).
alright. let's go with user simplicity for now and we'll see how things evolve. but this will require us to solve the multipath trait issue
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I don't agree this is a better way to do it from the user point of view. I understand it seams cleaner from our (developers) point of view, but iterfields/mapnode should be necessary only in cases of iterating over MULTIPLE values. This is just unnecessarily overcomplicated.
About exceptions user would get in the interactive mode. This would be just annoying - why would I need give a list if it will also work on single elements? What we need to do is to automatically generate traits constraints in the documentation so it would be clear for the user what to use.