See http://mailman.jach.hawaii.edu/pipermail/perldl/2011-February/004782.html for some previous discussion this list on the same topic.
On Wed, Jan 11, 2012 at 4:43 PM, David Mertens <[email protected]> wrote: > Thinking more about this, there are some operations that have no business > having default names for the output, such as addition or multiplication. The > only thing that matters is lining up the order of dimensions for the > operands. Things like addition or sumover. > > Perhaps we could add a key to pp_def that indicates which keys should have > specific names. > > As for constructors, we could modify them to accept dash-arguments of this > form: > > my $data = sequence( -time => 100, -replicate => 20, -lab => 3); > > That would correspond to three labs performing 20 experiments that each have > 100 time samples. The issue here would be gracefully handling what happens > when somebody forgets to put that dash. > > As for aliasing, we should have it be that changes to a slice's dimension > name *do not* propagate to parents. Then we could have an identity slice > that lets you rename dim names, something like: > > my $data = sequence(-length => 20); > my $aliased_data = $data->alias_dims('length' => 'time'); > $aliased_data->fft; > > David :-) > > > On Wed, Jan 11, 2012 at 3:22 PM, David Mertens <[email protected]> > wrote: >> >> Chris - >> >> Fascinating idea! That would be amazing! It would be PDL DWIM taken to a >> whole new level. Here are my thoughts, in a semi-coherent fashion: >> >> In order to get this to work, we would have to modify the way that PDL::PP >> processes the inputs. We might be able to get this working in Perl-side code >> (or XS code if somebody has the brains and tuits) which would use affine >> slices to 'line-up' the dimension lists before calling the threading engine. >> >> IN FACT, we could even have the dimension names from the Pars key be the >> expected names of the dimensions. Of course, this would raise issues such as >> aliasing names (should a Fourier transform call its expected single dim >> 'time' or 't_series', and if so, what if you were taking the Fourier >> transform that had some other dimension. >> >> If there are output piddles, the names of the resulting piddles' >> dimensions would be the names of the dimensions in the order specified in >> the Pars section. >> >> >> >> >> On Wed, Jan 11, 2012 at 3:05 PM, Chris Marshall <[email protected]> >> wrote: >>> >>> I think it may be time to consider adding support >>> for some sort of tag or ID for dimensions as an >>> alternative to strict order in the dims list. >>> >>> If you read in an image, then the IO routine could >>> "tag" the dimensions with qw( rgba x y ) to indicate >>> that dim0 is the color dimension, x is the horizontal >>> pixel dimension, and y is the vertical pixel dimension. >>> This allows for more generic interfaces than we >>> currently have. One could even include default >>> propagation options for various routines on those >>> objects. >>> >>> --Chris >>> >>> On Wed, Jan 11, 2012 at 3:54 PM, Craig DeForest >>> <[email protected]> wrote: >>> > Sure, I think that would be a Good Thing to do (wrapping your various >>> > color >>> > transformations into a PDL::Transform::Color package that just exports >>> > a >>> > bunch of PDL::Transform constructors). Among other things, that would >>> > mean >>> > you could implement outlying ones simply, by composing the other >>> > transforms >>> > together (e.g. you get HSV<->CMYK for free if you've written HSV<->RGB >>> > and >>> > CMYK<->RGB). >>> > >>> > The only filip is that the ::Color transform routines should probably >>> > all >>> > include some breakage of the standard threading rule, by looking for >>> > active >>> > dimensions *after* the 0 dim. That is, for many applications images >>> > are >>> > stacked up as <w>x<h>x3-PDLs rather than as 3x<w>x<h> PDLs. Since the >>> > color >>> > index dim is the active dim, that implies doing a lot of things like: >>> > $im2 = $im1->mv(2,0)->apply(t_rgb2hsv)->mv(0,2); >>> > which is awkward. >>> > >>> > But essentially all images have dimensions bigger than 4x4, so >>> > t_rgb2hsv >>> > could go looking for any dim of size 3 or 4 (so that it could handle >>> > rgba >>> > images) in the first three dims of the input. That is not a big deal >>> > to >>> > implement, nor is it particularly expensive... >>> > >>> > >>> > >>> > On Jan 11, 2012, at 12:37 PM, David Mertens wrote: >>> > >>> > Craig - >>> > >>> > After a closer inspection of PDL::Transform and a refresher on my code, >>> > I >>> > don't think it would be good to implement this using PDL::Transform. >>> > Wrapping the conversion into a transform would make sense, but not >>> > implementing it as a PDL::Transform. HSV -> RGB involves a very >>> > confusing >>> > six-way branch with calculations from derived values. I only vaguely >>> > understand the logic myself; it's based on a writeup I read on >>> > wikipedia. >>> > You could do this using PDL, but the calculation that would either >>> > involve >>> > Perl-level loops or be awkwardly and inefficiently represented with >>> > conditional expressions like this: >>> > >>> > my $result = ($a < $b) * ($a * 360) + ($a > $b) * ($b * 360); >>> > >>> > The conditionals and calculations would be even more complicated that >>> > what's >>> > shown here. That's an awful lot of temporaries, and five of every six >>> > calculations would be thrown away. However, it *would* make sense to >>> > wrap >>> > the current RGB->HSV in a transform, so that it could be easily >>> > composed >>> > with other transforms. >>> > >>> > David >>> > >>> > On Wed, Jan 11, 2012 at 10:50 AM, David Mertens >>> > <[email protected]> >>> > wrote: >>> >> >>> >> Hmmm, perhaps I should finally read the docs on PDL::Transform. There >>> >> are >>> >> *so* many parts of PDL about which I know little to nothing. >>> >> >>> >> >>> >> On Wed, Jan 11, 2012 at 10:46 AM, Craig DeForest >>> >> <[email protected]> wrote: >>> >>> >>> >>> This type of conversion is a natch for a PDL::Transform subclass... >>> >>> >>> >>> >>> >>> On Jan 11, 2012, at 9:20 AM, Maggie X wrote: >>> >>> >>> >>> Sure, I can add them. Not sure I have committer status though :) >>> >>> Haven't >>> >>> worked on PDL proper yet. >>> >>> >>> >>> Maggie >>> >>> >>> >>> On Wed, Jan 11, 2012 at 11:06 AM, David Mertens >>> >>> <[email protected]> wrote: >>> >>>> >>> >>>> Maggie - >>> >>>> >>> >>>> >>> >>>> On Tue, Jan 10, 2012 at 9:42 PM, Maggie X <[email protected]> >>> >>>> wrote: >>> >>>>> >>> >>>>> Hi David, >>> >>>>> >>> >>>>> Your code converts between HSV and RGB. But it's not that different >>> >>>>> to >>> >>>>> convert between HSL and RGB. >>> >>>> >>> >>>> >>> >>>> Oh, sorry! All these nearly-identical acronyms get me confused. >>> >>>> >>> >>>>> Chris suggested that I add the HSL and RGB conversion to >>> >>>>> PDL::ImageRGB. >>> >>>>> What do you think of putting the HSV and RGB conversion in >>> >>>>> PDL::ImageRGB? >>> >>>> >>> >>>> >>> >>>> Having these generally available makes a lot of sense to me. Do you >>> >>>> want >>> >>>> to add them, or shall I? >>> >>>> >>> >>>>> Best, >>> >>>>> Maggie >>> >>>> >>> >>>> >>> >>>> Regards, >>> >>>> David >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> Perldl mailing list >>> >>> [email protected] >>> >>> http://mailman.jach.hawaii.edu/mailman/listinfo/perldl >>> >>> >>> >>> >>> >> >>> >> >>> >> >>> >> -- >>> >> Sent via my carrier pigeon. >>> > >>> > >>> > >>> > >>> > -- >>> > Sent via my carrier pigeon. >>> > >>> > >>> > >>> > _______________________________________________ >>> > Perldl mailing list >>> > [email protected] >>> > http://mailman.jach.hawaii.edu/mailman/listinfo/perldl >>> > >>> >>> _______________________________________________ >>> Perldl mailing list >>> [email protected] >>> http://mailman.jach.hawaii.edu/mailman/listinfo/perldl >> >> >> >> >> -- >> Sent via my carrier pigeon. > > > > > -- > Sent via my carrier pigeon. _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
