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

Refactor behavior of dipy.sims.voxel.single_tensor vs SingleTensor #844

jchoude opened this issue Jan 22, 2016 · 0 comments · Fixed by #1898


Copy link

commented Jan 22, 2016

Currently, SingleTensor is aliased to single_tensor. Following discussions on Gitter, the behavior should be aligned with what is done in dipy.reconst and with gradient_table versus GradientTable.

single_tensor should stay a function to operate on small data, whereas SingleTensor should become a class that is able to deal with large datasets.

The following are the important parts of the discussion: (can't seem to find a way to link to the gitter discussion directly):


We still have 2 functions (dipy.sims.voxel.SingleTensor and dipy.sims.voxel.single_tensor), where SingleTensor just points to single_tensor? From the code, I see that it's to maintain backwards compatibility. Should we replace the last remaining calls to SingleTensor and move it to the Deprecation path?
Right now it might be confusing to a new user, since there are 2 functions to do the same thin gin the Doc.


+1 from me


Although the comment says that this is for backwards compatibility there is also another point. These simulations are still clearly expressed as functions. The proper object oriented approach is not available and it is something to think better if we want efficient simulations.
This is not the only place we have two ways of accessing different algorithms.


Hum ok... What do you suggest in this case? I just leave it like that for now?


Another place where something like that happened is with gradient_table and GradientTable . Those are a bit different in behaviour.


When Oscar from nipype used the sims module to do some full data simulations he noticed that with the current design we repeat a lot of things when in dipy.reconst we have a better design for dealing with big data.


Yes, I think we need to think a bit about this.
We may keep the functions for single voxels and change the classes to work with full data.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
2 participants
You can’t perform that action at this time.