MathGroup Archive 2007

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

Search the Archive

Re: problem with Pick

  • To: mathgroup at
  • Subject: [mg78222] Re: [mg78194] problem with Pick
  • From: "Chris Chiasson" <chris at>
  • Date: Tue, 26 Jun 2007 04:30:42 -0400 (EDT)
  • References: <>

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.


  • Prev by Date: Re: Copy and cut is unable
  • Next by Date: Re: Copying input from the Wolfram blog
  • Previous by thread: Re: problem with Pick
  • Next by thread: Re: Re: problem with Pick