naywhayare changed the topic of #mlpack to: http://www.mlpack.org/ -- We don't respond instantly... but we will respond. Give it a few minutes. Or hours. -- Channel logs: http://www.mlpack.org/irc/
govg has joined #mlpack
govg has quit [Changing host]
govg has joined #mlpack
andrewmw94 has left #mlpack []
sumedh__ has joined #mlpack
govg has quit [Ping timeout: 244 seconds]
govg has joined #mlpack
govg has quit [Changing host]
govg has joined #mlpack
govg has quit [Ping timeout: 244 seconds]
sumedh__ has quit [Remote host closed the connection]
govg has joined #mlpack
Anand has joined #mlpack
Anand has quit [Ping timeout: 246 seconds]
andrewmw94 has joined #mlpack
< jenkins-mlpack>
Starting build #1965 for job mlpack - svn checkin test (previous build: SUCCESS)
govg has quit [Ping timeout: 255 seconds]
govg has joined #mlpack
govg has quit [Changing host]
govg has joined #mlpack
Anand has joined #mlpack
< Anand>
Marcus : We are not getting probs for any library for logistic regression?
< marcus_zoq>
Anand: There is an option for the matlab method.
< Anand>
Btw, I have added the metrics to shogun and matlab too. I will push them in a while.
< Anand>
Ok. How can we do that for matlab?
< marcus_zoq>
Anand: Just save predictions instead of idx (line 50).
< Anand>
you mean csvwrite('probs.csv',predictions) ?
< marcus_zoq>
Anand: Yeah, right!
< Anand>
Ok. I will add that too. And for the others, I guess we have not yet figured out how to do that?
< marcus_zoq>
Anand: No, I think for the others there is no option to do that.
< Anand>
Ok. In that case, we will not be able to calculate MSE.
< Anand>
Other metrics will be fine
< marcus_zoq>
Anand: We can add a function to calculate the mse with the class prediction.
< Anand>
Yeah, but that is not the correct way to calculate mse, I guess
< Anand>
And btw, I also need to add the logistic regression java file to weka.
< Anand>
And scikit's logistic regression can be imported. It should not be a problem
< Anand>
I think for scikit, there is no difference in linear regression and logistic regression except the name. We use the fit(..) method which is the same for bith
< Anand>
*both
< marcus_zoq>
Anand: Yeah, right just use LogisticRegression instead of LinearRegression. There is also an option to get the probability for the testset.
< Anand>
Yes, predict_proba(X) function will do that
< jenkins-mlpack>
* Marcus Edel: Fix ambiguous math reference error, to pass the test clang.
< jenkins-mlpack>
* Marcus Edel: Assume the response to be the last column of the input file, as pointed out in the description.
< Anand>
Marcus : Ok. Scikit is done!
oldbeardo has joined #mlpack
< oldbeardo>
naywhayare: there?
Anand has quit [Ping timeout: 246 seconds]
< naywhayare>
oldbeardo: yes, I am here
< oldbeardo>
naywhayare: can we directly upgrade to 1.55?
< naywhayare>
do you mean force the minimum version to be 1.55 instead of 1.49?
< oldbeardo>
yes, if we need to change the version, why not change to the latest stable?
< naywhayare>
because that is not necessarily available in all distributions
< naywhayare>
we want to support the largest possible number of boost versions that we can
< naywhayare>
but clearly we can't support 1.48 or earlier anymore because we need Boost.Heap
< oldbeardo>
right, I get it
< naywhayare>
unfortunately, RHEL6 seems to only have Boost 1.48, but, RHEL7 was just released so I am not too worried that RHEL6 will not be able to have the next mlpack version
< oldbeardo>
okay, I also have something working on the Regularized SVD front, do you have time to have a look?
< naywhayare>
it'll be second or third on the list, but I should be able to get to it today or tomorrow
< oldbeardo>
okay, I'll send it by tomorrow then, it needs some commenting
< naywhayare>
you can check it into svn
< naywhayare>
just, if it doesn't build, make sure CMake doesn't try to build it :)
< oldbeardo>
right, is there a tutorial for svn, I haven't checked in anything till now
< naywhayare>
I am here to help if you have problems
< naywhayare>
and it's version control, so if you screw something up, we can always just roll back and fix it :)
< oldbeardo>
heh, okay, right now I'm in the process of installing 1.49, till what time are you here?
< naywhayare>
I'll probably get lunch in an hour or 90 minutes
< naywhayare>
after that, I'll be back for another 4 to 5 hours... basically all day
< oldbeardo>
okay, great
< naywhayare>
also, something I forgot -- we need to modify the first call to find_package(Boost ...) so that it looks for Boost.Heap too
< naywhayare>
I think this should be as simple as adding 'heap' to the call
< oldbeardo>
okay, I see 1.49.0 in the additional versions
< oldbeardo>
should I change that?
< oldbeardo>
the additional versions part
< naywhayare>
honestly I'm not sure that line is necessary anymore
< oldbeardo>
so I'll remove the 'set' line?
< naywhayare>
actually, sorry, we should keep that, but we should update it
< naywhayare>
take a look at FindBoost.cmake (wherever it is located on your system) for more information on it
< naywhayare>
basically, we need to list versions of Boost that might not be known to FindBoost.cmake
< naywhayare>
but... we have no guarantee on what FindBoost.cmake might know, so we should just list all versions between 1.49.0 (our minimum version) and the newest version
< oldbeardo>
this indirectly says that heap is a header only
< naywhayare>
okay; if you look in /usr/local/lib/ (or wherever libboost_*.so files are), do you see a libboost_heap.so (or any filename like that)?
< oldbeardo>
no, I don't
< naywhayare>
okay. the "real" way to check if it's header-only is to look through the Boost.Heap source and see if there are any .cpp files, but that can be a bit time-consuming because grabbing the boost sources (...for every version between 1.49 and now) can be tedious
< naywhayare>
so I think we can reasonably safely assume that boost.heap is header-only
< naywhayare>
so I don't think we need to list 'heap' in the list of libraries for the FindBoost script to search for
< naywhayare>
and I think we can assume that if FindBoost finds any Boost headers at all, then Boost.Heap is available
< naywhayare>
we can revisit this assumption later if someone files a bug... :)
< oldbeardo>
heh, okay, I'm building the source code, let's see if this gives any errors
< oldbeardo>
why does 'decision_stump' give so many warnings?
< naywhayare>
probably because udit or I have not fixed those warnings :)
< oldbeardo>
okay :) what is decision stump by the way?
< naywhayare>
a one-level decision tree
< naywhayare>
it's a weak learner; udit implemented it as a weak learner for use in AdaBoost
< oldbeardo>
aah, stump in that sense
< oldbeardo>
naywhayare: the build works, and so does 'CosineTreeTest'
< naywhayare>
okay, are you ready to check in your changes?
< oldbeardo>
should I do it now? I still have to combine the two classes
< naywhayare>
you can make incremental checkins
< naywhayare>
that often makes it easier to see what happened in the svn history
< naywhayare>
I try to commit small commits when I can
< oldbeardo>
right, is it okay if I do it tomorrow? it's getting kind of late here, had a tiring day
< naywhayare>
sure, that's just fine
< naywhayare>
I think I will still be here when you get up, but I'm not certain
< naywhayare>
so I should be able to help you tomorrow morning
< oldbeardo>
okay, in case you aren't here, I will ask Marcus for help, I will also send you the Regularized SVD code
< naywhayare>
alright
< naywhayare>
feel free to just add the regularized svd code to svn somewhere
< naywhayare>
that may make collaboration on it easier
< oldbeardo>
right, I also wanted to remind you about the Softmax Regression module I had written
< oldbeardo>
our discussion kind of faded away as GSoC started
oldbeardo has quit [Quit: Page closed]
sumedhghaisas has joined #mlpack
< sumedhghaisas>
naywhayare: hey did you had a look at the abstraction? any problems??
sumedh_ has joined #mlpack
sumedhghaisas has quit [Ping timeout: 245 seconds]
govg has quit [Ping timeout: 240 seconds]
govg has joined #mlpack
govg has quit [Ping timeout: 264 seconds]
< sumedh_>
naywhayare: Hey ryan, you free for some time??
< andrewmw94>
naywhayare: is there an easy way to convert from arma::subview_col to arma::col ?
< naywhayare>
sumedh_: I am wrapping one or two other things up before I take a look at your abstraction
< naywhayare>
andrewmw94: you can use unsafe_col() instead of col(), or, whatever function is accepting the subview_col object can be templatized so that it will accept both arma::subview_col and arma::Col
arcane has joined #mlpack
< arcane>
naywhayare, did you have a chance to look at the problem of using ball bound with binary space partition tree ?
< naywhayare>
arcane: if you've seen the logs of the channel, I have a thousand things I am trying to catch up on ... I'm doing my best ...
< arcane>
oh ok ! no problem :) ... I was just wondering.
arcane has quit [Quit: Leaving]
< jenkins-mlpack>
Starting build #1966 for job mlpack - svn checkin test (previous build: SUCCESS)
< sumedh_>
naywhayare: I am sorry.. I slept on the desk... its okay it can wait... its working for right now...
< naywhayare>
sumedh_: that sounds uncomfortable :(
< sumedh_>
naywhayare: not close compared to your situation though :) any way I could help?? anyways sleeping time is over...
< naywhayare>
can you go through and fix the little differences?
< sumedh_>
yeah sure...
< sumedh_>
do you have any specific code?? I will definitely check my own code...
< naywhayare>
yeah, just the stuff you checked in. I haven't had a chance to go through it yet, but one of the things I always do is a style check, and I seem to remember seeing some discrepancies in your code
< naywhayare>
that doesn't mean it's bad code or anything :)
< naywhayare>
just, all for the sake of consistency...
< sumedh_>
yes... For a library this big... it should be done...
< sumedh_>
naywhyare: okay done... Should I make a commit for it??
< naywhayare>
yeah, please do
< sumedh_>
naywhyare: AMF code seemed fine... did you do the changes in that?
< sumedh_>
and sorry about this :( won't happen again...
< naywhayare>
yeah, I went through AMF some time back
< naywhayare>
no, it's really not a problem at all
< naywhayare>
you said you were looking for a way to help, so there's one :)
< sumedh_>
no really ... code looks much cleaner now :)
< naywhayare>
:)
< naywhayare>
I think we should move the termination policy to be the first template parameter and first argument to the constructor
< naywhayare>
that way a user who only wants to specify the termination condition only needs to use one argument to the constructor