Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

problem with Pick

32 views
Skip to first unread message

Chris Chiasson

unread,
Jun 25, 2007, 7:09:04 AM6/25/07
to
Step to reproduce:
1. Evaluate these two inputs with a fresh kernel:
Pick[{a,b},z[{},{1}],{__}]
Pick[{a,b},{{},{1}},{__}]

Expected results:
{b}
{b}

Actual results:
{b}
{a,b}

Relevant Documentation:
Pick[list,sel,patt] picks out those list[[i1,i2,...]] for which
sel[[i1,i2,...]] matches patt.

Relevant Evaluation:
In[3]:= MatchQ[{},{__}]
Out[3]= False

In[4]:= {Internal`$CreationID,$Version}
Out[4]= {853857,6.0 for Microsoft Windows (32-bit) (April 27, 2007)}

--
http://chris.chiasson.name/

Oyvind Tafjord

unread,
Jun 26, 2007, 4:11:10 AM6/26/07
to
Chris Chiasson wrote:
> Step to reproduce:
> 1. Evaluate these two inputs with a fresh kernel:
> Pick[{a,b},z[{},{1}],{__}]
> Pick[{a,b},{{},{1}},{__}]
>
> Expected results:
> {b}
> {b}
>
> Actual results:
> {b}
> {a,b}
>
> Relevant Documentation:
> Pick[list,sel,patt] picks out those list[[i1,i2,...]] for which
> sel[[i1,i2,...]] matches patt.

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}

Oyvind Tafjord
Wolfram Research

Michael Weyrauch

unread,
Jun 26, 2007, 4:27:09 AM6/26/07
to
Hello,

this may explain the different results:

In[9]:= MatchQ[{{}, {1}}, {__}]
Out[9]= True
In[10]:= MatchQ[z[{}, {1}], {__}]
Out[10]= False

Note, that not even list in Pick[list,sel, patt] must have Head List.

Regards Michael


"Chris Chiasson" <ch...@chiasson.name> schrieb im Newsbeitrag news:f5o7og$50i$1...@smc.vnet.net...

Chris Chiasson

unread,
Jun 26, 2007, 4:35:03 AM6/26/07
to
On 6/25/07, Oyvind Tafjord <taf...@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.

--
http://chris.chiasson.name/

Message has been deleted

Chris Chiasson

unread,
Jun 26, 2007, 4:37:07 AM6/26/07
to
On 6/25/07, Oyvind Tafjord <taf...@wolfram.com> wrote:
> 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/

Andrzej Kozlowski

unread,
Jun 26, 2007, 5:35:47 AM6/26/07
to

On 25 Jun 2007, at 20:06, Chris Chiasson wrote:

> Step to reproduce:
> 1. Evaluate these two inputs with a fresh kernel:
> Pick[{a,b},z[{},{1}],{__}]

> In[78]:= Pick[{a, b}, {{}, {1}}, {__Integer}]
> Out[78]= {b}


>
> Expected results:
> {b}
> {b}
>
> Actual results:
> {b}
> {a,b}
>
> Relevant Documentation:

> Pick[list,sel,patt] picks out those list[[i1,i2,...]] for which
> sel[[i1,i2,...]] matches patt.
>

> Relevant Evaluation:
> In[3]:= MatchQ[{},{__}]
> Out[3]= False
>
> In[4]:= {Internal`$CreationID,$Version}
> Out[4]= {853857,6.0 for Microsoft Windows (32-bit) (April 27, 2007)}
>
> --
> http://chris.chiasson.name/
>


But of course

MatchQ[{{}, {1}}, {__}]

True

In other words, there is a Match at the top level in exactly the same
way as here:

Pick[{a, b}, {}, {___}]
{a, b}


You can avoid the top level match, by using, for example,

Pick[{a, b}, {{}, {1}}, {__Integer}]
{b}

Andrzej Kozlowski

Chris Chiasson

unread,
Jun 26, 2007, 5:37:48 AM6/26/07
to
I agree 100% with your assessment of what is probably happening, but I
also note that this is in violation of Pick's documentation. I also
think Pick's present behavior in this situation neither is nor should
be intended.

On 6/25/07, Andrzej Kozlowski <ak...@mimuw.edu.pl> wrote:
> *This message was transferred with a trial version of CommuniGate(tm) Pro*


--
http://chris.chiasson.name/

Andrzej Kozlowski

unread,
Jun 27, 2007, 5:19:49 AM6/27/07
to

>> Pick[list,sel,patt] picks out those list[[i1,i2,...]] for which
>> sel[[i1,i2,...]] matches patt.
>>


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

Andrzej Kozlowski

unread,
Jun 27, 2007, 5:25:04 AM6/27/07
to

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

> *This message was transferred with a trial version of CommuniGate
> (tm) Pro*
>

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


Chris Chiasson

unread,
Jun 27, 2007, 5:26:06 AM6/27/07
to
On 6/26/07, Andrzej Kozlowski <ak...@mimuw.edu.pl> plays Devil's advocate (;-)):

