BUG: what should we do about illegal operations on mixed frames?

[jreback]

so min across the columns is clearly non-sensical,
what should we do about this when an op crosses dtype boundaries and is wrong ?
(this is harder than it looks, because you can't always just get the numeric data,
a frame with only say timedelta64[ns] is ok)

maybe have a raise_on_error parameter to min? (default of True)?
(if its mixed (and not all numeric)) types?

(Pdb) mixed
                 A                 B    C  D  E
0         00:05:05 -1 days, 00:00:00  foo  1  1
1 1 days, 00:05:05 -1 days, 00:00:00  foo  1  1
2 2 days, 00:05:05 -1 days, 00:00:00  foo  1  1
(Pdb) mixed.min()
A            0:05:05
B    -1 day, 0:00:00
C                foo
D                  1
E                  1
Dtype: object
(Pdb) mixed.min(axis=1)
0   -8.640000e+13
1   -8.640000e+13
2   -8.640000e+13
Dtype: float64
(Pdb) mixed.dtypes
A    timedelta64[ns]
B    timedelta64[ns]
C             object
D              int64
E            float64
Dtype: object

[jreback]

and .... what about misbehaving operations (by numpy) in general?

e.g. argmin/max on timedelta64 see #2948
idxmin/max work, but should we give an error on the invalid numpy func?

[ghost]

1.6.2 was released last may, it's terrible that distros (ubuntu) don't update on minor releases.
Document in gotchas, and recommend users upgrade. Inserting numpy version checks is a slippery slope.

would hard-coding the astype() call be feasible? perhaps no perf hit, if numpy does it anyway further
down the call stack.

[jreback]

where are you suggesting we astype?

[ghost]

in the Series methods that delegate to numpy.

[jreback]

I put in a fix for this (to cover abs), PR #2958

problem is don't want to have to check types on the return ops from numpy, so sort of tabling the general issue
(I think once series DOES not inherit from numpy then this can be handled in a better way)

@wesm what do you think?

[jreback]

#3550 partially solves this as will raise a TypeError on invalid datetime/timedelta ops