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: Maximize with Integer constraints**

**two integrals**

**Re: Re: problem with Pick**

**Re: Re: problem with Pick**