On 2015-06-17 at 21:10:31 +0100, Ed wrote: > Please please please could one of you turn the example into a *.t file which > we can use to permanently constrain PDL behaviour going forward?
I have written some tests and commented further on the SF bug tracker. Hopefully the SF bug tracker accepts my e-mail (SF is slow at responding). :-( In the meantime, I've mirrored my comments on to GitHub <https://github.com/PDLPorters/pdl/issues/124#issuecomment-113960704> so they don't get lost. Cheers, - Zaki Mughal > > Ed > > From: Marek Gierliński > Sent: Tuesday, June 16, 2015 5:12 PM > To: Chris Marshall ; pdl-devel@lists.sourceforge.net > Subject: Re: [Pdl-devel] Fwd: Re: [Pdl-general] Weird behaviour of stats with > bad values > > Thanks a lot, Chris! > > Marek > > > On Tue, 16 Jun 2015 at 15:57 Chris Marshall <devel.chm...@gmail.com> wrote: > > Marek- > > I've opened a highest priority bug report based on your information: > > http://sourceforge.net/p/pdl/bugs/390 > > Could you add information on your system specifics to the ticket > for reference (the output of perldl -V has the main information)? > We'll be updating the ticket as information becomes available. > > Thanks for reporting the problem! > > Chris > > > > > > On 6/16/2015 09:49, Marek Gierliński wrote: > > This is very bad news for me. I just searched through my scripts and > found 586 instances of 'stats'. If this is not corrected, I have to assume > that all of them might potentially produce incorrect results, without even > failing (like in the if($s > 0) example). > > > We've been using 2.007 for a couple of months now. I'm not even sure if > my recent results are correct. > > Marek > > On Tue, 16 Jun 2015 at 14:43 Chris Marshall <devel.chm...@gmail.com> > wrote: > > That definitely seems like a bug to me. Thanks for the cross-check, > Marek. > Devels, I see the same in the latest PDL release so it is not a > PDL-2.007 only issue. > > > --Chris > > > > On 6/16/2015 09:36, Marek Gierliński wrote: > > OK, thank you for your explanations. I'm not sure if all of this > makes sense. If you try > > print $s > 5; > > in the above example, you will get 'BAD'. 5 is just a scalar and not > a bad value. And $s is a one-dimensional piddle with a value different from > the bad value. Neither of the values in this conditional expression is bad. > Why does it return a string 'BAD'? > > Marek > > On Tue, 16 Jun 2015 at 14:24 Chris Marshall <devel.chm...@gmail.com> > wrote: > > This result seems to violate the principle of least surprise. > On the LHS we have a PDL with badvalue(0) and on the RHS we > have a perl scalar with value 0 (which happens to be the bad > value for the PDL). > > It seems surprising that $pdl > 0 is actually $pdl > > pdl(0)->badvalue(0) > > Thoughts? > Chris > > > > -------- Forwarded Message -------- Subject: Re: [Pdl-general] > Weird behaviour of stats with bad values > Date: Tue, 16 Jun 2015 09:18:29 -0400 > From: Chris Marshall mailto:devel.chm...@gmail.com > To: Derek Lamb mailto:de...@boulder.swri.edu, Marek > Gierliński mailto:marek.gierlin...@gmail.com > CC: pdl-gene...@lists.sourceforge.net > > > > I think the problem is that if $s is a badvalue piddle with the > badvalue=0 > then $s>0 is $s>BAD which is BAD. If you use a value for badvalue > that is > not in the comparison, you should be good. > > --Chris > > > On 6/16/2015 09:11, Derek Lamb wrote: > > Thanks for the simple example. That helps a lot. > > > The actual problem is that piddles with the badflags set always > evaluate to BAD when element-wise logical operations are performed on them. > > > "print $s<0" prints BAD instead of 0 or 1. "print $x>0" also > prints [BAD BAD BAD BAD]. > > > $m and $s have their badflags set (as they should, since they > were made from partially-bad data). You can check if they can be safely > cleared, and clear them if so, with $s->check_badflag, etc. Since $m and $s > are 1-element piddles, you can also just set them directly to their scalar > values, for example > > > map{$_=$_->sclr} ($m,$s)=stats($x); #if you know they are only > going to be 1 element piddles > OR > map{$_=$_->((0))} ($m,$s)=stats($x); #if you just want the first > value > > > > The fact that $m and $s are 1-element piddles is likely what is > causing your problem. My guess is that this behavior has changed (perhaps > intentionally, perhaps not) between your old version and more recent > versions, and if you were getting $m and $s as simple perl scalars before you > would not have seen this problem. I can verify that stats() has returned > 1-piddles and not perl scalars at least as far back as PDL-2.4.11. > > > cheers, > Derek > > > On Jun 16, 2015, at 6:29 AM, Marek Gierliński > <marek.gierlin...@gmail.com> wrote: > > > Oops, sorry, I missed a line when copying the text. Here is the > code again. > > > use PDL; > use PDL::NiceSlice; > > > > > my $x = pdl(1, 2, 3, 0); > $x->badflag(1); > $x->badvalue(0); > > > print "x = $x\n"; > > > my ($m, $s) = stats($x); > > > print "m = $m, s = $s\n"; > print "s greater than zero\n" if $s > 0; > print "s less than zero\n" if $s < 0; > print "s equals zero\n" if $s == 0; > > > > > On Tue, 16 Jun 2015 at 12:20 Chris Marshall > <devel.chm...@gmail.com> wrote: > > Hi Marek- > > Do you have a complete example showing the problem? > You don't show where $m and $s are being set below. > > Thanks, > Chris > > > > On 6/16/2015 07:04, Marek Gierliński wrote: > > I have recently encountered a weird problem with stats (or > statsover) using bad values. The resulting numbers have a strange property, > they always return true in comparisons. This code: > > > use PDL; > use PDL::NiceSlice; > > > my $x = pdl(1, 2, 3, 0); > $x->badflag(1); $x->badvalue(0); > > > print "m = $m, s = $s\n"; > print "s greater than zero\n" if $s > 0; > print "s less than zero\n" if $s < 0; > print "s equals zero\n" if $s == 0; > > > returns the following output: > > > x = [1 2 3 BAD] > m = 2, s = 1 > s greater than zero > s less than zero > s equals zero > > > which doesn't make any sense. Can anyone explain this? I > always assumed that 'stats' returned ordinary Perl scalars, but this must be > something different. > > > I'm using PDL version 2.007. We had an older version > installed for a long time and I think this problem appeared when we upgraded > to 2.007. > > > > Marek > > > > ------------------------------------------------------------------------------ > _______________________________________________ > pdl-devel mailing list > pdl-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/pdl-devel > > > > > > > > -------------------------------------------------------------------------------- > ------------------------------------------------------------------------------ > > > > -------------------------------------------------------------------------------- > _______________________________________________ > pdl-devel mailing list > pdl-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/pdl-devel > ------------------------------------------------------------------------------ > _______________________________________________ > pdl-devel mailing list > pdl-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/pdl-devel ------------------------------------------------------------------------------ _______________________________________________ pdl-devel mailing list pdl-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pdl-devel
