[Rd] suggestion for "sets" tools upgrade

Carl Witthoft carl at witthoft.com
Fri Feb 7 22:11:24 CET 2014

Thanks to Duncan and all who responded.

I agree that the algebraic set rules do not allow for indistinguishable 
elements;  I must have been deeply immersed in quantum fermions when I 
wrote "strictly" rather than "less" in front of "algebraic style.

I'll clean up my code (so that intersect() remains symmetric, among 
other things) , and submit as a separate package to CRAN.


On 2/7/14 7:37 AM, Duncan Murdoch wrote:
> On 14-02-06 8:31 PM, Carl Witthoft wrote:

>> My idea is to provide an upgrade to all the "sets" tools (intersect,
>> union, setdiff, setequal) that allows the user to apply them in a
>> strictly algebraic style.
>> The current tools, as well documented, remove duplicate values in the
>> input vectors.  This can be helpful in stats work, but is inconsistent
>> with the mathematical concept of sets and set measure.
> I understand what you are asking for, but I think this justification for
> it is just wrong.  Sets don't have duplicated elements:  an element is
> in a set, or it is not.  It can't be in the set more than once.
> What I propose
>> is that all these functions be given an additional argument with a
>> default value:  "multiple=FALSE" .  When called this way, the functions
>> remain as at present.  When called with "multiple=TRUE,"  they treat the
>> input vectors as true 'sets' of elements.

>> Here's an example of the new code:
>> intersect<-function (x, y,multiple=FALSE)
>> {
>>       y <- as.vector(y)
>>     trueint <- y[match(as.vector(x), y, 0L)]
>>       if(!multiple) trueint <- unique(trueint)
>>     return(trueint)
>> }
> This is not symmetric.  I'd like intersect(x,y,TRUE) to be the same as
> intersect(y,x,TRUE), up to re-ordering.  That's not true of your function:
>  > x <- c(1,1,2,3)
>  > y <- c(1,1,1,4)
>  > intersect(x,y,multiple=TRUE)
> [1] 1 1
>  > intersect(y,x,multiple=TRUE)
> [1] 1 1 1
> I'd suggest that you clearly define what you mean by your functions, and
> put them in a package, along with examples where they give more useful
> results than the standard definitions.  I think the current base package
> functions match the mathematical definitions better.
> Duncan Murdoch


Sent from a parallel universe almost, but not entirely,
nothing at all like this one.

More information about the R-devel mailing list