11:21 < SinisterMJ> Hi, I need help loading a linear regression model back from harddrive, I just can't get it to work, please.

12:49 < SinisterMJ> anyone here?

13:32 < zoq> SinisterMJ: Hello, are you using the same mlpack version to load the existing model file?

13:32 < SinisterMJ> yes

13:33 < SinisterMJ> http://stackoverflow.com/questions/26015006/mlpack-linear-regression-data-input

13:34 < SinisterMJ> I put everything there with code, but its not too MLPack specific on SO

13:35 < zoq> Okay, I take a look

13:53 < zoq> Are you using the master branch (svn)?

13:58 < zoq> It's a bug in the function which loads the existing model.

13:58 < SinisterMJ> Yes

13:58 < SinisterMJ> Version 1.0.9 though, can't update right now

13:59 < SinisterMJ> Okay, that means what for me?

13:59 < SinisterMJ> Don't understand right now

14:00 < zoq> You can integrate the change on your side or if you can pull the change from the svn repo. Afterwards you need to rebuild mlpack.

14:00 < SinisterMJ> Is the issue fixed in the latest SVN trunk?

14:01 < zoq> once I've commited the change, give me 3 minutes.

14:02 < SinisterMJ> Okay, thanks. Will get the latest version then.

14:08 < zoq> SinisterMJ: Okay, it's fixed in #17187 http://trac.research.cc.gatech.edu/fastlab/changeset/17187 Thanks, for the report.

14:08 < SinisterMJ> Thanks a lot for the quick help!

14:12 < zoq> Sure, hopefully I didn't missed anything :)

14:12 < SinisterMJ> I will try it when my build system is done with it ;) Thanks a ton!

14:12 < jenkins-mlpack> Starting build #2123 for job mlpack - svn checkin test (previous build: SUCCESS)

14:15 < naywhayare> SinisterMJ: I think I'm the only person answering mlpack questions on stack overflow, and I check it less often than I check here or the mlpack mailing list :)

14:15 < SinisterMJ> :) Yeah, on SO there was not even a MLPack tag or similar, so I knew I was busted there

15:46 < jenkins-mlpack> Project mlpack - svn checkin test build #2123: SUCCESS in 1 hr 34 min: http://big.cc.gt.atl.ga.us:8080/job/mlpack%20-%20svn%20checkin%20test/2123/

15:46 < jenkins-mlpack> Marcus Edel: Right now, we can't load a vector, so we load a matrix and extract the last column.

15:47 < SinisterMJ> Funny enough, the latest trunk has another compilation error with VS. Error23error C2864: 'mlpack::tree::XTreeSplit<DescentType,StatisticType,MatType>::MAX_OVERLAP' : only static const integral data members can be initialized within a class\mlpack\src\mlpack\core\tree\rectangle_tree\x_tree_split.hpp33

15:49 < SinisterMJ> This error doesn't touch me, and I fixed it for me by making it non-static, but still fyi

15:50 < naywhayare> thanks

15:50 < naywhayare> I'm testing the fix before committing it

15:50 < naywhayare> the windows build server is down at the moment and I haven't had a chance to look into it

15:52 < naywhayare> so, that fix actually does not work under gcc; I'm going to open a ticket for the issue, and when I am less busy, hopefully I will have a chance to fix it

15:52 < naywhayare> but you have a workaround for now, which is good

15:54 < naywhayare> http://www.mlpack.org/trac/ticket/369

15:59 < SinisterMJ> Okay, that actually did not work. I have added "const double MAX_OVERLAP = 0.2;" to x_tree_split_impl.hpp, now that part works. But I get Linker errors now in the AugLagrangianFunction.

16:00 < naywhayare> linker errors about MAX_OVERLAP or something else?

16:02 < SinisterMJ> Something else

16:02 < SinisterMJ> sec

16:03 < SinisterMJ> Error71error LNK2005: "public: double __thiscall mlpack::optimization::AugLagrangianFunction<class mlpack::optimization::LRSDPFunction>::Evaluate(class arma::Mat<double> const &)const " (?Evaluate@?$AugLagrangianFunction@VLRSDPFunction@optimization@mlpack@@@optimization@mlpack@@QBENABV?$Mat@N@arma@@@Z) already defined in mlpack.lib(lrsdp.obj)\mlpack\Build-VS\src\mlpack\tests\mlpack.lib(lrsdp_function.obj)

16:38 < naywhayare> I have to get lunch, but hopefully I will have an answer for you later on

16:39 < zoq> naywhayare: You are right MAX_OVERLAP dosn't work with clang. I put MAX_OVERLAP outside the class to get it working, but I think there is a better way (constexpr). It looks like we already taked about it :) http://www.mlpack.org/irc/mlpack.20140819.html

16:40 < naywhayare> actually, maybe I have it figured out before lunch

16:40 < naywhayare> SinisterMJ: can you try adding this to lrsdp_function.hpp?

16:40 < naywhayare> template<>

16:40 < naywhayare> void AugLagrangianFunction<LRSDPFunction>::Gradient(

16:40 < naywhayare> const arma::mat& coordinates,

16:40 < naywhayare> arma::mat& gradient) const;

16:40 < naywhayare> I added it at line 99

16:41 < naywhayare> it seems to work on gcc, but I have to go now so I don't have more time to test it right now

16:41 < naywhayare> zoq: ah, we did... I'll get back to you about this after lunch :)

