BF - callable response does not work #314
Conversation
for now so that it can be added back with tests and an example
|
Agreed. If someone wants this kind of functionality in the future, this will have to come back with a test! |
|
Just waiting for the travis-bot to be happy with this. |
BF - callable response does not work
| should return an ndarray with the all the signal values for the response function. The response | ||
| function will be used as deconvolution kernel ([1]_) | ||
| response : tuple | ||
| A tuple with two elements. The first is the eigen-values as an (3,) |
There was a problem hiding this comment.
Which eigen-values are these? And where should the signal be evaluated to give the response function?
There was a problem hiding this comment.
Is this a comment about the docstring, or about the procedure used?
On Tuesday, January 14, 2014, Stefan van der Walt wrote:
In dipy/reconst/csdeconv.py:
@@ -35,12 +35,12 @@ def init(self, gtab, response, reg_sphere=None, sh_order=8, lambda_=1, tau=0
Parameters
----------
gtab : GradientTable
response : tuple or callableIf tuple, then it should have two elements. The first is the eigen-values as an (3,) ndarrayand the second is the signal value for the response function without diffusion weighting.This is to be able to generate a single fiber synthetic signal. If callable then the functionshould return an ndarray with the all the signal values for the response function. The responsefunction will be used as deconvolution kernel ([1]_)response : tupleA tuple with two elements. The first is the eigen-values as an (3,)Which eigen-values are these? And where should the signal be evaluated to
give the response function?—
Reply to this email directly or view it on GitHubhttps://github.com//pull/314/files#r8861319
.
There was a problem hiding this comment.
It comes from the perspective of someone who doesn't know the functionality, but who would like to try to use this sometime (but wouldn't know how). I.e., I think the docstring can be clearer.
This has been brought up in #313 and #218. This PR fixes the documentation (and removes a few lines of superfluous code) so we don't confuse our users.
We should also add some way of using an empirical response function with the CSD Model. I still like the API suggested in #218, but this would mean breaking backwards comparability with the last release.