[Pdl-porters] PDL::IO::Pic::rim() is broken.

Sisyphus sisyphus1 at optusnet.com.au
Wed Jul 18 01:02:07 HST 2012


Hi,

In Pic.pm we have:

##########################
sub rim {
  my(@args) = @_;

  if(@args == 2) {
    my($dest) = $args[0];
    if($dest->dim(0) == 3) {
      $args[0] = $dest->reorder(1,2,0);
    }
    return rpic(@args);
  }

 [then some other stuff - all it ever does, however, is to ultimately call 
rpic()]
#########################

Clearly the assumption is that if rim() has been called with 2 args, then 
the first arg is a piddle - ie it's assumed that rim has been called as:

rim($piddle, 'file.ext');

But this is a wrong assumption - it could just as well have been called as 
(eg):

$piddle = rim('file.ext', {FORMAT => 'PNG'});

So, I thought, we'll just change the condition from (@args == 2) to 
(ref($args[0]) eq 'PDL').
And that works ok if $dest->dim(0) != 3. But if dim(0) == 3, then it just 
errors out - and I'm wondering why that condition is in there in the first 
place.
Anyone know ?

Here's the error:

PDL::reorder: Number of elements (3) in newDimOrder array exceeds the number 
of dims in the supplied PDL (2) at :/MinGW/perl516/site/lib/PDL/Slices.pm 
line 890, <PNM> line 3.
        PDL::reorder('PDL=SCALAR(0x2daac9c)', 1, 2, 0) called at 
C:/MinGW/perl516/site/lib/PDL/IO/Pic.pm line 570
        PDL::IO::Pic::rim('PDL=SCALAR(0x2daac9c)', 'test2.png', 
'HASH(0x2dad2b4)') called at try.pl line 31

If I comment out the crud that deals with the case that ($dest->dim(0) == 
3), then all works fine - even when dim(0) *is* 3.
Is there a situation where we really *do* need to reorder() $dest when 
dim(0) == 3 ?

Given that:
a) we don't currently test rim() anywhere in the test suite, and;
b) all it does is call rpic()

should we just deprecate it ?
Or is it a function that should be fixed and tested ?

There's another deficiency with rim()  ... or so it seems to me.
If we want to do rim($piddle, 'file.ext'), and have that $piddle set 
correctly, then we can't just provide it with any old $piddle - we have to 
give it a $piddle that already has the correct dimensions. Is there an easy 
way to know (in general) the dimensions of the pdl that rpic('file.ext') is 
going to return ?

Cheers,
Rob




More information about the PDL-porters mailing list