Re: Re: problem with Pick

*To*: mathgroup at smc.vnet.net*Subject*: [mg78256] Re: [mg78222] Re: [mg78194] problem with Pick*From*: "Chris Chiasson" <chris at chiasson.name>*Date*: Wed, 27 Jun 2007 05:22:01 -0400 (EDT)*References*: <acbec1a40706230431p4f1db9a9i4320680dda027396@mail.gmail.com>

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 <akoz at mimuw.edu.pl> 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 > > > -- http://chris.chiasson.name/