Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

datetime Series should raise on most numerical ops #3726

Closed
cpcloud opened this issue May 31, 2013 · 6 comments · Fixed by #3731
Closed

datetime Series should raise on most numerical ops #3726

cpcloud opened this issue May 31, 2013 · 6 comments · Fixed by #3731
Labels
API Design Dtype Conversions Unexpected or buggy dtype conversions
Milestone

Comments

@cpcloud
Copy link
Member

cpcloud commented May 31, 2013

obvs something like diff is fine, but i think sum/prod and most ufuncs should raise a TypeError maybe try the ops on the values attribute and if it doesn't raise continue

@jreback
Copy link
Contributor

jreback commented May 31, 2013

this is fixed for all numerical type ops, eg +, - etc (some make sense some don't)
you can prevent people from doing stupid things though

@cpcloud
Copy link
Member Author

cpcloud commented May 31, 2013

haha indeed. shouldn't other ufuncs raise though? i think it could be prevented since u know the dtype. maybe not for object arrays. + and friends raise but the corresponding reductions don't

@cpcloud
Copy link
Member Author

cpcloud commented May 31, 2013

there's an unconditional conversion to float64 in many ops in nanops.py. while practical for most purposes i think disallowing reduction ops on dates is the way to go. additionally probably good to only allow conversion to float if it's numeric and pass casting='safe' to astype, i.e., discourage the object dtype as much as possible.

@cpcloud
Copy link
Member Author

cpcloud commented May 31, 2013

this is a bit of an API change though, although currently there are no tests for summing over datetime64[ns] series/frames

@jreback
Copy link
Contributor

jreback commented May 31, 2013

This is ok for Frames, as they use _get_numeric_data, no dice for series though.....

In [1]: df = DataFrame(randn(10,2),columns=list('AB'))

In [2]: df['time'] = pd.date_range('20130101',periods=10)

In [3]: df
Out[3]: 
          A         B                time
0  0.655409 -2.119777 2013-01-01 00:00:00
1  0.326656 -0.208558 2013-01-02 00:00:00
2  0.284697  0.568025 2013-01-03 00:00:00
3  2.155815 -0.419372 2013-01-04 00:00:00
4  1.728936 -0.336092 2013-01-05 00:00:00
5  0.184181  0.642192 2013-01-06 00:00:00
6 -0.219383  0.794445 2013-01-07 00:00:00
7 -1.691735 -0.089012 2013-01-08 00:00:00
8 -1.388988 -1.407949 2013-01-09 00:00:00
9 -0.541974  1.472820 2013-01-10 00:00:00

In [4]: df.sum()
Out[4]: 
A    1.493613
B   -1.103279
dtype: float64

@cpcloud
Copy link
Member Author

cpcloud commented May 31, 2013

I should have this in by today. Should I start a new section in rls notes and a new what's new doc? You mentioned that there shouldn't be any more than doc prs until 11.1 is pushed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
API Design Dtype Conversions Unexpected or buggy dtype conversions
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants