Louis - First, from the looks of your code, your use of the cross product is identical to a squared sum:
$result = sum(a**2); That should handle bad values just fine. You can also use sumover in place of sum if you need to thread that over multiple dimensions. As for the code you actually posted, you are using some slightly obfuscated code which I believe bears some dissection. Here at least here is how I interpret it: On Mon, Jan 2, 2012 at 8:43 AM, louis <[email protected]> wrote: > I am trying to understand how to handle BAD values, but can do with some > help. I want to know how to properly deal with this warning "WARNING: > routine does not handle bad values." Here is some sample code. > > ------ > print (transpose($a) x $a); > This throws the warnings, right? > > . > . > . > > > I'm not sure if you understand the return value of the following sub. You might, but in case others miss it, I've added my understanding (but please correct me if I'm wrong). If a function does not have an explicit return statement, Perl returns the last executed statement. So... sub mysub{ > my ($pdla) = @_; > if (!$pdla->badflag()) { transpose($pdla) x $pdla;} > ... if there is no bad flag, this function returns this cross product... > else { my $pdlb=pdl(0)->inplace->setvaltobad( 0 );} > ... and if there is a badflag, this function returns this value, which is bad. > } > print mysub($a) ? "result is undefined\n" : "a is, $a"; > Because PDL doesn't like boolean evaluations **except for single-element piddles**, this expression will croak if $a is anything more than a one-dimensional vector. Have you tried running that conditional when $a is more complex? For example, if $a is a matrix, this will croak. Something I didn't realize, but just learned messing with this, is that a single BAD value is considered boolean false. That's more clever than I had expected. :-) ------ > > If $a has a bad value the first line will give the correct answer with > bad values where you expect them, but gives a warning: "WARNING: routine > does not handle bad values." > For those following along, the cross product (the 'x' operator) is PDL::matmult, defined in Basic/Primitive/primitive.pd. Craig implemented a tiled version of that function a couple of years back (so that multiplication of large matrices doesn't blow the processor cache). The resulting code is a bit more complex than a naive C implementation of matrix-matrix multiplication, and there is no BadCode section (yet?). Anyway, the fact that BAD values show up in the right place is quite surprising since there is no obvious reason to me why that should happen. I would almost consider that to be a bug. > The sub will not give the warning but of course the answer is now > undefined. > No, it's a PDL with a single bad value, which evaluates to false in boolean context. That's different from undef in some important ways. For exapmle, if you add 1 to an undefined value, it becomes 1, but if you add 1 to a PDL with a single bad value, its single value is still bad. > 1) How can I use the 'x' operator, with the correct propagation of the > bad values, but without the warning. > There is no way to avoid that warning unless you find a different expression that does the same thing, but which handles bad values (like the squared sum I used above). Which raises the question for PDL porters (not for you): wouldn't it make sense if PDL created its own class of warnings by using warnings::register? This way, users could turn off bad-value warning messages, or even handle them with their own $SIG{__WARNING__}. For those who care, checkout http://perldoc.perl.org/warnings.html > 2) The line with "else { my $pdlb=pdl(0)->inplace->setvaltobad( 0 );}" > is fairly ugly, is there a shorter way to do the same? > In PDL 2.4.10, you should be able to return pdl('bad'). That's a recent implementation of mine. :-) Alternatively, perhaps PDL should add BAD to PDL::Constants (as well as INF, for that matter). > Any help appreciated, I could not find the answer in the documentation > for PDL::Badbalues or in the PDL::Bad manpage. If avoidable I will stay > away from using the PP_def structures. > Sorry the bad docs are not very clear. I've struggled with them myself. Thank you for reading the docs before asking your question! Regards Louis > > > _______________________________________________ > Perldl mailing list > [email protected] > http://mailman.jach.hawaii.edu/mailman/listinfo/perldl > Did that help? David -- Sent via my carrier pigeon.
_______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
