On Tue, Jun 2, 2009 at 1:18 PM, William Dunlap <wdunlap@tibco.com> wrote:

> %in% is a thin wrapper on a call to match().


Yes, as I mentioned in my email, all this is clearly documented in ? match.


> match() is not a generic function (and is not documented to be one),
> so it treats data.frames as lists, as their underlying representation is a
> list of columns.


Yes, I understand that this is the proximal cause of the current strange
behavior.  What I don't understand is why the current behavior is a good
idea.


> match is documented to convert lists to character and to then run

the character version of match on that character data


Yes, this peculiar behavior is documented.  What I don't get is its
rationale.


> match does not bail out if the types of the x and table arguments don't
> match
> (that would be undesirable in the integer/numeric mismatch case).


Why would it 'bail out'?

The related functions, duplicated() and unique(), do have
> row-wise data.frame methods.  E.g.,
>   > duplicated(data.frame(x=c(1,2,2,3,3),y=letters[c(1,1,2,2,2)]))
>   [1] FALSE FALSE FALSE FALSE  TRUE
> Perhaps match() ought to have one also....
>

I think that %in% and is.element() ought to remain calls to match()
> and that if you want them to work row-wise on data.frames then
> match should get a data.frame method.


After all that, it sounds like we agree...!

         -s

	[[alternative HTML version deleted]]

