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/