> 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:

You have sufficiently demonstrated that, when used as the selector in
Pick, SparseArray is not matched at level zero like List and general
expressions of other heads. However, you haven't provided a reason why
the situation should be that way. Also, not to be pedantic, but

> It is not actually the case that in this respect we have "one way
> for SparseArray and another way for lists"

is false.

> 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.

I agree with these statements, but they are somewhat peripheral to
determining the intended behavior of Pick and making the documentation
consistent. It seems you are not actually taking a position, but are
illuminating certain concepts.


--
http://chris.chiasson.name/

Andrzej Kozlowski

unread,
Jun 27, 2007, 5:30:08 AM6/27/07
to


Well, I think the the behaviour of Pick is logically consistent and I
am sure it does what was intended. I am not sure that it is the
optimal behaviour: in fact I once suggested that a level
specification be added to Pick, see the last line of the post:

http://forums.wolfram.com/mathgroup/archive/2005/Dec/msg00221.html

and the reply by Oyvind Tafjord. My own current feeling is that
having a level secification in Pick would be less elegant and less
aesthetically satisfying than the present situation to a
"purist" (the kind of person who frowns on procedural constructs in
functional languages) but could be convenient in some situations.

Andrzej Kozlowski

Chris Chiasson

unread,
Jun 27, 2007, 5:32:10 AM6/27/07
to
Ok, I agree to disagree in that I think it would be more consistent as
I specified above, but I of course respect your and (assumedly)
Oyvind's view that things are better the way they are.

On 6/26/07, Andrzej Kozlowski <ak...@mimuw.edu.pl> wrote:
> *This message was transferred with a trial version of CommuniGate(tm) Pro*
>


--
http://chris.chiasson.name/

Oyvind Tafjord

unread,
Jun 27, 2007, 5:41:18 AM6/27/07
to
>> --http://chris.chiasson.name/

>
>
> Well, I think the the behaviour of Pick is logically consistent and I am
> sure it does what was intended. I am not sure that it is the optimal
> behaviour: in fact I once suggested that a level specification be added
> to Pick, see the last line of the post:
>
> http://forums.wolfram.com/mathgroup/archive/2005/Dec/msg00221.html
>
> and the reply by Oyvind Tafjord. My own current feeling is that having a
> level secification in Pick would be less elegant and less aesthetically
> satisfying than the present situation to a "purist" (the kind of person
> who frowns on procedural constructs in functional languages) but could
> be convenient in some situations.
>
> Andrzej Kozlowski
>

One option might be to add a 4th argument which is a level specification,
defaulting to Automatic (the present behavior). Of course, this wouldn't
alleviate confusion when used in its simple form.

As for the SparseArray behavior, I think Chris is trying to make the point
that a sparse array should behave the same as its Normal[...] version, which
is how sparse arrays usually are supported.

We made an exception in this case, for reasons of efficiency. Say, your
selector is a rank 3 sparse array, it would be inefficient to have to check
all the lower rank lists and matrices that might match, when that's almost
certainly not what you wanted. In some cases you can know that the pattern
cannot possible match something with head List, but in general you cannot.

As for having the default Pick have a level specification of 1, there is
much to be said for that, and given all the confusion that has arisen, that
might have been the more practical design. Although for the original
purposes where list and sel were supposed to have the same structure (say,
two matrices), this seems less elegant.

Oyvind Tafjord
Wolfram Research

Chris Chiasson

unread,
Jun 27, 2007, 5:44:35 AM6/27/07
to
On 6/26/07, Oyvind Tafjord <taf...@wolfram.com> wrote:
> One option might be to add a 4th argument which is a level specification,
> defaulting to Automatic (the present behavior). Of course, this wouldn't
> alleviate confusion when used in its simple form.

OOTH, a note about the level specification would alert users that
there is more than just a first-level operation going on by default
(kinda like Outer).

> As for the SparseArray behavior, I think Chris is trying to make the point
> that a sparse array should behave the same as its Normal[...] version, which
> is how sparse arrays usually are supported.

Yea. Mainly I just brought it in to show that the (lack of) level
specification handling wasn't described accurately enough in the
documentation (assuming no one wants to go with my idea of defaulting
to the first level).

> We made an exception in this case, for reasons of efficiency. Say, your
> selector is a rank 3 sparse array, it would be inefficient to have to check
> all the lower rank lists and matrices that might match, when that's almost
> certainly not what you wanted. In some cases you can know that the pattern
> cannot possible match something with head List, but in general you cannot.

Yes, that would be bad.

> As for having the default Pick have a level specification of 1, there is
> much to be said for that, and given all the confusion that has arisen, that
> might have been the more practical design. Although for the original
> purposes where list and sel were supposed to have the same structure (say,
> two matrices), this seems less elegant.

What about making the Automatic level specification always choose {1}
or greater if both list and sel are not atomic? If the user
specifically wants to test the whole expression, then it could be
specified manually? Would that break a lot of code? (It wouldn't break
any sparse matrix code, would it?)


--
http://chris.chiasson.name/

