Hi, I want to extract elements of an array (say, a) that are contained in
another array (say, b). That is, if a=array([1,1,2,3,3,4]), b=array([1,4]),
then I want array([1,1,4]).
I did the following but the speed is very slow (maybe because a is very
long):
c=array([])
for x in b:
c=append(c,a[
On Wed, Jun 3, 2009 at 8:29 PM, Ning Sean wrote:
> Hi, I want to extract elements of an array (say, a) that are contained in
> another array (say, b). That is, if a=array([1,1,2,3,3,4]), b=array([1,4]),
> then I want array([1,1,4]).
>
> I did the following but the speed is very slow (maybe because
Thanks! Tried it and it is about twice as fast as my approach.
-Ning
On Wed, Jun 3, 2009 at 7:45 PM, wrote:
> On Wed, Jun 3, 2009 at 8:29 PM, Ning Sean wrote:
> > Hi, I want to extract elements of an array (say, a) that are contained in
> > another array (say, b). That is, if a=array([1,1,2,3,
a[(a==b[:,None]).sum(axis=0,dtype=bool)]
hth,
Alan Isaac
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Thu, Jun 4, 2009 at 8:23 AM, Alan G Isaac wrote:
> a[(a==b[:,None]).sum(axis=0,dtype=bool)]
this is my preferred way when b is small and has unique elements.
if the elements in b are not unique, then be can be replaced by np.unique(b)
If b is large this creates a huge intermediate array
The a
> On Thu, Jun 4, 2009 at 8:23 AM, Alan G Isaac wrote:
>> a[(a==b[:,None]).sum(axis=0,dtype=bool)]
On 6/4/2009 8:35 AM josef.p...@gmail.com apparently wrote:
> If b is large this creates a huge intermediate array
True enough, but one could then use fromiter:
setb = set(b)
itr = (ai for ai in a
On Thu, Jun 4, 2009 at 10:13 AM, Alan G Isaac wrote:
>> On Thu, Jun 4, 2009 at 8:23 AM, Alan G Isaac wrote:
>>> a[(a==b[:,None]).sum(axis=0,dtype=bool)]
>
>
> On 6/4/2009 8:35 AM josef.p...@gmail.com apparently wrote:
>> If b is large this creates a huge intermediate array
>
>
> True enough, but
> On Thu, Jun 4, 2009 at 10:13 AM, Alan G Isaac wrote:
>> Or if a stable order is not important (I don't
>> recall if the OP specified), one could just
>> np.intersect1d(a, np.unique(b))
On 6/4/2009 10:50 AM josef.p...@gmail.com apparently wrote:
> This requires that also `a` has only unique elem
On Thu, Jun 4, 2009 at 11:12 AM, Alan G Isaac wrote:
>> On Thu, Jun 4, 2009 at 10:13 AM, Alan G Isaac wrote:
>>> Or if a stable order is not important (I don't
>>> recall if the OP specified), one could just
>>> np.intersect1d(a, np.unique(b))
>
> On 6/4/2009 10:50 AM josef.p...@gmail.com apparen
On 6/4/2009 10:50 AM josef.p...@gmail.com apparently wrote:
> intersect1d gives set intersection if both arrays have
> only unique elements (i.e. are sets). I thought the
> naming is pretty clear:
> intersect1d(a,b) set intersection if a and b with unique elements
> intersect1d_nu(a,b) set
Alan G Isaac wrote:
> On 6/4/2009 10:50 AM josef.p...@gmail.com apparently wrote:
>> intersect1d gives set intersection if both arrays have
>> only unique elements (i.e. are sets). I thought the
>> naming is pretty clear:
>
>> intersect1d(a,b) set intersection if a and b with unique elements
On Thu, Jun 4, 2009 at 11:19 AM, Alan G Isaac wrote:
> On 6/4/2009 10:50 AM josef.p...@gmail.com apparently wrote:
>> intersect1d gives set intersection if both arrays have
>> only unique elements (i.e. are sets). I thought the
>> naming is pretty clear:
>
>> intersect1d(a,b) set intersection i
On 6/4/2009 11:29 AM josef.p...@gmail.com apparently wrote:
> intersect1d is the intersection between sets (which are stored as
> arrays), just like in the mathematical definition the two sets only
> have unique elements
Hmmm. OK, I see you and Robert believe this.
But it does not match the do
On Thu, Jun 4, 2009 at 12:32 PM, Alan G Isaac wrote:
> On 6/4/2009 11:29 AM josef.p...@gmail.com apparently wrote:
>> intersect1d is the intersection between sets (which are stored as
>> arrays), just like in the mathematical definition the two sets only
>> have unique elements
>
> Hmmm. OK, I se
On 6/4/2009 1:27 PM josef.p...@gmail.com apparently wrote:
> Note: there are two versions of the docs for np.intersect1d, the
> currently published docs which describe the actual behavior (for the
> non-unique case), and the new docs on the doc editor
> http://docs.scipy.org/numpy/docs/numpy.lib.ar
On Thu, Jun 4, 2009 at 2:58 PM, Alan G Isaac wrote:
> On 6/4/2009 1:27 PM josef.p...@gmail.com apparently wrote:
>> Note: there are two versions of the docs for np.intersect1d, the
>> currently published docs which describe the actual behavior (for the
>> non-unique case), and the new docs on the
Concerning the name setmember1d_nu, I personally find it quite verbose
and not the name I would expect as a non-insider coming to numpy and
not knowing all the names of the more special hidden-away functions
and not being a python-wiz either.
I think ain(a,b) would be the name I had expected as an
On Thu, Jun 04, 2009 at 10:27:11PM +0200, Kim Hansen wrote:
> "in(b)" or "in_iterable(b)" method, such that you could do a.in(b)
> which would return a boolean array of the same shape as a with
> elements true if the equivalent a members were members in the iterable
> b.
That would really by what
2009/6/4 :
> intersect1d should throw a domain error if you give it arrays with
> non-unique elements, which is not done for speed reasons
It seems to me that this is the basic source of the problem. Perhaps
this can be addressed? I realize maintaining compatibility with the
current behaviour is
On Thu, Jun 4, 2009 at 4:30 PM, Gael Varoquaux
wrote:
> On Thu, Jun 04, 2009 at 10:27:11PM +0200, Kim Hansen wrote:
>> "in(b)" or "in_iterable(b)" method, such that you could do a.in(b)
>> which would return a boolean array of the same shape as a with
>> elements true if the equivalent a members w
On Thu, Jun 04, 2009 at 04:43:39PM -0400, josef.p...@gmail.com wrote:
> Just using "in" might promise more than it does, eg. it works only for
> one dimensional arrays, maybe "in1d". With "in",
Then 'in_1d'
> I found arraysetops because of unique1d, but I didn't figure out what
> the subpackage
On Thu, Jun 4, 2009 at 4:52 PM, Gael Varoquaux
wrote:
> On Thu, Jun 04, 2009 at 04:43:39PM -0400, josef.p...@gmail.com wrote:
>> Just using "in" might promise more than it does, eg. it works only for
>> one dimensional arrays, maybe "in1d". With "in",
>
> Then 'in_1d'
No, if the breaks in a name
josef.p...@gmail.com wrote:
> On Thu, Jun 4, 2009 at 2:58 PM, Alan G Isaac wrote:
>> On 6/4/2009 1:27 PM josef.p...@gmail.com apparently wrote:
>>> Note: there are two versions of the docs for np.intersect1d, the
>>> currently published docs which describe the actual behavior (for the
>>> non-uniq
Kim Hansen wrote:
> Concerning the name setmember1d_nu, I personally find it quite verbose
> and not the name I would expect as a non-insider coming to numpy and
> not knowing all the names of the more special hidden-away functions
> and not being a python-wiz either.
To explain the naming: those
Anne Archibald wrote:
> 2009/6/4 :
>
>> intersect1d should throw a domain error if you give it arrays with
>> non-unique elements, which is not done for speed reasons
>
> It seems to me that this is the basic source of the problem. Perhaps
> this can be addressed? I realize maintaining compatibi
josef.p...@gmail.com wrote:
> On Thu, Jun 4, 2009 at 4:30 PM, Gael Varoquaux
> wrote:
>> On Thu, Jun 04, 2009 at 10:27:11PM +0200, Kim Hansen wrote:
>>> "in(b)" or "in_iterable(b)" method, such that you could do a.in(b)
>>> which would return a boolean array of the same shape as a with
>>> element
On Fri, Jun 5, 2009 at 1:48 AM, Robert Cimrman wrote:
> josef.p...@gmail.com wrote:
>> On Thu, Jun 4, 2009 at 4:30 PM, Gael Varoquaux
>> wrote:
>>> On Thu, Jun 04, 2009 at 10:27:11PM +0200, Kim Hansen wrote:
"in(b)" or "in_iterable(b)" method, such that you could do a.in(b)
which would
josef.p...@gmail.com wrote:
> On Fri, Jun 5, 2009 at 1:48 AM, Robert Cimrman wrote:
>> josef.p...@gmail.com wrote:
>>> On Thu, Jun 4, 2009 at 4:30 PM, Gael Varoquaux
>>> wrote:
On Thu, Jun 04, 2009 at 10:27:11PM +0200, Kim Hansen wrote:
> "in(b)" or "in_iterable(b)" method, such that you
On 4-Jun-09, at 4:38 PM, Anne Archibald wrote:
> It seems to me that this is the basic source of the problem. Perhaps
> this can be addressed? I realize maintaining compatibility with the
> current behaviour is necessary, so how about a multistage deprecation:
>
> 1. add a keyword argument to inte
Robert Cimrman ntc.zcu.cz> writes:
> Anne Archibald wrote:
>
> > 1. add a keyword argument to intersect1d "assume_unique"; if it is not
> > present, check for uniqueness and emit a warning if not unique
> > 2. change the warning to an exception
> > Optionally:
> > 3. change the meaning of the fun
On Sat, Jun 6, 2009 at 4:42 AM, Neil Crighton wrote:
> Robert Cimrman ntc.zcu.cz> writes:
>
>> Anne Archibald wrote:
>>
>> > 1. add a keyword argument to intersect1d "assume_unique"; if it is not
>> > present, check for uniqueness and emit a warning if not unique
>> > 2. change the warning to an
Hi Josef,
thanks for the summary! I am responding below, later I will make an
enhancement ticket.
josef.p...@gmail.com wrote:
> On Sat, Jun 6, 2009 at 4:42 AM, Neil Crighton wrote:
>> Robert Cimrman ntc.zcu.cz> writes:
>>
>>> Anne Archibald wrote:
>>>
1. add a keyword argument to intersec
Robert Cimrman wrote:
> Hi Josef,
>
> thanks for the summary! I am responding below, later I will make an
> enhancement ticket.
Done, see http://projects.scipy.org/numpy/ticket/1133
r.
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http:/
33 matches
Mail list logo
