BUG: rolling count on string Series and TimeIndex raises an error

[ezerkar]

• I have checked that this issue has not already been reported.

• I have confirmed this bug exists on the latest version of pandas.

• (optional) I have confirmed this bug exists on the master branch of pandas.

Code Sample, a copy-pastable example

d = {'vv': {pd.Timestamp('2020-01-13 08:22:00', freq='T'): 'aa',
  pd.Timestamp('2020-01-13 08:23:00', freq='T'): 'bb',
  pd.Timestamp('2020-01-13 08:24:00', freq='T'): 'cc',
  pd.Timestamp('2020-01-13 08:25:00', freq='T'): np.nan,
  pd.Timestamp('2020-01-13 08:26:00', freq='T'): 'dd'}}

df = pd.DataFrame(d)

print(df['vv'].rolling('72s').count())

Problem description

this raises DataError: No numeric types to aggregate insted if the expected output:

2020-01-13 08:22:00    1.0
2020-01-13 08:23:00    2.0
2020-01-13 08:24:00    2.0
2020-01-13 08:25:00    1.0
2020-01-13 08:26:00    1.0
Name: vv, dtype: float64

Output of pd.show_versions()

INSTALLED VERSIONS

commit : d9fff27
python : 3.8.5.final.0
python-bits : 64
OS : Windows
OS-release : 10
Version : 10.0.16299
machine : AMD64
processor : Intel64 Family 6 Model 78 Stepping 3, GenuineIntel
byteorder : little
LC_ALL : None
LANG : None
LOCALE : English_United States.1252

pandas : 1.1.0
numpy : 1.19.1
pytz : 2020.1
dateutil : 2.8.1
pip : 20.2.1
setuptools : 49.2.1.post20200807
Cython : 0.29.21
pytest : 6.0.1
hypothesis : None
sphinx : 3.2.0
blosc : None
feather : None
xlsxwriter : 1.2.9
lxml.etree : 4.5.2
html5lib : 1.1
pymysql : None
psycopg2 : None
jinja2 : 2.11.2
IPython : 7.16.1
pandas_datareader: None
bs4 : 4.9.1
bottleneck : 1.3.2
fsspec : 0.7.4
fastparquet : None
gcsfs : None
matplotlib : 3.2.2
numexpr : 2.7.1
odfpy : None
openpyxl : 3.0.4
pandas_gbq : None
pyarrow : None
pytables : None
pyxlsb : None
s3fs : None
scipy : 1.5.0
sqlalchemy : 1.3.18
tables : 3.6.1
tabulate : None
xarray : None
xlrd : 1.2.0
xlwt : 1.3.0
numba : 0.50.1

[jreback]

this is a duplicate issue - pls have a look

window functions are not defined on non numerics

they could be but it's not implemented

[rhshadrach]

Closing as a duplicate of #23002

[ezerkar]

thanks, sorry for the hassle