[Pdl-porters] Logical evaluation of a piddle

[David Mertens]

Ingo -

In practice, is there a situation where using local to override &PDL::bool
won't work? I.e.
{
local *PDL::bool = sub {
... preferred boolean handling goes here ...
};
# Call the code that expects defined == true
my $foo = Some::Class->new(arg => $piddle);
...
}

Also, why not allow the user to specify callbacks? Why limit the user to
strings that identify behavior?

David


On Fri, Dec 6, 2013 at 12:40 PM, Craig DeForest

Hmmm...
The issues with '&&' and '||' support is that an important part of
(a) they short-circuit, which would require non-deterministic code
execution in the multielement case;
(b) there is no obvious way to clump the results to a single boolean
("any" vs "all" vs "majority-rule", for example)
Ingo, your idea is kind of cool, but I don't see how it helps much.
Since PDL-as-hash-element is mainly meant as a convenience to writers
of subclasses, why not just override 'bool' for that class instead
of adding more strangeness to PDLs themselves?
I actually rather like the default behavior of PDLs: placing a
multielement PDL into a Perl conditional expression is nearly always
an error...

Chris,
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 and
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
'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!

Bug reports, testing and user feedback are critical to
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.

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 uniform
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.

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 also
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 various
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 could
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.

To summarise, I like PDL a lot and use it a lot.

Great to hear...
Happy PDL-ing!
Chris

Ingo
<PDL-Dim.pm>_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

[Chris Marshall]

Good points, David.

I recommend that the KISS principle be one of the guiding
lights for the PDL2 -> PDL3 evolution. The clearer and
cleaner the implementation, the simpler and more powerful
PDL will become as a perl toolkit for computation/visualization.

--Chris

Post by David Mertens
Ingo -
In practice, is there a situation where using local to override &PDL::bool
won't work? I.e.
{
local *PDL::bool = sub {
... preferred boolean handling goes here ...
};
# Call the code that expects defined == true
my $foo = Some::Class->new(arg => $piddle);
...
}
Also, why not allow the user to specify callbacks? Why limit the user to
strings that identify behavior?
David

[Ingo Schmid]

Hi,


i wasn't aware of the
local *PDL::bool = sub{}
possibility. the solution I posted was greping on multielement,
sketching over Core.pm.PL, and thought up in about 5 minutes while typing.

Nevertheless, some predefined options for the behaviour that don't
require expert knowledge of internals (i.e. existance of the &bool ...).
Obviously, the desired behaviour is controversial, that's why I'd opt
for some flag. Something like is used for inplace, bad, etc.

Ingo

Post by Chris Marshall
Good points, David.
I recommend that the KISS principle be one of the guiding
lights for the PDL2 -> PDL3 evolution. The clearer and
cleaner the implementation, the simpler and more powerful
PDL will become as a perl toolkit for computation/visualization.
--Chris

Post by David Mertens
Ingo -
In practice, is there a situation where using local to override &PDL::bool
won't work? I.e.
{
local *PDL::bool = sub {
... preferred boolean handling goes here ...
};
# Call the code that expects defined == true
my $foo = Some::Class->new(arg => $piddle);
...
}
Also, why not allow the user to specify callbacks? Why limit the user to
strings that identify behavior?
David

[David Mertens]

I thought of a situation where overriding \&bool would not achieve the
desired goal. When working with even programming, it is easy to push an
event on the event stack that will be executed after your function has
exited scope, in which case the bool override is gone. The only way to work
with local bool overrides in an event-driven context is to push an
anonymous subroutine reference to the event loop. The subref would itself
override bool before invoking the code that expects the PDL to not die in a
boolean evaluation. If that's not flaming hoops to jump through, I don't
know what is.

Also, I used the wrong name. The correct override is the function named
(bool, with the opening parenthesis:

--------%<--------
use strict;
use warnings;
use PDL;
use Test::More;

my $data = sequence(20);

### Confirm the known failing boolean eval ###
my $result = eval {
note("This should not appear") if $data;
1;
};
ok(!$result, "Multi-element piddle should croak when evaluated in boolean
context");

### Try the local boolean override ###
$result = eval {
no strict 'refs';
no warnings 'redefine';
local *{"PDL::(bool"} = sub { return defined $_[0] };
note("This should appear") if $data;
1;
};
ok($result, "Local bool override saves the day");

### Create a subref that won't work the way we want ###
my $subref;
{
no strict 'refs';
no warnings 'redefine';
local *{"PDL::(bool"} = sub { return defined $_[0] };
$subref = sub {
note("This should not appear") if $data;
};
}

$result = eval {
$subref->();
1;
};
ok(!$result, "local override is not carried with anonymous subroutine");

### Create a subref that will work the way we want ###
$subref = sub {
no strict 'refs';
no warnings 'redefine';
local *{"PDL::(bool"} = sub { return defined $_[0] };
note("This should appear") if $data;
};

$result = eval {
$subref->();
1;
};
ok($result, "local override works if applied within the anonymous subref");

done_testing;
-------->%--------

David

Post by Ingo Schmid
Hi,
i wasn't aware of the
local *PDL::bool = sub{}
possibility. the solution I posted was greping on multielement, sketching
over Core.pm.PL, and thought up in about 5 minutes while typing.
Nevertheless, some predefined options for the behaviour that don't require
expert knowledge of internals (i.e. existance of the &bool ...). Obviously,
the desired behaviour is controversial, that's why I'd opt for some flag.
Something like is used for inplace, bad, etc.
Ingo

Post by Chris Marshall
Good points, David.
I recommend that the KISS principle be one of the guiding
lights for the PDL2 -> PDL3 evolution. The clearer and
cleaner the implementation, the simpler and more powerful
PDL will become as a perl toolkit for computation/visualization.
--Chris

Post by David Mertens
Ingo -
In practice, is there a situation where using local to override &PDL::bool
won't work? I.e.
{
local *PDL::bool = sub {
... preferred boolean handling goes here ...
};
# Call the code that expects defined == true
my $foo = Some::Class->new(arg => $piddle);
...
}
Also, why not allow the user to specify callbacks? Why limit the user to
strings that identify behavior?
David