On 2015-07-05 at 20:05:26 +0100, Ed wrote:
> That interpretation of the semantics of "bad" seems reasonable. It
> seems very clear to me that the "badval per piddle" behaviour has
> not been widely used; therefore its behaviour is not widely
> depended-upon; therefore if we apply a reasonable clarification of
> its behaviour, we should be fine; and this clarification seems
> highly reasonable.
>
> Does anybody disagree?
Thanks for the response Ed.
As I posted in the SF bug tracker, I believe I have a final fix for
this.
I had to scale back on my changes from last time. Turns out I didn't
need to think about `BADVAL_PER_PDL`... All I needed to do is check the
badflag and badvalue. This fixed a bug in how *all* binary operations
are handled[^1].
The other fix was to change how the badflag propagates out of
`statsover()`. You can see the details in the PR patch.
Chris, hopefully we can get turn this into the next stable release and
then move on to splitting, Alien-based builds, and the Windows CI
support. I unfortunately won't be able to help out with any of that
until next month.
Cheers,
- Zaki Mughal
[^1]: However, compiling with `BADVAL_PER_PDL` might be a good
idea since there isn't a PDL::Logical subclass. If there was,
allowing the user to set the badvalue of PDL::Logical to 0 or 1
should throw a warning, since that messes with a lot of
assumptions.
>
> -----Original Message----- From: Zakariyya Mughal
> Sent: Saturday, July 04, 2015 8:40 AM
> To: pdl-devel
> Cc: MarekGierliński ; Chris Marshall ; Ed
> Subject: Re: [Pdl-devel] Fwd: Re: [Pdl-general] Weird behaviour of
> stats with bad values
>
> Hi all,
>
> I have done further investigation into SF#390 on the sf390 branch
> <https://github.com/PDLPorters/pdl/pull/128>.
>
> I rewrote the BadCode PP code in `ops.pd` specifically for comparison
> operators (==, >, <, etc.) since, with the previous code, the semantics
> for what to do when only one of the values is bad is unclear under the
> per-PDL badvalues configuration.
>
> The bug is now fixed in builds that use the BADVAL_PER_PDL option
> <https://travis-ci.org/PDLPorters/pdl/builds/69517571>.
>
> In order to fix it for the other badval options, I need some input. I
> currently check the following in a switch[^1]
>
> switch( ( ($ISBAD(a())) << 1 ) | ($ISBAD(b())) )
>
> in order to handle all the cases where each operand might be bad.
>
> Would checking the badflag of each operand as well make sense? The line
> would then become:
>
> switch( ( ( $ISBAD(a()) & $ISPDLSTATEBAD(a()) ) << 1 )
> | ( ( $ISBAD(b()) & $ISPDLSTATEBAD(b()) ) ) )
>
> so that I would check both the badflag and the badvalue for each
> operand. I just want to make sure I'm understanding the semantics
> correctly.
>
> Cheers,
> - Zaki
>
> [^1]:
> <https://github.com/PDLPorters/pdl/pull/128/files#diff-621e73c99459a6921891a9de81d5818aR106>
>
> P.S. Exciting news! I think I may have found a way to test on Windows
> automatically just like Travis-CI. I'd like to start that after the
> split.
>
------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
pdl-devel mailing list
pdl-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-devel
