The problem with the Perl logicals is that, being short-circuiting
operators (which explicitly don't evaluate their second argument if
that argument can't affect the outcome), they don't have deterministic
behavior in a threaded expression. The bitwise Booleans work well as
non-short-circuiting operators, provided only that you ensure your
values are logical and not just arbitrary numbers.
In your case
my $t = $opts{t} or sequence( $data->dim(0) );
I think that what you really want is the perl-6 operator '//':
my $t = $opts{t} // sequence( $data->dim(0) );
which acts on the definedness, rather than truth, of the left-hand
argument. It would indeed be very nice to have that particular
shorthand in Perl 5.
The current status quo (of barfing out when a multi-element PDL gets
evaluated in boolean context) is surprising but at least it avoids the
(different) hosts of tricky bugs and surprising cases that turn up
when any of the main alternatives (non-short-circuiting operation, all/
any collapse, or nonnullness) are considered.
Cheers,
Craig
On Jul 1, 2009, at 9:26 AM, David Mertens wrote:
> It says in the FAQ (question 6.11) that logical operators simply
> don't work. Why?
>
> As is somewhat common practice, I have set up some of my scripts to
> get user info through a hash, which allows for nicely compact ways
> of setting variable defaults, like:
>
> my $yLabel = ( $opts{yLabel} or 'Amplitude');
>
> However, since logical operators are not allowed with piddles, I
> can't do something like this:
>
> my $t = ( $opts{t} or sequence( $data->dim(0) ) );
>
> I argue that this breaks precedence with how Perl handles this sort
> of expression. I think that any nonempty piddle should return
> 'true', just as any nonempty list returns 'true' (since nonempty
> lists return their length in scalar contexts). This way, you can
> still set up more elaborate checks on user passed data if you want
> to allow them to pass a null piddle and have it carry some meaning:
>
> my $t;
> if ( defined ( $opts{t} )) {
> $t = $opts{t};
> }
>
> Surely somebody has thought about this and justified the current
> lack of logicals. If I had to guess, it's because introducing this
> behavior would lead to difficult-to-find bugs. Is that the
> reasoning? Where can I read more?
>
> Thanks.
> David
> _______________________________________________
> Perldl mailing list
> [email protected]
> http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
_______________________________________________
Perldl mailing list
[email protected]
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
