TimeArray .prod is borked (because of overflow?)

[arokem]

a = ts.TimeArray([-1, 1.5,2,3])

a.prod()
Out[69]: -8739516.551889159 s

[arokem]

And:

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

[ivanov]

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.

[ivanov]

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

[ivanov]

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

[ivanov]

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

[ivanov]

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))

[arokem]

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.

[arokem]

This is resolved in:

dcd6bc2