TimeArray .prod is borked (because of overflow?) about nitime HOT 8 CLOSED

And:

a.var()
Out[72]: 2171875000000.0 s

from nitime.

Yea, I specifically didn't implement prod - since the units
will end up being seconds**(len(a)) - should we make it so this
function return a "Not implemented" error, or something like
that?

The same should probably apply to mul(self, val) when val is
another TimeArray.

from nitime.

var on the other hand should be fixed, i'll have a PR shortly

from nitime.

hmm, looks like it won't be so quick - it's a bit hairy - since my first stab at it makes us lose precision:

In [130]: a = nitime.timeseries.TimeArray([1,2,3]); a.var()
Out[130]: 0.66666666666700003 s

In [131]: b = np.array([1.,2.,3.]); b.var()
Out[131]: 0.66666666666666662966

where a.var is

def var(self, *args, **kwargs):
    tmp = np.array(self, np.float) / self._conversion_factor
    ret = TimeArray(tmp.var(*args,**kwargs), time_unit=self.time_unit)
    return ret

from nitime.

hmm, more info:

In [156]: (np.array(a, dtype=np.float)/a._conversion_factor).var()
Out[156]: 0.66666666666666662966

actually does what we want, but when we try to make it into a TimeArray, we get back

In [157]: nitime.timeseries.TimeArray((np.array(a, dtype=np.float)/a._conversion_factor).var(),time_unit='s')
Out[157]: 0.66666666666700003 s

so maybe the implementation i have is fine

from nitime.

more thinking, though, sorry for using this like a chat, a.var() would have units of s**2, so maybe we shouldn't implement it on the TimeArray, unless we want to dive further in to the units universe, (whereas a.std() is in seconds, so that's fine))

from nitime.

Good point about the units. I think that it would be OK to raise a NotImplementedError for cases in which we get 'strange' units, maybe even explicitly mentioning that the units would undergo strange mutations through this transformation. I don't really see an obvious use-case for prod or var anyway.

from nitime.

This is resolved in:

dcd6bc2

from nitime.