Re: Re: Re: problem with Pick
- To: mathgroup at smc.vnet.net
- Subject: [mg78323] Re: [mg78256] Re: [mg78222] Re: [mg78194] problem with Pick
- From: DrMajorBob <drmajorbob at bigfoot.com>
- Date: Thu, 28 Jun 2007 04:28:20 -0400 (EDT)
- References: <acbec1a40706230431p4f1db9a9i4320680dda027396@mail.gmail.com> <29194312.1182942180213.JavaMail.root@m35>
- Reply-to: drmajorbob at bigfoot.com
A primary aspect of "optimal behavior" is that we expect it. By that
definition, Pick is ideal for Oyvind and nearly ideal for Andrzej. But...
for the rest of us? We'll just have to adjust our expectations.
In Mathematica, as in life, documentation can never be taken at face
value, and every answer must be double-checked.
Bobby
On Wed, 27 Jun 2007 04:22:01 -0500, Chris Chiasson <chris at chiasson.name>
wrote:
> 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
>>
>>
>>
>
>
--
DrMajorBob at bigfoot.com