New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
test comparisons between scalars and 0-dim PDLs with badflag == 1 #128
Conversation
0b154bd
to
2cae17e
Compare
Thread on pdl-devel http://thread.gmane.org/gmane.comp.lang.perl.pdl.general/8729/focus=6584 |
Plan for further work is discussed at http://irclog.perlgeek.de/pdl/2015-07-18#i_10918794:
|
Why not just unconditionally I'm also keen to squash together / eliminate failing commits, to ease future bisecting. The bit of primitive.pd you changed looks like it's crying out for a bit of data-driven action. |
This is to elucidate the issues with stat() and per-PDL badvalues brought up by Marek Gierliński in SF#390 <http://sourceforge.net/p/pdl/bugs/390/>, <#124>. When testing the scalar comparison, test across several values on either side of bad value so that it is clear which case is failing. The test must be skipped if BADVAL_USENAN: the test sets `badvalue()`.
Also added a note that the parameter is unused because it is not involved in setting `$badcode` for exceptional cases for each function as intended (e.g., negative values for `sqrt()` would require complex numbers to be returned). This helps move PDL towards using `use strict` everywhere.
When checking for badvalues in binary operators, we need to be sure that each of the operands are not only badvalues, but also **have the badflag set**. This way non-bad PDLs and scalars do not get treated as bad when they are not.
The documentation for `statsover()` states that it ignores badvalues. Since `stats()` calls `statsover()`, this behaviour applies there as well.
Converted the older tests to be data-driven.
When using a comparison operator, inconsistent results can appear when a badvalue is either 0 or 1. This is because {0, 1} is the range of all operators that return a logical PDL. This means that if the input PDL contains badvalues, it can not both represent badvalues that are the result of computing the operator *and* logical values at the same time. This is a continuation of the work addressing the problem brought up in <http://sourceforge.net/p/pdl/bugs/390/>, <#124>.
I squashed and reordered the commits. I want to hold off on the two things you mentioned:
|
test comparisons between scalars and 0-dim PDLs with badflag == 1
This is to elucidate the issues with stat() and per-PDL badvalues
brought up by Marek Gierliński in SF#390
http://sourceforge.net/p/pdl/bugs/390/,
#124.