Re: Re: problem with Pick
- To: mathgroup at smc.vnet.net
- Subject: [mg78268] Re: [mg78222] Re: [mg78194] problem with Pick
- From: "Chris Chiasson" <chris at chiasson.name>
- Date: Wed, 27 Jun 2007 05:28:11 -0400 (EDT)
- References: <acbec1a40706230431p4f1db9a9i4320680dda027396@mail.gmail.com>
On 6/26/07, Oyvind Tafjord <tafjord at wolfram.com> wrote:
> 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.
OOTH, a note about the level specification would alert users that
there is more than just a first-level operation going on by default
(kinda like Outer).
> 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.
Yea. Mainly I just brought it in to show that the (lack of) level
specification handling wasn't described accurately enough in the
documentation (assuming no one wants to go with my idea of defaulting
to the first level).
> 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.
Yes, that would be bad.
> 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.
What about making the Automatic level specification always choose {1}
or greater if both list and sel are not atomic? If the user
specifically wants to test the whole expression, then it could be
specified manually? Would that break a lot of code? (It wouldn't break
any sparse matrix code, would it?)
--
http://chris.chiasson.name/