16:41 < zoq> naywhayare: sure

19:26 < naywhayare> zoq: for now switching to constexpr probably won't work since we don't require C++11 at the moment (since Udit never finished the variant of Adaboost that would require C++11 features)

19:27 < naywhayare> SinisterMJ: did you have a chance to try the fix I suggested?

19:27 < SinisterMJ> Sorry, I am in a hotel on a reaally crappy internet

19:27 < SinisterMJ> what fix did you refer to?

19:28 < naywhayare> http://www.mlpack.org/irc/ at 16:40

19:28 < SinisterMJ> ah, okay

19:28 < SinisterMJ> found it in the logs

19:28 < SinisterMJ> lemme test

19:30 < zoq> naywhayare: right, so maybe the easiest solution to fix this is to put MAX_OVERLAP outside the class or to remove static.

19:32 < SinisterMJ> Doesn't it work the same way for GCC, you initialize the const static outside the class, but have it be a class variable?

19:33 < SinisterMJ> Okay, so that code removed one linker error, and there is now one remaining only

19:33 < SinisterMJ> Error52error LNK2005: "public: double __thiscall mlpack::optimization::AugLagrangianFunction<class mlpack::optimization::LRSDPFunction>::Evaluate(class arma::Mat<double> const &)const " (?Evaluate@?$AugLagrangianFunction@VLRSDPFunction@optimization@mlpack@@@optimization@mlpack@@QBENABV?$Mat@N@arma@@@Z) already defined in mlpack.lib(lrsdp.obj)\mlpack\Build-VS\src\mlpack\tests\mlpack.lib(lrsdp_function.obj)

19:36 < SinisterMJ> okay, got everything compiling now

19:36 < SinisterMJ> added

19:36 < SinisterMJ> template<> double AugLagrangianFunction<LRSDPFunction>::Evaluate(const arma::mat& coordinates) const;

19:36 < SinisterMJ> template<> void AugLagrangianFunction<LRSDPFunction>::Gradient(const arma::mat& coordinates,arma::mat& gradient) const;

19:36 < SinisterMJ> on line 98 of the .hpp, and now everything works

19:37 < SinisterMJ> ========== Build: 36 succeeded, 0 failed, 0 up-to-date, 2 skipped ==========

19:37 < naywhayare> oh, right, we need to declare the Evaluate specialization too

19:37 < naywhayare> I'll incorporate that fix (the two specialization declarations in lrsdp_function.hpp) shortly

19:39 < naywhayare> zoq: the only problem with removing the static is that MAX_OVERLAP is used in static functions of XTreeSplit

19:39 < naywhayare> I guess for now the best thing is to just put it outside the class... I will eventually be refactoring that whole thing when I have time

19:40 < zoq> naywhayare: Maybe I missed something but is there a good reason for the parameter/design, because it's used in one function?

19:42 < naywhayare> this is code Andrew wrote that I haven't had a good chance to go through, and I think he did it in a hurry since it was very close to the deadline

19:42 < naywhayare> I think his goal was to allow the user to choose this MAX_OVERLAP parameter, but specify a default value

19:43 < naywhayare> I think the better way to do it may be to make the class non-static and actually hold a maxOverlap member which defaults in the constructor to 0.2

19:43 < naywhayare> but I'm not sure that RectangleTree will work with a non-static XTreeSplit function at this point

19:44 < zoq> naywhayare: yeah, that sounds like a good plan

19:45 < naywhayare> for now I'll commit a quick fix to make it a const double outside of the class, but I'll leave the ticket open until it can be refactored like I suggested or some other equally better solution

19:45 < zoq> okay good

19:46 < zoq> Thanks!

19:49 < naywhayare> okay, fix committed in r17188 and updated the ticket

19:50 < naywhayare> SinisterMJ: I committed the specializations in r17189; thanks for your help in tracking down these two issues!

19:51 < SinisterMJ> Thanks to you guys!

19:51 < SinisterMJ> Saves me loads of time to implement this on my own ;)

19:52 < naywhayare> :)

19:52 < naywhayare> if you have more issues, feel free to report them here, on trac, the mailing list, or wherever :)

19:52 < naywhayare> let me take a minute and get the Windows build slave back online

19:52 < SinisterMJ> Will do, but currently everything seems to work fine. My data doesnt fit with the predictions, but I doubt its your issue ;)

19:52 < naywhayare> which might help prevent future issues like this...

19:56 < jenkins-mlpack> Starting build #2124 for job mlpack - svn checkin test (previous build: SUCCESS)

19:57 < naywhayare> okay, I have the x64 and x32 slaves back online, although the x32 slave isn't configured right and will just fail on everything

19:57 < naywhayare> the x64 slave should work fine though

21:27 < jenkins-mlpack> Project mlpack - svn checkin test build #2124: SUCCESS in 1 hr 31 min: http://big.cc.gt.atl.ga.us:8080/job/mlpack%20-%20svn%20checkin%20test/2124/

21:27 < jenkins-mlpack> * Ryan Curtin: Add explicit declarations of template function specializations for linker fixes

21:27 < jenkins-mlpack> on Visual Studio.

21:27 < jenkins-mlpack> * Ryan Curtin: Move MAX_OVERLAP to be a member in the mlpack::tree namespace to fix errors on

21:27 < jenkins-mlpack> Visual Studio. Thanks to SinisterMJ for pointing this out. #369.