issue moving from 0.3.0 to v0.4.0

[dlovell]

0.4.0 seems to use np.add.reduceat() where 0.3.0 doesn't which is causing issues with some code I run during the evaluation of the beta in a PanelOLS. In particular, during the evaluation of self._y_trans.count() in _time_obs_count() there is a seg fault.

I'm not familiar with the internals of numpy or pandas but it looks like 0.4.0 passes in a zero length array for the output. The debugger won't go into the np.add.reduceat() code but it segfaults as soon as I make the next step

python -m pdb valModel1.py
b /usr/local/lib/python2.7/site-packages/pandas/core/series.py:505

/usr/local/lib/python2.7/site-packages/pandas/core/series.py(505)_count_level()
-> np.add.reduceat(mask, locs[start:end], out=out)
(Pdb) np.shape(mask)
(0,)
(Pdb) np.shape(locs)
(271,)
(Pdb) np.shape(out)
(0,)

And then seg faults

Its possible this is an underlying numpy issue but everything works fine on the same system with 0.3.0.

If this is of interest to you I can give you more info.

I'm running Freebsd 8.1 with the following packages and pandas compiled from a git pull

python27-2.7.1_1
cython-0.14.1
py27-numpy-1.5.1,1
py27-matplotlib-1.0.1
py27-scipy-0.8.0_1
py27-dateutil-1.5
py27-setuptools-0.6c11_1
py27-nose-1.0.0
py27-pytz-2011c

Best
Dan

[wesm]

Hm, reduceat segfaulting on malformed input is not good. I should probably rewrite it to not use reduceat now that I have hierarchical indexing functions.

Would you mind sending me the inputs to the ols function over e-mail (wesmckinn (at) gmail) so I can debug further? I'm going to put out a bugfix release of pandas within the next week so I'll make sure this gets fixed

[wesm]

Sorry, to do this, step up to the top level and either use cPickle directly or call .save(path) on each of the objects that you're passing in and send me those files

[wesm]

I fixed the underlying bug. Thanks for reporting-- will go into the 0.4.1 bugfix release soon. Feel free to install from GitHub with the fix