Re: Re: problem with Pick

• To: mathgroup at smc.vnet.net
• Subject: [mg78254] Re: [mg78222] Re: [mg78194] problem with Pick
• From: Andrzej Kozlowski <akoz at mimuw.edu.pl>
• Date: Wed, 27 Jun 2007 05:21:00 -0400 (EDT)
• References: <acbec1a40706230431p4f1db9a9i4320680dda027396@mail.gmail.com> <200706260830.EAA05573@smc.vnet.net> <76C6BC8F-C94E-4574-BEFB-9903EFEDAA86@mimuw.edu.pl> <acbec1a40706260631y785868bcnadd36c795d0c557e@mail.gmail.com>

```On 26 Jun 2007, at 22:31, Chris Chiasson wrote:

> On 6/26/07, Andrzej Kozlowski <akoz at mimuw.edu.pl> plays Devil's
>>   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/

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

```

• Prev by Date: Re: Data Export to Excel, Reals or now Strings?
• Next by Date: Re: Why use Java in Mathematica?
• Previous by thread: Re: problem with Pick
• Next by thread: Re: Re: problem with Pick