MathGroup Archive 2007

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: Re: problem with Pick

  • To: mathgroup at
  • Subject: [mg78249] Re: [mg78222] Re: [mg78194] problem with Pick
  • From: Andrzej Kozlowski <akoz at>
  • Date: Wed, 27 Jun 2007 05:18:26 -0400 (EDT)
  • References: <> <> <>

On 26 Jun 2007, at 21:18, Andrzej Kozlowski wrote:

> *This message was transferred with a trial version of CommuniGate 
> (tm) Pro*
> On 26 Jun 2007, at 17:30, Chris Chiasson wrote:
>> On 6/25/07, Oyvind Tafjord <tafjord at> wrote:
>>> Chris Chiasson wrote:
>>>> On 6/25/07, Oyvind Tafjord <tafjord at> wrote:
>>>>> In this case, sel={{},{1}}. sel[[]] matches patt, and so list 
>>>>> [[]] is
>>>>> picked out.
>>>>> This behavior, in which all of list gets picked, does produce a  
>>>>> fair
>>>>> amount
>>>>> of confusion, unfortunately. It often shows up in connection  
>>>>> with Except:
>>>>> In[1]:= Pick[{a, b, c}, {1, 2, 3}, Except[2]]
>>>>> Out[1]= {a, b, c}
>>>>> In[2]:= Pick[{a, b, c}, {1, 2, 3}, Except[2, _Integer]]
>>>>> Out[2]= {a, c}
>>>> Thank you for the reply.
>>>> You seem to be implying that the above behavior is intended, even
>>>> though it violates the documentation. I believe it is  
>>>> unintended, due
>>>> to the following output, which seems to indicate that the  
>>>> matches are
>>>> supposed to be checked on the first level:
>>>> In[1]:= Pick[{a,b,c},SparseArray@{1,2,3},Except[2]]
>>>> Pick[{a,b,c},{1,2,3},Except[2]]
>>>> Out[1]= {a,c}
>>>> Out[2]= {a,b,c}
>>>> If I am wrong, then this SparseArray behavior is a bug, the
>>>> documentation is wrong, and I suggest that an optional level  
>>>> argument
>>>> be added to Pick.
>>> In what way does this behavior violate the documentation? It uses  
>>> the
>>> statement you quoted:
>>> Pick[list,sel,patt] picks out those list[[i1,i2,...]] for which
>>> sel[[i1,i2,...]] matches patt.
>>> with the 0-length version of i1,i2,... I agree this is often what  
>>> you don't
>>> want though.
>>> The SparseArray case is treated differently, in this case only the
>>> individual elements are treated as "selectors", for optimization and
>>> usefulness. This could be explained better in the documentation.
>> Again, thank you for the reply.
>> You're trying to have it one way for SparseArray and another way for
>> lists, which makes no sense given the definition of Pick in the
>> documentation. Pick should either match sel's "0-length version of
>> i1,i2,..." or it should not*.
>> In[1]:= MatchQ[(SparseArray@{1,2,3})[[]],Except@2]
>> Out[1]= True
>> I'll bet it doesn't take much CPU time to test this, either. Do you
>> have an example where testing the entire SparseArray expression first
>> would be absolutely unacceptable? Even if you do, I'd use that as an
>> argument for Pick to work only on the first level of all expressions
>> so that it would be more consistent (and, therefore, ostensibly more
>> useful due to predictability).
>> I hope I have been persuasive and inoffensive in arguing for behavior
>> that is more consistent with the documentation.
>> *I recognize there are evaluation vs. pattern matching issues here,
>> but I think my reasoning is still germane.
>> -- 
>  It is not actually the case that in this respect we have  "one way  
> for SparseArray and another way for lists" because "the way for  
> lists" is in fact the way for most other selectors except  
> SparseArrays. For example, using an arbitrary head f, we have:
> Pick[{a, b}, f[2, 3], Except[2]]
> {a, b}
> which behaves the same way as List. The fact that SparseArray  
> behaves in a special way becoems clear if you examine its FullForm:
>  FullForm[SparseArray[{1, 2}]]
>  FullForm[SparseArray[Automatic, {2}, 0, {1, {{0, 2}, {{1}, {2}}},  
> {1, 2}}]]
> Normally, it is the FullForm of the expression that is used in Pick  
> (or for pattern matching) but of course it would be extremly  
> inconvenient if this were the case with SparseArrays.
> Actually, not only SparseArray but also other atomic expressions  
> are also treated in "special ways", for example:
> Pick[{a, b}, Complex[2, 3], 2]
> Sequence[]
> Pick[{a, b}, complex[2, 3], 2]
> {a}
> Note that List[a,b] is not an atom and there is no reason to treat  
> it in any way different from the way one treats an expression with  
> an arbitrary head f. On the other hand,
> AtomQ[SparseArray@{1, 2}]
> True
> and Atoms in Mathematica are generally treated in special ways as  
> far as pattern matching or Part extraction are concerned.
> Andrzej Kozlowski

At the risk of belaboring the obvious, I would like to point out that  
Pick also works with higher level arrays, thus:

Pick[{{a, b}, {c, d}}, {{True, False}, {False, True}}]

  {{a}, {d}}

and the same with Heads other than List but, of course, this will not  
work if you try to use SparseArray in the same way (based on its  
FullForm). I am just again restating what should now be obvious:  
SparseArrays are special and their treatment by Pick is not based on  
their FullForm - List are not special and in their case it is the  
FullForm that decides hwo they are treated by Pick.

Andrzej Kozlowski

  • Prev by Date: Re: Re: problem with Pick
  • Next by Date: Re: Re: problem with Pick
  • Previous by thread: Re: Re: problem with Pick
  • Next by thread: Re: Re: problem with Pick