Re: Re: problem with Pick

*To*: mathgroup at smc.vnet.net*Subject*: [mg78244] Re: [mg78222] Re: [mg78194] problem with Pick*From*: Andrzej Kozlowski <akoz at mimuw.edu.pl>*Date*: Wed, 27 Jun 2007 05:15:53 -0400 (EDT)*References*: <acbec1a40706230431p4f1db9a9i4320680dda027396@mail.gmail.com> <200706260830.EAA05573@smc.vnet.net>

On 26 Jun 2007, at 17:30, Chris Chiasson wrote: > On 6/25/07, Oyvind Tafjord <tafjord at wolfram.com> wrote: >> Chris Chiasson wrote: >>> On 6/25/07, Oyvind Tafjord <tafjord at wolfram.com> 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. > > -- > http://chris.chiasson.name/ > 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

**References**:**Re: problem with Pick***From:*"Chris Chiasson" <chris@chiasson.name>

**Re: Re: problem with Pick**

**Re: Maximize with Integer constraints**

**Re: Re: problem with Pick**

**Re: Re: problem with Pick**