Re: Re: problem with Pick
- To: mathgroup at smc.vnet.net
- Subject: [mg78279] Re: [mg78222] Re: [mg78194] problem with Pick
- From: Andrzej Kozlowski <akoz at mimuw.edu.pl>
- Date: Wed, 27 Jun 2007 05:33:49 -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> <46813C96.4090107@wolfram.com>
On 27 Jun 2007, at 01:19, Oyvind Tafjord wrote:
> 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.
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
- References:
- Re: problem with Pick
- From: "Chris Chiasson" <chris@chiasson.name>
- Re: problem with Pick