14:10 < govg> det/dtree.cpp : Dimlefterror, righterror, and splitvalue are all giving warnings, this is all right?

15:40 < naywhayare> govg: I think the code is right, but the warnings should probably be fixed regardless

15:40 < naywhayare> can you tell me what the warnings are?

19:33 < govg> Those variables I mentioned, the warnings say they might be used without being initialized

19:34 < govg> Also, @naywhayare, I'm having problems building the package. I updated the AUR package, and it fails on one of the test cases. I'll give you a detailed log tomorrow, but basically, it builds, and during testing, encounters an illegal memory access. I'm not sure if it is something wrong with my machine or not, so I'll look into that.

20:15 < naywhayare> govg: yeah, this is the same thing reported by Li Dong on the mailing list

20:15 < naywhayare> there are a few memory issues that ended up getting released with 1.0.10

20:15 < naywhayare> I've been tracking them down (slowly) one by one and once they're all taken care of I'll release 1.0.11...

20:16 < govg> Oh okay. So I suppose I'll watch out for that, and roll back this to the previous package. Someone commented about the availability of 1.0.10, I should have checked it.

20:17 < naywhayare> I'm not sure how long it will take to get these bugs all hunted down; I've been at it (off and on) for about a month now

20:18 < govg> :

20:18 < govg> :| 1.0.9 doesn't have any of it, right? So that should be the one on the AUR?

20:23 < naywhayare> 1.0.9 has a bug that slows down allknn significantly, and it may also have the same bugs as 1.0.10

20:24 < naywhayare> those bugs that are present in 1.0.10 are generally present in new features (like the decision stump, etc.)

20:24 < naywhayare> and the other test failures are often a result of tolerances simply being too tight for random algorithms

20:25 < govg> Okay ...

20:25 < govg> I'll just hold the updating then.

20:25 < govg> Cause installation fails in the package manager if tests fail.

20:25 < naywhayare> yeah; it's unfortunate because there are so many tests for mlpack and a lot of them are written and tested only on one system

20:26 < naywhayare> so the tolerances might appear fine on one system, but when they are tried everywhere they fail

20:27 < naywhayare> the matrix build ( http://big.cc.gt.atl.ga.us:8080/job/mlpack%20-%20nightly%20matrix%20build/ ) helps with this, but as you can see many of the builds are currently unstable (meaning at least one test is failing)

20:27 < govg> /mlpack/methods/det/dtree.cpp:239:40: warning: ‘dimLeftError’ may be used uninitialized in this function [-Wmaybe-uninitialized]

20:27 < govg> leftError = std::log(dimLeftError) - 2 * std::log((double) data.n_cols)

20:27 < govg> ^

20:27 < govg> That is the error I mentioned, similar with two other variables.

20:27 < naywhayare> that's for 1.0.10, right?

20:27 < govg> *warning, sorry, not error.

20:27 < govg> This is happening even for 1.0.9, which is building as I speak.

20:28 < govg> It did happen for 1.0.10

20:28 < naywhayare> yeah; the dtree code hasn't changed in quite some time

20:29 < naywhayare> I think that warning is a bit misleading because the compiler doesn't recognize that those values won't actually ever be used uninitialized, but let me see if I can think of a better way to write the function so that the warnings aren't there

20:30 < govg> Cool enough. I am also hitting some more warnings in the decision stump code, but I suppose those were patched in 1.0.10.

20:35 < naywhayare> yeah, I did fix several warnings in the decision stump code

20:35 < naywhayare> that needed a bit of work

20:36 < naywhayare> I suppose 1.0.10 was not the best release we have had :)

20:36 < govg> I'll be on the look out for the 1.0.11 release then, cheers!

20:36 < govg> Understood :)

20:36 < naywhayare> yeah; I hope to have it done in a week or two, but it's hard to find the time sometimes

20:37 < naywhayare> if anyone else in the channel wants to help it should be as simple as finding a failing test in the matrix build, figuring out why it's failing (sometimes valgrind shows invalid accesses), and fixing it :)

20:38 < govg> I'll maybe give it a shot tomorrow :P

20:40 < naywhayare> maybe some of them are easy, maybe some are hard... I'm not sure :)

20:49 < naywhayare> ok, those dtree.cpp warnings should be fixed in r17377

20:49 < naywhayare> thanks for pointing them out :)

21:20 < zoq> fixing bugs ... sounds like fun ... let's fix them