Andrzej Kozlowski

unread,
Jun 27, 2007, 5:55:52 AM6/27/07
to

> One option might be to add a 4th argument which is a level
> specification, defaulting to Automatic (the present behavior). Of
> course, this wouldn't alleviate confusion when used in its simple
> form.
>

> As for the SparseArray behavior, I think Chris is trying to make
> the point that a sparse array should behave the same as its Normal
> [...] version, which is how sparse arrays usually are supported.

There seem to be two opposite "philosophies' that one could based
this on. One is the above: SparseArray should be treated the same way
as Normal[SparseArray[....]], and this of indeed often what happens.
But one can equally well argue that since you can already use Normal
[SparseArray[]], you don't gain much by implementing Pick to treat
SparseArray in the same way - all this does is saves the user some
typing. By treating SparseArrays in a different way, you actually
create more functionality. I think I personally rather like this
latter approach (treating SparseArray and Normal[SparseArray[]]
differently), but of course if this is done it ought to be very
clearly documented, because it obviously not what one would
instinctively expect.

Andrzej Kozlowski

>
> We made an exception in this case, for reasons of efficiency. Say,
> your selector is a rank 3 sparse array, it would be inefficient to
> have to check all the lower rank lists and matrices that might
> match, when that's almost certainly not what you wanted. In some
> cases you can know that the pattern cannot possible match something
> with head List, but in general you cannot.
>

> As for having the default Pick have a level specification of 1,
> there is much to be said for that, and given all the confusion that
> has arisen, that might have been the more practical design.
> Although for the original purposes where list and sel were supposed
> to have the same structure (say, two matrices), this seems less
> elegant.
>

> Oyvind Tafjord
> Wolfram Research


Chris Chiasson

unread,
Jun 27, 2007, 6:03:01 AM6/27/07
to
On 6/26/07, Chris Chiasson <ch...@chiasson.name> wrote:
> On 6/26/07, Oyvind Tafjord <taf...@wolfram.com> wrote:
<snip/>

> > As for having the default Pick have a level specification of 1, there is
> > much to be said for that, and given all the confusion that has arisen, that
> > might have been the more practical design. Although for the original
> > purposes where list and sel were supposed to have the same structure (say,
> > two matrices), this seems less elegant.
>
> What about making the Automatic level specification always choose {1}
> or greater if both list and sel are not atomic? If the user
> specifically wants to test the whole expression, then it could be
> specified manually? Would that break a lot of code? (It wouldn't break
> any sparse matrix code, would it?)
>

Errata:
I forgot that SparseArray is Atomic as Andrzej mentioned. In the
suggestion above, I wasn't meaning to change the present (special)
behavior of SparseArray.

--
http://chris.chiasson.name/

DrMajorBob

unread,
Jun 28, 2007, 4:35:54 AM6/28/07
to
That's entirely contrary to the documentation, which says that Pick "picks
out those ELEMENTS of list for which the corresponding ELEMENT of sel is
True."

How is a list its own ELEMENT, if English words mean anything?

Bobby

On Tue, 26 Jun 2007 03:08:14 -0500, Oyvind Tafjord <taf...@wolfram.com>
wrote:

> Chris Chiasson wrote:
>> Step to reproduce:
>> 1. Evaluate these two inputs with a fresh kernel:
>> Pick[{a,b},z[{},{1}],{__}]

>> Pick[{a,b},{{},{1}},{__}]
>>

>> Expected results:
>> {b}
>> {b}
>>
>> Actual results:
>> {b}
>> {a,b}
>>
>> Relevant Documentation:

>> Pick[list,sel,patt] picks out those list[[i1,i2,...]] for which
>> sel[[i1,i2,...]] matches patt.
>

> 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}
>

> Oyvind Tafjord
> Wolfram Research


