Perl 6 - the future is here, just unevenly distributed

IRC log for #pdl, 2015-07-18

| Channels | #pdl index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
09:43 jberger joined #pdl
13:12 jberger joined #pdl
19:24 chm joined #pdl
19:26 chm sivoais: I think I see where the problem may be
19:26 sivoais chm: yes?
19:26 chm sivoais: from 07-13 "the badflag from $s is propagated to the output" and "thus $c = $s < 0; # BAD"
19:27 chm apparently, the badflag is being propagated in the output piddle.  The mechanism should
19:27 chm probably be $pdl->check_badflag instead
19:28 sivoais hmm, let me pull up the code
19:29 sivoais this is where the operators are defined <https://github.com/PDLPorters/pdl/blob/master/Basic/Ops/ops.pd#L72>
19:29 sivoais it only sets the badflag if $BADFLAGCACHE() is true
19:30 sivoais gah... SF is still down
19:30 sivoais which means pdl.perl.org is also down
19:32 chm Looking at the biop() you indicate seems like it could be generating the behavior I'm hypothsizing.
19:33 chm I wonder when this bad code has been changed and if/when it worked differently before.
19:33 chm sivoais: How is your git-bisect fu?  (Mine's not so good)
19:35 sivoais I've done it before...
19:35 sivoais chm: if you want, I can test on old PDL releases
19:35 sivoais I found that easier to do
19:36 chm It looks like $ISPDLSTATEBAD(pdl) and  $SETPDLSTATEBAD(pdl) may be of use (from PDL::PP)
19:36 sivoais chm: did you look at my patch?
19:37 sivoais <https://github.com/PDLPorters/pdl/pull/128/files>
19:43 chm sivoais: The problematic result above was from the sf390 branch build.
19:43 chm I'm looking at the corresponding patches you referenced, thanks.
19:43 chm Ideally, we would be able to run the failing tests in master, then apply the patch
19:44 chm and see that things are working.  I'm a bit worried about all the explicit $PDLSTATESETBAD() calls
19:45 sivoais ok, what I can do is cherry pick the tests and create a new branch that lets that run separately to show that the failures are indeed there
19:46 chm I'm taking the test and rebuilding master for reference.
19:46 chm BTW, thanks for the pointer to COS.  It looks pretty cool and I'm working to try it with tcc.
19:46 chm An outstanding issue is whether or not it can be used on windows.
19:47 chm From first study, it seems that the restriction may come from the build system and not the actual C OO code
19:50 sivoais I'll join you in investigating that in a couple weeks. I'm very excited about giving it a spin.
20:10 chm sivoais: master with global badvalue fails 4 of 4 in badvalue_scalar_cmp.t
20:11 chm sivoais: master with bad value per pdl set fails 1 of 4
20:11 sivoais yep
20:11 chm sivoais: sorry, I didn't see that there are subtests.  I'll have to review more closely.
20:11 chm will keep you posted.
20:19 chm sivoais: It appears that in ($m, $s) = stats($x); the badflag is being set in the results
20:19 sivoais chm: yes
20:20 chm even though neither is BAD
20:20 sivoais which is why another part of my patch fixes that
20:20 mohawk this is some complicated stuff :-)
20:20 chm I'm working through to make sure I see the same as you, please be patient
20:21 sivoais I understand and it's not a problem :-)
20:22 sivoais It took a while for me to fix because there were multiple issues that needed to be addressed :-)
20:34 mohawk not to distract from discussing this issue, just placing it on the agenda: i propose that we continue to release despite known problems, if they exist in the last full release
20:38 sivoais they exist in every release going back as far as 2008 :-P
20:47 mohawk right
20:48 mohawk so is there any reason to not release another version(s) while this gets worked on in the meantime?
20:48 mohawk this is an important point of policy
20:48 mohawk so i want to canvas views here before taking it to the list for wider discussion
20:49 sivoais mohawk: well, we haven't had any commits on top of 2.012 yet :-P
20:50 sivoais but we could get those unmerged commits in and the test rewrite
20:50 sivoais what do you think chm?
21:07 mohawk sivoais, i want the principle established first
21:07 mohawk because there are genuine improvements to be made while sf390 is worked on
21:07 mohawk eg the Changes thing
21:11 sivoais well, those are done :-P
21:11 sivoais just pending review
21:12 sivoais really the only thing left to actually do is the split
21:13 chm sivoais, mohawk:  It looks like sf390 fixes all the problems but the one example from 7/13
21:14 chm I suggest merging into master and pushing a devel release from that.
21:14 sivoais chm: should I go ahead and merge?
21:15 chm Seems reasonable to me, mohawk?
21:15 sivoais also, do you have a link to the 7/13 example? Was it on pdl-devel
21:15 chm http://irclog.perlgeek.de/pdl/2015-07-13
21:16 chm sivoais: at the top, my original question
21:16 chm the problem is that the result of a perfectly valid logic operation is being treated as a badvalue.
21:17 sivoais yep, and as I was saying, that's an issue with how the user uses the library
21:17 sivoais instead of badvalue(), they should use setvaltobad()
21:17 sivoais because otherwise 0 will pop out of the calculation
21:18 sivoais and you can't per-element badvalues ;-)
21:18 chm The problem is the forced propagation of the badflag even though neither result is BAD (logic is T/F)
21:18 jberger joined #pdl
21:18 sivoais this gives a more concrete example <http://irclog.perlgeek.de/pdl/2015-07-13#i_10885508>
21:18 sivoais without using comparison
21:18 chm And the cast into a pdl should get that value which is 0 or 1 not BAD or 1
21:19 sivoais if you use BADVAL_PER_PDL, the example passes
21:19 chm if the badflag weren't forced onto the result it would work as well.
21:20 sivoais true, but do we want to special case that?
21:20 chm The badvalue itself is not the issue, the fact that it is *active* in the result is
21:20 chm Why would that be a special case?
21:21 chm BADVALPERPDL just has more badvalues (each pdl possibly) the badflag shouldn't be propagated there either.
21:21 sivoais see the link where I use cos() as an example
21:22 chm Yes, the difference is that cos() is computation and <, >, == are comparison operators.
21:23 chm Not quite the same to me, especially since we map them to do bitwise logic with pdl elements
21:23 sivoais they are also a computation, just a special case that maps to 0 and 1
21:23 sivoais which means we have to check whether a_badval or b_badval are 0 or 1
21:25 chm I think the issue is the default type of the output from the comparison
21:26 sivoais ah, that would make a better solution
21:26 sivoais byte?
21:26 sivoais that's why I made a comment in the mailing list about having a PDL::Logical (that's how R does things)
21:26 chm That makes more sense to me, of course the question is if it breaks things elsewhere
21:27 chm With the new types support planned for PDL3, I was thinking bitfields, directly
21:28 chm As an interim for the release, is there a way to issue a warning when the "surprising" result is comuted?
21:28 chm That would allow for user feedback, could include your other fixes, and let folks weigh in on what works best...
21:29 chm sivoais: I like the warning idea---least risk, moves us forward, and "fixes" the surprise non-intuitive results
21:29 chm warning the user if it pops up so they know what happened.
21:30 chm Of course, a quick check changing the output type for comparisons to see what breaks could be informative.
21:30 sivoais we should probably do a full release with the warning
21:31 sivoais and a dev release with the type change
21:31 sivoais ?
21:31 chm Full release with warning, branch test with type change, then we could push devel if seems viable
21:31 sivoais that way Marek's bug has some sort of fix available
21:32 sivoais sounds good
21:32 chm Sounds like a plan.  Hey I have to go, catch you later and thanks for all your work (hope you have time to write..)
21:32 chm o/
21:32 sivoais o/
21:33 sivoais I'll work on that later in the week. Doing some diagrams now. Adding an issue as a reminder.
21:36 opkick [pdl] zmughal comment on issue #128: Plan for further work is discussed at <http://irclog.perlgeek.de/pdl/2015-07-18#i_10918794>:... http://git.io/vmDET
21:36 opkick [pdl] zmughal comment on issue #128: Plan for further work is discussed at <http://irclog.perlgeek.de/pdl/2015-07-18#i_10918794>:... http://git.io/vmDEL
21:37 jberger_ joined #pdl
21:37 jberger joined #pdl
22:01 mohawk anyway, i am in favour of merging known-good work and dev-releasing
22:21 mohawk and then, and this is critical, actual-releasing it if it's not got worse
22:39 sivoais joined #pdl
23:35 mohawk sivoais, please see channel log

| Channels | #pdl index | Today | | Search | Google Search | Plain-Text | summary