You worry too much :-)

I don't see what the advantage is in what you are specifying. Do
"light-weight" objects actually have a substantially smaller memory
signature? Better performance? If not, then the only reason to want objects
to be light weight seems like an aesthetic preference.

But if I understand your proposal - I think that's not good. In particular,
sometimes you might have an array of evals and no gtab to go with it (for
example, if you are ). I don't want to be stuck having to create the object
with its particular components, when all I want to do (for example) is to
compute the mode of a tensor that looks like this:
`[[1,0,0],[0,0,0],[0,0,0]]` or the linearity of a set of evals that looks
like this: `[1,0,0]`, to give a silly example.

And to answer your question: yes - we would implement methods that we find
potentially useful. As I am seeing myself in my work these days,
interpreting the tensor can be tricky. In particular, the commonly used FA
can change for a variety of reasons. These stats all help disentangle these
different reasons.




On Sun, Apr 14, 2013 at 11:01 AM, Stefan van der Walt <
notifications@github.com> wrote:

> In dipy/reconst/dti.py:
>
> > @@ -619,6 +730,85 @@ def trace(self):
> >          """
> >          return trace(self.evals)
> >
> > +
> > +    @auto_attr
>
> What I'm always worried about is: where do we stop? What if another paper
> comes out with some cool attribute to measure of a Tensor? Do we just add
> all those methods in? I guess my preference is for light-weight objects
> that contain the bare minimum, and for operations to happen on them. E.g.,
> can't we have an array of Tensor objects, and have the utility operate on
> that?
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/nipy/dipy/pull/170/files#r3786314>
> .
>