Services & ResourcesWolfram ForumsMathGroup Archive

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

Re: Re: problem with Pick

• To: mathgroup at smc.vnet.net
• Subject: [mg78265] Re: [mg78222] Re: [mg78194] problem with Pick
• From: Oyvind Tafjord <tafjord at wolfram.com>
• Date: Wed, 27 Jun 2007 05:26:39 -0400 (EDT)
• References: <acbec1a40706230431p4f1db9a9i4320680dda027396@mail.gmail.com> <200706260830.EAA05573@smc.vnet.net> <76C6BC8F-C94E-4574-BEFB-9903EFEDAA86@mimuw.edu.pl> <acbec1a40706260631y785868bcnadd36c795d0c557e@mail.gmail.com> <7C64879C-867C-48F9-BB8C-6F0A8420DDE4@mimuw.edu.pl>

Andrzej Kozlowski wrote:
> *This message was transferred with a trial version of CommuniGate(tm) Pro*
> 
> On 26 Jun 2007, at 22:31, Chris Chiasson wrote:
> 
>> On 6/26/07, Andrzej Kozlowski <akoz at 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/
> 
> 
> 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

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