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