>
>>
>> Relevant Evaluation:
>> In[3]:= MatchQ[{},{__}]
>> Out[3]= False
>>
>> In[4]:= {Internal`$CreationID,$Version}
>> Out[4]= {853857,6.0 for Microsoft Windows (32-bit) (April 27, 2007) }
>>
>> --
>> http://chris.chiasson.name/
>
>
>

--
DrMaj...@bigfoot.com

DrMajorBob

unread,
Jun 28, 2007, 4:36:55 AM6/28/07
to
> This could be explained better in the documentation.

You think?

Bobby

On Tue, 26 Jun 2007 03:30:10 -0500, Oyvind Tafjord <taf...@wolfram.com>

wrote:

> Chris Chiasson wrote:
>> On 6/25/07, Oyvind Tafjord <taf...@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.
>

> E.g., compare
>
> In[20]:= Pick[{{a, b, c}, {d, e, f}},
> SparseArray@{{3, 4, 5}, {1, 2, 3}}, 4]
>
> Out[20]= {{b}, {}}
>
> In[21]:= Pick[{{a, b, c}, {d, e, f}},
> SparseArray@{{3, 4, 5}, {1, 2, 3}}, {3, 4, 5}]
>
> Out[21]= {{}, {}}
>
> In[22]:= Pick[{{a, b, c}, {d, e, f}}, {{3, 4, 5}, {1, 2, 3}}, {3, 4, 5}]
>
> Out[22]= {{a, b, c}, {}}
>
> Oyvind Tafjord
> Wolfram Research
>
>

--
DrMaj...@bigfoot.com

DrMajorBob

unread,
Jun 28, 2007, 4:39:56 AM6/28/07
to
A primary aspect of "optimal behavior" is that we expect it. By that
definition, Pick is ideal for Oyvind and nearly ideal for Andrzej. But...
for the rest of us? We'll just have to adjust our expectations.

In Mathematica, as in life, documentation can never be taken at face
value, and every answer must be double-checked.

Bobby

On Wed, 27 Jun 2007 04:22:01 -0500, Chris Chiasson <ch...@chiasson.name>
wrote:

> Ok, I agree to disagree in that I think it would be more consistent as
> I specified above, but I of course respect your and (assumedly)
> Oyvind's view that things are better the way they are.
>

--
DrMaj...@bigfoot.com

János

unread,
Jun 29, 2007, 5:40:57 AM6/29/07
to
Like barbers who are shaving themselves... :)

J=E1nos
P.S. I am hearing someone turning slowly in his grave....

On Jun 28, 2007, at 4:26 AM, DrMajorBob wrote:

> That's entirely contrary to the documentation, which says that Pick
> "picks
> out those ELEMENTS of list for which the corresponding ELEMENT of
> sel is
> True."
>
> How is a list its own ELEMENT, if English words mean anything?
>

> Bobby
>
> On Tue, 26 Jun 2007 03:08:14 -0500, Oyvind Tafjord

> <taf...@wolfram.com>
> wrote:
>
>> Chris Chiasson wrote:

>>> Step to reproduce:
>>> 1. Evaluate these two inputs with a fresh kernel:
>>> Pick[{a,b},z[{},{1}],{__}]
>>> Pick[{a,b},{{},{1}},{__}]
>>>
>>> Expected results:
>>> {b}
>>> {b}
>>>
>>> Actual results:
>>> {b}
>>> {a,b}
>>>
>>> Relevant Documentation:

>>> Pick[list,sel,patt] picks out those list[[i1,i2,...]] for which
>>> sel[[i1,i2,...]] matches patt.
>>

>> 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}
>>

Chris Chiasson

unread,
Jul 1, 2007, 3:32:44 AM7/1/07
to
On Jun 29, 4:40 am, J=E1nos <janos.l...@yale.edu> wrote:
> Like barbers who are shaving themselves... :)
>
> J=E1nos
> P.S. I am hearing someone turning slowly in his grave....
>
> On Jun 28, 2007, at 4:26 AM, DrMajorBob wrote:
>
> > That's entirely contrary to the documentation, which says that Pick
> > "picks
> > out those ELEMENTS of list for which the corresponding ELEMENT of
> > sel is
> > True."
>
> > How is a list its own ELEMENT, if English words mean anything?
>
> > Bobby

LOL


Andrzej Kozlowski

unread,
Jul 2, 2007, 7:06:35 AM7/2/07
to

Actually, there is nothing at all unusual about barbers shaving
themselves. I am sure lots of barbers do it. Russell's illustration
(of a variant of his paradox) was about a barber who "shaved everyone
in town who did not shave himself". It would take more than all the
resourcefulness of Figoro, the barber of Seville, to relate this to
this description of the behaviour of Pick, also taken from the
documentation:

Pick[list,sel,patt] picks out those list[[i1,i2,=85]] for which sel
[[i1,i2,=85]] matches patt.

Now, this is a pretty straight forward statement which describes
precisely the behaviour of Pick - but I am afraid it's not likely to
generate any more feats of philosophical depth and wit.

I do agree that the statement quoted by Bobby can mislead those who
insist on taking everything at face value but it was only meant as a
"first order approximation" and it is enough to dig a little deeper
into the documentation to see that the behaviour of Pick that Chris
objected to is in fact clearly documented.

Andrzej Kozlowski


Chris Chiasson

unread,
Jul 3, 2007, 5:13:58 AM7/3/07
to
On 7/2/07, Andrzej Kozlowski <ak...@mimuw.edu.pl> wrote:
<snip/>

> Actually, there is nothing at all unusual about barbers shaving
> themselves. I am sure lots of barbers do it. Russell's illustration
> (of a variant of his paradox) was about a barber who "shaved everyone
> in town who did not shave himself". It would take more than all the
> resourcefulness of Figoro, the barber of Seville, to relate this to
> this description of the behaviour of Pick, also taken from the
> documentation:
>
> Pick[list,sel,patt] picks out those list[[i1,i2,=85]] for which sel
> [[i1,i2,=85]] matches patt.
>
> Now, this is a pretty straight forward statement which describes
> precisely the behaviour of Pick - but I am afraid it's not likely to
> generate any more feats of philosophical depth and wit.
>
> I do agree that the statement quoted by Bobby can mislead those who
> insist on taking everything at face value but it was only meant as a
> "first order approximation" and it is enough to dig a little deeper
> into the documentation to see that the behaviour of Pick that Chris
> objected to is in fact clearly documented.
>
> Andrzej Kozlowski

I disagree:

The documentation fails to properly indicate on which level it is
starting the comparison (and possibly whether the matching is
depth-first or top-first).

Compare MemberQ to the behavior of Pick mentioned in my first post of
the thread:
In[1]:= MemberQ[z[{},{1}],{__}]
MemberQ[z[{},{}],{__}]
MemberQ[{{},{}},{__}]
Out[1]= True
Out[2]= False
Out[3]= False

The behavior of MemberQ (and Cases, etc) is much more predictable
because its documentation actually tells you on which level it starts
comparing things.

Attempting to describe the behavior of a multi-level pattern matching
function solely in terms of evaluation of Part is not very precise.

Finally, if they wanted me to not be surprised, they should have said:

Pick[list,sel,patt] picks out those list[[i1=85]] for which sel[[i1=85]]
matches patt.

--
http://chris.chiasson.name/

Chris Chiasson

unread,
Jul 3, 2007, 5:14:59 AM7/3/07
to
On 7/2/07, Andrzej Kozlowski <ak...@mimuw.edu.pl> wrote:
>
> On 2 Jul 2007, at 22:07, Chris Chiasson wrote:
>
> > Finally, if they wanted me to not be surprised, they should have said:
> >
> > Pick[list,sel,patt] picks out those list[[i1=85]] for which sel[[i1=85=
]]
> > matches patt.
>
> Maybe that (not surprising you) was not at the top of their list of
> priorities.
>
> Andrzej

Agreed. They were probably rushing just to finish the documentation in
time for the release. Still, using RepeatedNull@i1 would do more to
indicate matching at the top level than i1, i2, \[Ellipsis]. Why
should they attempt to invent a new set of pattern descriptions when
they already have a working set?
--
http://chris.chiasson.name/

Andrzej Kozlowski

unread,
Jul 3, 2007, 5:17:03 AM7/3/07
to

On 2 Jul 2007, at 22:07, Chris Chiasson wrote:

> Finally, if they wanted me to not be surprised, they should have said:
>

> Pick[list,sel,patt] picks out those list[[i1=85]] for which sel[[i1=85]]
> matches patt.

Maybe that (not surprising you) was not at the top of their list of
priorities.

Andrzej=

Andrzej Kozlowski

unread,
Jul 3, 2007, 5:19:05 AM7/3/07
to
It seems to me that the whole discussion of parts, empty sets etc. is
really beside the point, although I admit that the vagueness of the
documentation on this point can give rise to this representation. For
example both

Pick[{{{a}}, {b}, c}, l, _]

{{{a}}, {b}, c}

and

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


aare perfectly understandable if you think in terms of pattern
matching but require (quite unnecesasary) mental acrobatics to
explain in terms of the properties of the empty set, NOTHING,
EVERYTHING or barbers. The problem is that pattern matching is not
easy to explain in one or two lines of documentation.

Andrzej Kozlowski


On 3 Jul 2007, at 07:46, DrMajorBob wrote:

> If I were collecting indices on some criterion and didn't get any,
> I'd want the result to be some logical equivalent of NOTHING, not
> EVERYTHING.
>
> expr[[]] = Head[expr][], for instance.
>
> But Mathematica doesn't do it that way so, as I've said before,
> we'll just have to adjust our expectations.
>
> Bobby
>
> On Mon, 02 Jul 2007 16:58:11 -0500, Chris Chiasson
> <ch...@chiasson.name> wrote:
>
>> On 7/2/07, DrMajorBob <drmaj...@bigfoot.com> wrote:
>> <snip/>
>>> Nor have I seen an example in which [[]] is useful, rather than
>>> needlessly
>>> puzzling.
>>>
>>> (Unless I blinked and missed it.)
>>
>> It could be useful if one is generating the arguments to Part via a
>> program. If there are no sub-parts needed, then Sequence[] should be
>> sent as the second argument.
>>
>
>
>
> --
> DrMaj...@bigfoot.com


Chris Chiasson

unread,
Jul 3, 2007, 5:26:47 AM7/3/07
to
On 7/2/07, DrMajorBob <drmaj...@bigfoot.com> wrote:
<snip/>
> Nor have I seen an example in which [[]] is useful, rather than needlessly
> puzzling.
>
> (Unless I blinked and missed it.)

It could be useful if one is generating the arguments to Part via a
program. If there are no sub-parts needed, then Sequence[] should be
sent as the second argument.

--
http://chris.chiasson.name/

DrMajorBob

unread,
Jul 3, 2007, 5:27:48 AM7/3/07
to
Yeah, yeah, I know... the "2nd-order" explanation talks about
list[[i1,12,...]], and Sequence[] is a (degenerate) example of i1,i2,...,
so...

Right. That's totally obvious.

At least Andrzej (unlike Oyvind) told Chris how to avoid the top-level
match.

Bobby

On Mon, 02 Jul 2007 00:05:38 -0500, Andrzej Kozlowski <ak...@mimuw.edu.pl>
wrote:

> *This message was transferred with a trial version of CommuniGate(tm)
> Pro*
>

> On 1 Jul 2007, at 16:31, Chris Chiasson wrote:
>
>> On Jun 29, 4:40 am, J=E1nos <janos.l...@yale.edu> wrote:
>>> Like barbers who are shaving themselves... :)
>>>
>>> J=E1nos
>>> P.S. I am hearing someone turning slowly in his grave....
>>>
>>> On Jun 28, 2007, at 4:26 AM, DrMajorBob wrote:
>>>
>>>> That's entirely contrary to the documentation, which says that Pick
>>>> "picks
>>>> out those ELEMENTS of list for which the corresponding ELEMENT of
>>>> sel is
>>>> True."
>>>
>>>> How is a list its own ELEMENT, if English words mean anything?
>>>
>>>> Bobby
>>
>> LOL
>>
>>
>

> Actually, there is nothing at all unusual about barbers shaving
> themselves. I am sure lots of barbers do it. Russell's illustration (of
> a variant of his paradox) was about a barber who "shaved everyone in
> town who did not shave himself". It would take more than all the
> resourcefulness of Figoro, the barber of Seville, to relate this to this
> description of the behaviour of Pick, also taken from the documentation:
>

> Pick[list,sel,patt] picks out those list[[i1,i2,…]] for which sel
> [[i1,i2,…]] matches patt.


>
> Now, this is a pretty straight forward statement which describes
> precisely the behaviour of Pick - but I am afraid it's not likely to
> generate any more feats of philosophical depth and wit.
>
> I do agree that the statement quoted by Bobby can mislead those who
> insist on taking everything at face value but it was only meant as a
> "first order approximation" and it is enough to dig a little deeper into
> the documentation to see that the behaviour of Pick that Chris objected
> to is in fact clearly documented.
>
> Andrzej Kozlowski
>
>
>
>

--
DrMaj...@bigfoot.com

DrMajorBob

unread,
Jul 3, 2007, 5:28:49 AM7/3/07
to
No matter how obvious all this may be to Andrzej and Oyvind...

The fact remains, some of us have used Mathematica for eight years without
seeing an example of [[]] until now. If documentation often or prominently
mentioned it, we wouldn't be having this discussion.

Nor have I seen an example in which [[]] is useful, rather than needlessly
puzzling.

(Unless I blinked and missed it.)

I don't, by the way, insist on taking everything at face value. I test
code to see what it actually does, EVERY TIME, because I'm just that
cynical, both about the documentation and my own ability to interpret it.
Most of the time I don't mind very much, either. It's always an adventure!!

When the documentation is vague, ambiguous or contradictory and the
habitual defenders rush in to claim it's not... and the rest of us are
(apparently) just too dumb to read it properly...

THAT is annoying. And not helpful.

State in a positive and specific way that WRI meant i1,i2,... to include
Sequence[] as a possibility, and here's what happens in that case, and we
can all be thankful for the clarification. Tell us we should have already
KNOWN that, and we get annoyed.

I'm pretty sure that's a well-documented human reaction.

Bobby

On Mon, 02 Jul 2007 08:07:56 -0500, Chris Chiasson <ch...@chiasson.name>
wrote:

> On 7/2/07, Andrzej Kozlowski <ak...@mimuw.edu.pl> wrote:
> <snip/>


>> Actually, there is nothing at all unusual about barbers shaving
>> themselves. I am sure lots of barbers do it. Russell's illustration
>> (of a variant of his paradox) was about a barber who "shaved everyone
>> in town who did not shave himself". It would take more than all the
>> resourcefulness of Figoro, the barber of Seville, to relate this to
>> this description of the behaviour of Pick, also taken from the
>> documentation:
>>
>> Pick[list,sel,patt] picks out those list[[i1,i2,…]] for which sel
>> [[i1,i2,…]] matches patt.
>>
>> Now, this is a pretty straight forward statement which describes
>> precisely the behaviour of Pick - but I am afraid it's not likely to
>> generate any more feats of philosophical depth and wit.
>>
>> I do agree that the statement quoted by Bobby can mislead those who
>> insist on taking everything at face value but it was only meant as a
>> "first order approximation" and it is enough to dig a little deeper
>> into the documentation to see that the behaviour of Pick that Chris
>> objected to is in fact clearly documented.
>>
>> Andrzej Kozlowski
>

> I disagree:
>
> The documentation fails to properly indicate on which level it is
> starting the comparison (and possibly whether the matching is
> depth-first or top-first).
>
> Compare MemberQ to the behavior of Pick mentioned in my first post of
> the thread:
> In[1]:= MemberQ[z[{},{1}],{__}]
> MemberQ[z[{},{}],{__}]
> MemberQ[{{},{}},{__}]
> Out[1]= True
> Out[2]= False
> Out[3]= False
>
> The behavior of MemberQ (and Cases, etc) is much more predictable
> because its documentation actually tells you on which level it starts
> comparing things.
>
> Attempting to describe the behavior of a multi-level pattern matching
> function solely in terms of evaluation of Part is not very precise.
>

> Finally, if they wanted me to not be surprised, they should have said:
>

> Pick[list,sel,patt] picks out those list[[i1…]] for which sel[[i1…]]
> matches patt.
>
>
>

--
DrMaj...@bigfoot.com

DrMajorBob

unread,
Jul 3, 2007, 5:29:49 AM7/3/07
to
If I were collecting indices on some criterion and didn't get any, I'd
want the result to be some logical equivalent of NOTHING, not EVERYTHING.

expr[[]] = Head[expr][], for instance.

But Mathematica doesn't do it that way so, as I've said before, we'll just
have to adjust our expectations.

Bobby

On Mon, 02 Jul 2007 16:58:11 -0500, Chris Chiasson <ch...@chiasson.name>
wrote:

> On 7/2/07, DrMajorBob <drmaj...@bigfoot.com> wrote:
> <snip/>


>> Nor have I seen an example in which [[]] is useful, rather than
>> needlessly
>> puzzling.
>>
>> (Unless I blinked and missed it.)
>

> It could be useful if one is generating the arguments to Part via a
> program. If there are no sub-parts needed, then Sequence[] should be
> sent as the second argument.
>

--

DrMaj...@bigfoot.com

DrMajorBob

unread,
Jul 3, 2007, 5:30:50 AM7/3/07
to
> Pick[{{{a}}, {b}, c}, l, _]
>
> {{{a}}, {b}, c}
>
> and
>
> Pick[{{{a}}, {b}, c}, True]
> { {{a}} , {b}, c}
>
> are perfectly understandable if you think in terms of pattern matching

Yeah, yeah, we get it now. AFTER wasting too much time on it.

We're all reasonably smart, here... if a lot of us had the wrong
impression of both Pick and Part, the documentation bears at least a
LITTLE responsibility for that.

Regardless of how pattern matching works, it remains that documentation
doesn't tell us (1) at which level matching begins or (2) what the result
(if any) of expr[[]] would be.

Those examples also make me wonder what Help "means" when it says:

"The selector list has to have the same length and structure as the data:"

> The problem is that pattern matching is not easy to explain in one or

> two lines of documentation.

ONE line is all it takes to let us know Part's second argument can be
nothing at all, and what the result would be. It's no harder than the line
that says

"Part 0 of an expression is its head."

If Part had been implemented so that expr[[]] == Head[expr][] -- and I see
no reason why it couldn't or shouldn't have been -- we'd have a different
result from Pick, and I think you'd be arguing for its transparent
inevitability.

Bobby

On Mon, 02 Jul 2007 19:04:39 -0500, Andrzej Kozlowski <ak...@mimuw.edu.pl>
wrote:

> It seems to me that the whole discussion of parts, empty sets etc. is

> really beside the point, although I admit that the vagueness of the

> documentation on this point can give rise to this representation. For

> example both
>
> Pick[{{{a}}, {b}, c}, l, _]
>
> {{{a}}, {b}, c}
>
> and
>
> Pick[{{{a}}, {b}, c}, True]
> { {{a}} , {b}, c}
>
>
> aare perfectly understandable if you think in terms of pattern matching
> but require (quite unnecesasary) mental acrobatics to explain in terms
> of the properties of the empty set, NOTHING, EVERYTHING or barbers. The
> problem is that pattern matching is not easy to explain in one or two
> lines of documentation.
>
> Andrzej Kozlowski
>
>
>
>
> On 3 Jul 2007, at 07:46, DrMajorBob wrote:
>

--

DrMaj...@bigfoot.com

Chris Chiasson

unread,
Jul 3, 2007, 5:38:08 AM7/3/07
to
On 7/2/07, Andrzej Kozlowski <ak...@mimuw.edu.pl> wrote:
<snip/>
> The problem is that pattern matching is not
> easy to explain in one or two lines of documentation.

They should go with standardized levels-based documentation. I am
going to try to resist making further public replies, even though I
like arguing about this. Thanks to everyone for listening.

--
http://chris.chiasson.name/

János

unread,
Jul 3, 2007, 6:20:38 AM7/3/07
to
On Jul 2, 2007, at 6:52 AM, Andrzej Kozlowski wrote:

>
> On 1 Jul 2007, at 16:31, Chris Chiasson wrote:
>

>> On Jun 29, 4:40 am, J=3DE1nos <janos.l...@yale.edu> wrote:
>>> Like barbers who are shaving themselves... :)
>>>

>>> J=3DE1nos


>>> P.S. I am hearing someone turning slowly in his grave....
>>>
>>> On Jun 28, 2007, at 4:26 AM, DrMajorBob wrote:
>>>
>>>> That's entirely contrary to the documentation, which says that Pick
>>>> "picks
>>>> out those ELEMENTS of list for which the corresponding ELEMENT of
>>>> sel is
>>>> True."
>>>
>>>> How is a list its own ELEMENT, if English words mean anything?
>>>
>>>> Bobby
>>
>> LOL
>>
>>
>

> Actually, there is nothing at all unusual about barbers shaving
> themselves. I am sure lots of barbers do it. Russell's illustration
> (of a variant of his paradox) was about a barber who "shaved everyone
> in town who did not shave himself". It would take more than all the
> resourcefulness of Figoro, the barber of Seville, to relate this to

Figaro

http://en.wikipedia.org/wiki/Figaro

J=E1nos


------
"..because Annushka has already bought sunflower oil, and not only =20
bought it, but spilled it too."
Bulgakov: Master and Margarita


János

unread,
Jul 4, 2007, 5:37:15 AM7/4/07
to

On Jul 3, 2007, at 7:16 AM, Andrzej Kozlowski wrote:

> Congratulations! My imperfect keyboard control gave your chance
>
> La vendetta, oh la vendetta
> e un piacer serbato ai saggi,
> l'obliar l'onte, gli oltraggi
> e bassezza, e ognor vilta.
>
> ...
> Se tutto il codice dovessi volgere,
> se tutto l'indice dovessi leggere,
> con un equivoco, con un sinonimo,
> qualche garbuglio si trovera.
>
> (Le Nozze Di Fiagaro, Atto 1, Bartolo's Vendetta Aria).
>
> Andrzej Kozlowski

Andrzej, you are a wonderful person, although both of us know that it
is not just your keyboard control that is imperfect :)

For example: "...Figoro, the barber of Seville,...".

Well, the barber of Sevilha - as the Spanish would say - was
Bartolo, according to Beaumarchais :)


J=E1nos


----------------------------------------------------------
"A cyber virgin has never had intercourse outside of virtual reality,
whereas a virtual virgin has never had intercourse with a real person
even in virtual reality"

-Ray Kurzweil - "The age of spiritual machines"


Andrzej Kozlowski

unread,
Jul 4, 2007, 5:50:39 AM7/4/07
to

Andrzej Kozlowski=

Andrzej Kozlowski

unread,
Jul 5, 2007, 3:53:16 AM7/5/07
to

On 4 Jul 2007, at 18:32, J=E1nos wrote:

>> Andrzej Kozlowski
>
> Andrzej, you are a wonderful person, although both of us know that it
> is not just your keyboard control that is imperfect :)
>
> For example: "...Figoro, the barber of Seville,...".
>
> Well, the barber of Sevilha - as the Spanish would say - was
> Bartolo, according to Beaumarchais :)
>
>
> J=E1nos
>
>
> ----------------------------------------------------------
> "A cyber virgin has never had intercourse outside of virtual reality,
> whereas a virtual virgin has never had intercourse with a real person
> even in virtual reality"
>
> -Ray Kurzweil - "The age of spiritual machines"
>
>


A newbie is a newbie is a newbie (even if he has Wikipedia to help him).

Andrzej Kozlowski


------------------------------------------
Your proposition may be good
But let's have one thing understood --
Whatever it is, I'm against it!
And even when you've changed it or condensed it,
I'm against it.

Professor Quincy Adams Wagstaff
President of Huxley College

Andrzej Kozlowski

unread,
Jul 5, 2007, 4:42:38 AM7/5/07
to

On 4 Jul 2007, at 18:38, Andrzej Kozlowski wrote:

>
> On 3 Jul 2007, at 19:24, J=E1nos wrote:
>
>> On Jul 2, 2007, at 6:52 AM, Andrzej Kozlowski wrote:
>>
>>>
>>> On 1 Jul 2007, at 16:31, Chris Chiasson wrote:
>>>

>>>> On Jun 29, 4:40 am, J=E1nos <janos.l...@yale.edu> wrote:
>>>>> Like barbers who are shaving themselves... :)
>>>>>

>>>>> J=E1nos

> Andrzej Kozlowski=
>

Figaro ...

János

unread,
Jul 6, 2007, 3:24:14 AM7/6/07
to

I saw that, but my thought was that one "kill" is enough for one day :)

J=E1nos


-----------------------------------------


A newbie is a newbie is a newbie (even if he has Wikipedia to help him).

- Andrzej Kozlowski


Chris Chiasson

unread,
Jul 6, 2007, 3:44:50 AM7/6/07
to
On Jul 3, 4:13 am, "Chris Chiasson" <c...@chiasson.name> wrote:
> Pick[list,sel,patt] picks out those list[[i1=85]] for which sel[[i1=85]]
> matches patt.

Time to disagree with myself:
Actually, it should be:
Pick[list,sel,patt] picks out those list[[i___]] for which
sel[[i___]] matches patt.


Andrzej Kozlowski

unread,
Jul 7, 2007, 5:58:35 AM7/7/07
to
I see that I have now superseded not only Lem but even Bulhakov (the
correct Ukrainian spelling, by the way) by which I am really flattered.

Andrzej Kozlowski

0 new messages