Mailing-List: contact dev-help@groovy.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@groovy.incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of blackdrag@gmx.org designates
 212.227.17.20 as permitted sender)
Message-ID: <55799CD0.4000705@gmx.org>
Date: Thu, 11 Jun 2015 16:36:00 +0200
From: Jochen Theodorou <blackdrag@gmx.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: dev@groovy.incubator.apache.org
Subject: Re: intersect() returns duplicate elements
References: 
 <CANBeYQRcS_5kbJunzYTkaouqrp-b5rWeoW_rpKEEmuG1VFCnug@mail.gmail.com>
 <CAL2qGUFJL7+NT6ZUGtAsGjyW2xy-iB1kAsWiDyCuvB364uZtgw@mail.gmail.com>
 <CAKrRyTAb2=Cut81ZVyHZW5uEAftGZz0t00xScbYMVMEbw=Ezqg@mail.gmail.com>
 <CAL2qGUFrJ4rEUbvY59QXnJfwhU7r8C2K2b+DQA=d=Gnq5FZdjw@mail.gmail.com>
 <CAL2qGUEJD-Qpp3rEgEdqv7BUCNVm1n0M0yc7nUM9iaUQv2y+Bw@mail.gmail.com>
 <5577C0DB.2080207@gmx.org>
 <CAL2qGUHSu3V3jJhgjE94ygrysHU3vfHfSx3ZHW-XocbmpN8dZw@mail.gmail.com>
 <5577E3D9.7050807@gmx.org>
 <CANBeYQSDJd55XH2+n=iKWn2VsWfbygpWfm0eXGao+hKpFrOQew@mail.gmail.com>
In-Reply-To: 
 <CANBeYQSDJd55XH2+n=iKWn2VsWfbygpWfm0eXGao+hKpFrOQew@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Am 11.06.2015 14:32, schrieb Peter Ledbrook:
>     If I define intersect like this:
>     A intersect B = C:
>     x element of A and x element of B is equivalent to x element of C
>
>     with A,B,C not being Sets, just similar, then I don't see why repetition
>     should not be allowed in the result. If somebody wants no repetition,
>     then he should use sets or unique.
>
>
> I have a different take on this. I think intersect() is by definition a
> set operation and the method on Iterable is simply a convenience that
> automatically converts the object and the arguments to sets. I would
> even argue for the result of the method always being a set as well.

If you argue like that I have to ask: Does it make sense to convert an 
Iterable to Set automatically? Wouldn't it be better to instead have it 
on Set only?

> Even if one doesn't agree with this definition, the current
> implementation is broken. Surely intersect() must be a commutative
> operation? And yet this code
>
>      def a = [1, 1, 2, 4]
>      def b = [1, 2, 2, 3]
>      a.intersect(b)
>
> produces a result of [1, 2, 2]. b.intersect(a) produces [1, 1, 2].

you are right: https://proofwiki.org/wiki/Intersection_is_Commutative

I tried using the history of the method to find out why it was added 
this way, but this code goes back to 2003, and I really never talked to 
the author of this method. I did see that the early version did use a 
TreeSet in some cases, but not in all cases.

I really wonder if we should keep the method on anything that is no 
Set... actually even with sets... If a non-standard comparator is used, 
problems like above will easily happen again.

My feeling is that this was added to Collection (now Iterable I know, 
but back then Collection), because there is no native construct for sets.

bye blackdrag

-- 
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/