Failing test on win/py2.6/64, TestResample:test_how_lambda_functions

This has failed intermittently a couple of times in the last week or two.

=============================================================
=======================
FAILURE: test_how_lambda_functions (pandas.tseries.tests.test_resample.TestResample)
------------------------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\Python27-AMD64\Lib\unittest\case.py", line 331, in run
    testMethod()
  File "C:\workspace\pandas_tests\BITS\64\PYTHONVER\27\pandas\tseries\tests\test_resample.py", line 640, in test_how_lambda_functions
    tm.assert_series_equal(result['bar'], bar_exp)
  File "C:\workspace\pandas_tests\BITS\64\PYTHONVER\27\pandas\util\testing.py", line 448, in assert_series_equal
    assert_almost_equal(left.values, right.values, check_less_precise)
  File "testing.pyx", line 58, in pandas._testing.assert_almost_equal (pandas\src\testing.c:2561)
  File "testing.pyx", line 93, in pandas._testing.assert_almost_equal (pandas\src\testing.c:1803)
  File "testing.pyx", line 107, in pandas._testing.assert_almost_equal (pandas\src\testing.c:2023)
AssertionError: First object is not null, second is null: inf != nan

[jreback]

I'll have. look tomorrow

@jreback , I've been chasing this down, I think it's an actual bug.
So far i've only seen it on windows, on py2.6.6/64 bit, with numpy 1.8.0.
I was able to reproduce and capture a pickle of the data that causes the problem.
I don't have python2.6 on this linux box, but the problem doesn't appear
on 2.7 with the same numpy.

I can't inline the float64 data because the repr roundtrip changes the data,
presumably roundoff. I'll mail you the pickle.

Reproduce:

import pandas as pd
from pandas import *
ts = pd.read_pickle('GH6136.pickle')
# on win/py2.6.6 np1.8.0 vs linux/py2.7.5 np1.8.0
print ts.resample('M', how={'bar': lambda x: x.std(ddof=1)})
# similarly, on linux above and below produce the same result
# on window/... they are different see below. That's the cause
# of the failing test
ts.resample('M', how='std')

INSTALLED VERSIONS
------------------
commit: 1775ba10518d7026bde95d9d77a1aab52f025033
python: 2.6.6.final.0
python-bits: 64
OS: Windows
OS-release: 7
Cython: 0.19.2

numpy: 1.8.0
bottleneck: None
numexpr: None

gives

In [71]: ts.resample('M', how={'bar': lambda x: x.std(ddof=1)})
Out[71]:
                 bar
2000-01-31  0.896238
2000-02-29  0.944715
2000-03-31  1.149277
2000-04-30    1.#INF

[4 rows x 1 columns]

In [72]: ts.resample('M', how='std')
Out[72]:
2000-01-31    0.896238
2000-02-29    0.944715
2000-03-31    1.149277
2000-04-30         NaN
Freq: M, dtype: float64

In [73]: np.version.git_revision
Out[73]: 'a60b3901cd635d28bef8328e83bafd35ce631e08'

while

INSTALLED VERSIONS
------------------
commit: b20fc1540c51ad4d69ac7b71c8d53ee696c52a57
python: 2.7.5.final.0
python-bits: 64
OS: Linux

numpy: 1.8.0
bottleneck: None
numexpr: None

gives

In [24]: ts.resample('M', how={'bar': lambda x: x.std(ddof=1)})
Out[24]: 
                 bar
2000-01-31  0.896238
2000-02-29  0.944715
2000-03-31  1.149277
2000-04-30       NaN

[4 rows x 1 columns]
In [25]: 
In [
In [25]: ts.resample('M', how='std')
Out[25]: 
2000-01-31    0.896238
2000-02-29    0.944715
2000-03-31    1.149277
2000-04-30         NaN
Freq: M, dtype: float64

>>> np.version.git_revision
'a60b3901cd635d28bef8328e83bafd35ce631e08'

moved to 0.13.1, push to 0.14 if we must.

Damn, we're doing that mindread thing again.

[jreback]

detailed!

I have. py2.6 64 windows so I can try to reproduce