[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

Reply via email to