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
SF#390 scalar PDL with badvalue always compares BAD with perl scalars #124
Comments
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>.
I have put together some tests on the sf390 branch: I think I may have a direct fix for the problem regarding
The PDL $p in the above stringifies to "[1 BAD 3]" since 2 is now a However, this is the same as the badvalue that was set for the input I feel that setting a badflag as the result of statsover() does not make
That would imply badvalues should not be propagated out of statsover() [^1] https://github.com/PDLPorters/pdl/blob/sf390/t/badvalue_scalar_cmp.t#L97-108 |
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>.
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>.
I wanted to know if this bug was a regression or not, so I used a tool I wrote (in the devops repository on GitHub) and it appears that this bug has been around since at least 2008. |
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>.
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()`.
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>.
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()`.
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>.
This will be in the next full release: PDL v2.013. |
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()`.
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>.
From http://sourceforge.net/p/pdl/bugs/390/
The text was updated successfully, but these errors were encountered: