Hi Diab-
I generally prefer have bug tickets be for
things that are broken while enhancements and
new features or API changes would be added as
feature request tickets. That said, I'm not usually
picky either---except when we're in feature freeze
for a new release and adding a feature request as
a bug means I have a new problem to report in the
Known_Problems file for the release... :-)
The proposed copy behavior would "do what I mean" here which
seems appropriate---but definitely not clear from the POD.
I think that the special nature of being a placeholder for LHS
assignment operations should be clarified w.r.t. non-LHS
operations and behavior. For example, I read the docs as
stating the Null piddle value is only "possible" on the LHS
(other use is unspecified and null->copy => Empty seems to
be a reasonable outcome---I still like the principle of
least surprise value above...)
Seems a simple change but I don't know enough about
the threadI and sever operations on Null piddles to
apply something for the release I'm planning to push
tomorrow AM.
Cheers,
Chris
On 10/7/2016 17:30, Diab Jerius wrote:
> [I'm moving discussion of this here at Chris' request and top-posting,
> which looks like is
> the default behavior for this list]
>
> Executive summary,
>
> I expect PDL->null->copy to return a null piddle, it returns an empty one.
> ]
>
> I don't read the docs in the same way. Here's the excerpt from PDL::Core
>
> PDLs on the left-hand side of assignment can have the special value
> "Null". A null PDL has no dim list and no set size; its shape is
> determined by the computed shape of the expression being assigned to it.
> Null PDLs contain no values and can only be assigned to. When assigned
> to (e.g. via the ".=" operator), they cease to be null PDLs.
>
> There's nothing here which says that null's are only valid on the LHS,
> only that they have a special behavior when assigned to. I would like
> to be able to count on that behavior when a null piddle is copied
> without having to explicitly check if it is null. For example let's
> say I have an object which contains one or more piddles and I'd like
> to clone it, which would involve copying the piddles to the clone. I
> don't believe the code should care if the source piddle is null or
> not. I'd rather do this:
>
> use Safe::Isa;
> sub clone {
> my $self = shift;
> my %new = %$self;
> $new{$_} = $self->{$_}->copy for $self->{$_->$_isa( 'PDL' ) };
> return bless \%new, ref $self;
> }
>
> rather than
>
> use Safe::Isa;
> sub clone {
> my $self = shift;
> my %new = %$self;
> $new{$_} = $self->{$_}->isnull ? PDL->null : $self->{$_}->copy
> for $self->{$_->$_isa( 'PDL' ) };
> return bless \%new, ref $self;
> }
>
> It's inconsistent for copy() to return anything other than an exact copy.
>
> Could you define what you mean by "inappropriate context"? That might
> help me understand your argument.
>
>
>
> On Fri, Oct 7, 2016 at 12:34 PM, Chris Marshall <marshal...@users.sf.net>
> wrote:
>> - **Group**: normal --> feature_request
>> - **Priority**: 5 --> 1
>> - **Comment**:
>>
>> Per the docs a Null piddle is only valid on the LHS of an assignment
>> statement. Changing this to a feature request since it seems to be more of
>> a discussion regarding how to treat/use Null piddles in inappropriate
>> contexts. Croaking might be more appropriate although, ignoring the
>> specialness of Null piddles and trying to do the right (wrong) thing could
>> be more friendly. API discussion is needed. Please continue discussion on
>> the PDL mailing lists.
>>
>>
>>
>> ---
>>
>> ** [bugs:#427] PDL->null->copy returns an empty (not null) piddle**
>>
>> **Status:** open
>> **Group:** feature_request
>> **Labels:** 2.016
>> **Created:** Thu Oct 06, 2016 06:31 PM UTC by Diab Jerius
>> **Last Updated:** Thu Oct 06, 2016 06:31 PM UTC
>> **Owner:** nobody
>>
>>
>> PDL v. 2.016
>>
>> Copying a null piddle returns an empty piddle:
>>
>> ~~~
>> % perl -MPDL -E 'say PDL->null->copy->info'
>> PDL: Byte D [0]
>>
>> % perl -MPDL -E 'say PDL->null->copy->isnull'
>> 0
>> ~~~
>>
>> I expect it to return another null piddle.
>>
>>
>> ---
>>
>> Sent from sourceforge.net because you indicated interest in
>> <https://sourceforge.net/p/pdl/bugs/427/>
>>
>>
>>
>> To unsubscribe from further messages, please visit
>> <https://sourceforge.net/auth/subscriptions/>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> pdl-devel mailing list
> pdl-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/pdl-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
pdl-devel mailing list
pdl-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-devel
