I see. Yes, that is a trouble spot. Currently dim generation and manipulation is pretty awkward. I seem to end up writing things like " [ some_operation( pdl( $a->dims )->(0:2) )->list ] " a lot.
Would that use case be helped by something like a "pdims" that returned a PDL instead of a list? Also, maybe dims() and pdims() could take an optional second argument that's the number of dims you want? e.g. $dexes = ndcoords( $a->dims(2) ); # Index the first two dimensions of $a $b = $a->indexND( ndcoords( list $a->pdims(2)/2 ) ); # cheesy downsample On Feb 27, 2013, at 11:28 AM, Chris Marshall <[email protected]> wrote: > The use case I had in mind was generating > an appropriate set of ndcoords for a set of > dims that *would* work with threading as in > processing an RGB image as a set of 2D > color images. > > I just had a thought this might be workable > with an optional second argument to the > shape() method to specify the dims of interest > and the result would be something that could > work with dice et. al. > > --Chris > > On Wed, Feb 27, 2013 at 1:22 PM, Craig DeForest > <[email protected]> wrote: >> On Feb 27, 2013, at 10:53 AM, Chris Marshall <[email protected]> wrote: >> >>> This is either a question about slice/niceslice >>> or an idea for new functionality: >>> >>> If I have a pdl of shape [M,N,P,Q,R] how can >>> extract the slice with shape [M,N] without filling >>> out all the missing dimensions explicitly? E.g., >>> >>> (:,:,0,0,0;-) if M>1 and N>1 >>> >>> this would amount to setting a default index >>> for missing dimensions. Of course, it would >>> nice to be able to specify by dimension number >>> for the dims you keep as well.... >>> >> >> I don't particularly hold with it, since it breaks the generality of the >> threading paradigm -- i.e. that the first few dimensions are considered to >> be intrinsic to the quantity you're manipulating, and the later dimensions >> are looped over automagically. Keeping that concept robustly in mind as we >> develop has made PDL extraordinary among vectorized languages. Alone among >> the big players, PDL really does offer robust vectoriztation pretty much >> anywhere: you actually can vectorize pretty much any operation just by >> adding some more dims to its operand. Sure, there are a few exceptions >> (e.g. the short-circuiting operators and a few of the primitives) but they >> are sparse enough to not break the paradigm. >> >> I worry that, if we introduce notation that permits breaking the threading >> paradigm so easily, it will indeed be broken more frequently, and a thing of >> beauty will begin to decay. Of course, all that said -- if there is a >> common use case we should definitely think about it. I know that IDL users >> expect that kind of broken behavior, for example. >> >> > _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
