isin doesn't work for Timestamps

[cpcloud]

SO question: http://stackoverflow.com/q/19070194/564538

[dsm054]

This just came up again: http://stackoverflow.com/questions/19551336/using-isin-with

Options:

(1) Raise. Irritating but no one will get the wrong answer.

(2) Detect common cases like timestamps which don't place nicely with hashes and do list membership testing instead of set membership testing. Slow for big collections but it'll give the right answer, and probably work well enough in the typical case of a small group.

(2b) Instead of list membership testing, sort and then bisect if the to-be-tested collection is big enough.

(3) Make sure that standard time objects have compatible hashes.

[jreback]

@dsm054 thanks for the ping on this.....pretty easy to fix actually....just need to convert to i8 for date/time like inputs and it works with the existing methods

[dsm054]

Does that preserve precision? When I ran the idea of coercing to a common type past @cpcloud, he seemed sceptical.

[jreback]

yep....this is what we do with date/time-likes....the in64's are in nanoseconds

[jreback]

it doesn't use the __hash__ of the actual objects, rather the hashes of the integers which back the date/time-like (which prob hash to themselves)

[jreback]

@dsm054 do you have any more tests that you think I ought to include?

[cpcloud]

Do python datetimes hash to their integer value? The ts class does use the object hash if there are no nanoseconds which I would assume constitutes the majority of use cases.

[jreback]

it doesn't matter in this case, as everything hashes as the value which is the num of nanoseconds in epoch space

[cpcloud]

Ah ok nice

[cpcloud]

right I saw ur pr. Just convert to int b4 hand

[cpcloud]

Maybe test that an ndarray and series as an arg to isin return the same result

[cpcloud]

Ndarray with datetime64 style that is

[cpcloud]

Dtype I meant

[jreback]

ok...sure