Ingo Schmid
2013-12-06 17:20:18 UTC
Chris,
here are some fragments of where I'm aiming, see below.
I think the "proper" solution would be to make PDL be
consistent with other perl objects. The existing error
could be moved to planned PDL warnings support. That
has been on the wish list for quite some time.
I remember the discussion. I think that my suggestion would present a
relatively simple
solution. A modification to Core.pm.PL along the lines of this would do
it (line 870):
'bool' => sub { return 0 if $_[0]->isnull;
unless ($_[0]->pdl_cond ) { # old behaviour;
default
croak("multielement piddle in
conditional expression")
unless $_[0]->nelem == 1;
$_[0]->clump(-1)->at(0);
}
$_[0]->any if ($_[0]->pdl_cond eq 'any');
$_[0]->all if ($_[0]->pdl_cond eq 'all');
$_[0]->defined if ($_[0]->pdl_cond eq 'defined');
},
I would have provided a patch, but I think something like this is also
needed. I didn't figure where exactly I should place it.
sub pdl_cond {
my $self=shift;
my $c=shift;
if ($c) {
unless (UNIVERSAL::isa($self,'HASH')) {
my $h={};
$h{PDL}=$self;
$self=\%h;
}
$self->{multielement_cond}=shift ;
return $self->{umltielement_cond};
}
honestly, hard to say, I already do most stuff in PDL.
A lot of work has gone into making PDL easy to install. Keep
that going!
Bug reports, testing and user feedback are critical to
keeping this going.
method/function naming scheme and argument format are all
much desired features.
Right now, the goal for PDL-2.008 is to address the
remaining limitation of the 64bit index support within
the current PDL-2.x development sequence.
The PDL3 work will start from a core-cleanup from the
PDL-2.008 release which is hoped to be completed by
the end of Dec 2013.
a goal for PDL3 work. Various clean up along the
way is occurring.
metadata are planned for PDL3 as well. We have a general
approach already (roughly based on HDF5) but want to
clean up the PDL base before adding anything new. The
idea is that PDL3 will be more minimalist (closer to the
current PDL core distribution but allowing for backwards
compatibility to the 2.x sequence while enabling aggressive
new capabilities.
help to avoid redundant effort or inconsistent implementations.
Please take a look at the file attached. It's code that is extracted
from a bigger project which is meant to be its own module. I haven't
come around to actually separate it. This is something to work from, but
it should provide you with the idea where it is aimed. For example, the
sln() function should incorporate a call to slice, etc. At the moment it
operates on the metadata only and does not touch the piddle itself, it
should overload the appropriate basic PDL methods.
Happy PDL-ing!
Chris
Ingo
here are some fragments of where I'm aiming, see below.
Far less important but still, the barf on multielement piddles!
It breaks the expected if ($var) { ...} perl behaviour. This is
an issue whenever you use existing perl code with piddles. I
thought about it and maybe a per-piddle $piddle->cond_behave()
call added? The default value and undef would mean the
current behaviour, the other values would be, for example
'any','all','defined'. Then these calls are used in the
conditional expression. Discussion should go to a separate
thread, I guess.
There has been some discussion about this already andIt breaks the expected if ($var) { ...} perl behaviour. This is
an issue whenever you use existing perl code with piddles. I
thought about it and maybe a per-piddle $piddle->cond_behave()
call added? The default value and undef would mean the
current behaviour, the other values would be, for example
'any','all','defined'. Then these calls are used in the
conditional expression. Discussion should go to a separate
thread, I guess.
I think the "proper" solution would be to make PDL be
consistent with other perl objects. The existing error
could be moved to planned PDL warnings support. That
has been on the wish list for quite some time.
relatively simple
solution. A modification to Core.pm.PL along the lines of this would do
it (line 870):
'bool' => sub { return 0 if $_[0]->isnull;
unless ($_[0]->pdl_cond ) { # old behaviour;
default
croak("multielement piddle in
conditional expression")
unless $_[0]->nelem == 1;
$_[0]->clump(-1)->at(0);
}
$_[0]->any if ($_[0]->pdl_cond eq 'any');
$_[0]->all if ($_[0]->pdl_cond eq 'all');
$_[0]->defined if ($_[0]->pdl_cond eq 'defined');
},
I would have provided a patch, but I think something like this is also
needed. I didn't figure where exactly I should place it.
sub pdl_cond {
my $self=shift;
my $c=shift;
if ($c) {
unless (UNIVERSAL::isa($self,'HASH')) {
my $h={};
$h{PDL}=$self;
$self=\%h;
}
$self->{multielement_cond}=shift ;
return $self->{umltielement_cond};
}
- I would use PDL more (or at all) if only ...
... I could find the time to look into PP.honestly, hard to say, I already do most stuff in PDL.
- Any suggestions for PDL development?
many ;)A lot of work has gone into making PDL easy to install. Keep
that going!
keeping this going.
The graphics side took huge steps forward with bindings to
Prima and Gnuplot. BTW., what do you get if you install PDL but
have no graphics package installed? I'd like to see a big fat
warning whenever that is the case, because nothing would turn
people away faster than not being able to say "plot $x;" and
get something on the screen, I guess.
Good idea.Prima and Gnuplot. BTW., what do you get if you install PDL but
have no graphics package installed? I'd like to see a big fat
warning whenever that is the case, because nothing would turn
people away faster than not being able to say "plot $x;" and
get something on the screen, I guess.
Better documentation, especially some kind of index to look for
keywords related to modules/functions is always an issue.
Better documentation, cross-references, and a more uniformkeywords related to modules/functions is always an issue.
method/function naming scheme and argument format are all
much desired features.
There has been a lot of improvements, especially the book is a
real bonus. As a side note, when I click on the PDL Book link
(side panel on pdl.perl.org), I come to the page first steps
with PDL. Only at the very bottom of the page, there is a link
to the sf book! Please provide a link right at the top!
Done.real bonus. As a side note, when I click on the PDL Book link
(side panel on pdl.perl.org), I come to the page first steps
with PDL. Only at the very bottom of the page, there is a link
to the sf book! Please provide a link right at the top!
Support more data types, especially complex.
Generic type support is planned in the PDL3 development.Right now, the goal for PDL-2.008 is to address the
remaining limitation of the 64bit index support within
the current PDL-2.x development sequence.
The PDL3 work will start from a core-cleanup from the
PDL-2.008 release which is hoped to be completed by
the end of Dec 2013.
Make PDL as perlish as possible from the view of other non-PDL
modules. Ideally, PDL behaves just like another class, and
a piddle is just yet another reference to an object. Recent
discussions on use base PDL; and Storable should give you an
idea what I mean.
Clean up of the default PDL import semantics is alsomodules. Ideally, PDL behaves just like another class, and
a piddle is just yet another reference to an object. Recent
discussions on use base PDL; and Storable should give you an
idea what I mean.
a goal for PDL3 work. Various clean up along the
way is occurring.
Support for meaningful dimensions (names, units, spacing).
Rather than having to remember and keeping track of what your
piddle looks like, ie. the mes one can end after using several
mv(), reshape(), etc., calling sumover('x','t') would be cool.
Support for attributes to tag dimensions with variousRather than having to remember and keeping track of what your
piddle looks like, ie. the mes one can end after using several
mv(), reshape(), etc., calling sumover('x','t') would be cool.
metadata are planned for PDL3 as well. We have a general
approach already (roughly based on HDF5) but want to
clean up the PDL base before adding anything new. The
idea is that PDL3 will be more minimalist (closer to the
current PDL core distribution but allowing for backwards
compatibility to the 2.x sequence while enabling aggressive
new capabilities.
I have been working on that and some stuff is already there.
I plan to release a module some time in the future, but have
currently too much other stuff to do. Discussion should go to a
separate thread, I guess.
Yes, and please keep pdl-porters in the loop. It couldI plan to release a module some time in the future, but have
currently too much other stuff to do. Discussion should go to a
separate thread, I guess.
help to avoid redundant effort or inconsistent implementations.
from a bigger project which is meant to be its own module. I haven't
come around to actually separate it. This is something to work from, but
it should provide you with the idea where it is aimed. For example, the
sln() function should incorporate a call to slice, etc. At the moment it
operates on the metadata only and does not touch the piddle itself, it
should overload the appropriate basic PDL methods.
To summarise, I like PDL a lot and use it a lot.
Great to hear...Happy PDL-ing!
Chris