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/
< jenkins-mlpack>
Ryan Curtin: First pass: comment standardization, fix header guard names, move .cpp to .hpp
< jenkins-mlpack>
because it's all templated functions.
shiva3791 has joined #mlpack
< shiva3791>
Hi. I have an question. Can I use LogisticRegression with sparse matrixes?
govg has quit [Ping timeout: 244 seconds]
govg has joined #mlpack
govg has quit [Client Quit]
< naywhayare>
shiva3791: currently it is not possible to do that, but I don't think it would be too hard to refactor the LogisticRegression class to also take arma::sp_mat (sparse matrices)
< jenkins-mlpack>
Starting build #1955 for job mlpack - svn checkin test (previous build: SUCCESS)
< Anand>
Marcus : I have added the base py file for logistic regression. I see that the code produces a parameters.csv. What exactly does that file contain?
< oldbeardo>
naywhayare: please reply to my mails whenever you get time
< naywhayare>
oldbeardo: please be patient. I am doing my best to catch up and I have not forgotten your emails
oldbeardo has quit [Ping timeout: 246 seconds]
oldbeardo has joined #mlpack
< oldbeardo>
naywhayare: okay, was just reminding, I'll be patient :)
oldbeardo has quit [Quit: Page closed]
< andrewmw94>
naywhayare: I have a version of the R Tree that seems to be constructed correctly uploaded now. I'm going to get lunch soon, but I'd appreciate it if you could look through it sometime when you are free, paying attention to memory leaks (I keep thinking in terms of java). Also, I'm wondering if you could help me with the method softDelete() in rectangle_tree_impl.hpp:111 .
< andrewmw94>
Basically, I want to use it to delete nodes that I made copies of, but I need to save some of the data such as the points and I don't want to delete the child nodes. I'll take out all of the debugging code I have in it once you read through it and make the requisite changes. No rush though. I'll try to write up the heuristics for X trees and R* trees while I wait
< jenkins-mlpack>
Starting build #1957 for job mlpack - svn checkin test (previous build: SUCCESS)
< naywhayare>
andrewmw94: have you written unit tests for the R tree construction?
Anand has quit [Ping timeout: 246 seconds]
Anand has joined #mlpack
sumedhghaisas has joined #mlpack
< sumedhghaisas>
naywhayare: Hey ryan, you free??
sumedh_ has joined #mlpack
sumedhghaisas has quit [Ping timeout: 240 seconds]
< jenkins-mlpack>
* andrewmw94: bug fix. had n_rows when I needed n_cols
< jenkins-mlpack>
* andrewmw94: bug fixes for memory leaks
< jenkins-mlpack>
Starting build #1958 for job mlpack - svn checkin test (previous build: SUCCESS)
Anand has quit [Ping timeout: 246 seconds]
< andrewmw94>
naywhayare: So I'm looking through the testing code (I haven't written the unit tests) and I don't see any "main" file where I would need to add the names of all the tests I want to run. If I add them to eg. allknn_test.cpp, will they run automatically?
udit_s has joined #mlpack
< naywhayare>
udit_s: your decision stump tests don't actually test anything; they write output to a file
< naywhayare>
can you change them so they use BOOST_REQUIRE_* and BOOST_CHECK_* to test things automatically?
< naywhayare>
andrewmw94: write a new file, rectangle_tree_test.cpp, which is like allknn_test.cpp
< naywhayare>
add the file to the CMakeLists.txt file in the tests/ directory
< naywhayare>
then it will get built into the mlpack_test executable
< udit_s>
I did when I comitted today.
< udit_s>
naywhayare: I pushed code today. I had that fixed.
< udit_s>
naywhayare: or let me check that.
< naywhayare>
udit_s: I don't see any changes to the decision stump test, maybe you forgot to commit that one?
< naywhayare>
andrewmw94: anyway, supposing you name your test suite RectangleTreeTest, you can then run those tests with 'bin/mlpack_test -t RectangleTreeTest'
< udit_s>
naywhayare: oops. yeah, I did. let me just get that.
< naywhayare>
sure, sounds good
< sumedh_>
naywhayare: did you find any bug in SVDBatch code??
< naywhayare>
sumedh_: I am trying to catch up from last week; I have not been able to do that yet
< sumedh_>
ohh okay... Cause I checked again and again... still 1.8 :(
< sumedh_>
naywhayare: Can we go ahead and write a test with 1.8?? the performance is better than current NMF ... accuracy wise atleast.. but taking longer time...
< andrewmw94>
naywhayare: should I put all of them there or should I put the traits in tree_traits_test.cpp?
< naywhayare>
sumedh_: have you tried any other datasets?
< naywhayare>
andrewmw94: yes, put all of the tests in a new file, something like rectangle_tree_test.cpp
< naywhayare>
tree_test.cpp is really long and should probably be split into a few files, so it's probably better to not make it even longer
< sumedh_>
naywhayare: yeah... GroupLens100k... But its not their in the paper.... they have used subsets of MovieLens1M
< sumedh_>
*there
< naywhayare>
okay; what about the netflix dataset?
< udit_s>
naywhayare: done.
< naywhayare>
udit_s: thanks
< udit_s>
naywhayare: also, about the perceptron. You'll see I've left the update weights as a template, which can be extended further as required. I guess that's fine. I was having trouble getting the gradient descent to converge.
< udit_s>
naywhayare: so, I'll start working on the adaboost aspect now ? Reading up and designing ?
< sumedh_>
naywhayare: netflix dataset?? Its too too big... MovieLens1M contains 6000 users.. netflix dataset contains 480,000 users and 20,000... I dont think I have enough computation power to process that dataset:(
< udit_s>
naywhayare: and I also wanted to talk about the mid term evaluation.
< naywhayare>
sumedh_: ok
< naywhayare>
sumedh_: I will try and get to the RMSE issue soon. like I said (and as you can see) I am completely overloaded right now
< naywhayare>
udit_s: I saw your email about the perceptron, but I have not been able to respond
< naywhayare>
since you're a little ahead of schedule, I wouldn't mind if you took a little time to implement another learning algorithm for the perceptron
< sumedh_>
naywhayare: yeah I guess I will be up tonight... so you can ping any time you are free... After the tests for SVDBatch are done I will commit the SVDIncrementalLearning code :)
< naywhayare>
sumedh_: can you take some time and add a template parameter to the AMF code, for the convergence criterion?
< naywhayare>
currently, you're terminating when the change in residue is below tolerance
< naywhayare>
but before, it terminated when the residue itself was below a tolerance
< naywhayare>
we should allow users to choose either of these things (or the slightly weirder SVDBatch condition which is based on the validation RMSE)
< naywhayare>
so a template parameter is probably the right thing to do here
< naywhayare>
so the while() loop in the AMF::Apply() function should be something like 'while(!ConvergencePolicy::IsConverged(...))'
< sumedh_>
naywhayare: yes... I wanted to discuss that... I have currently some working code for that...
< sumedh_>
yes... sort of the same... I am using terminate function there...
< naywhayare>
ok, that sounds good. probably as parameters the IsConverged() policy will need V, W, and H
< naywhayare>
maybe more? not sure
< sumedh_>
yes... you are right... V, W and H will suffice...
< naywhayare>
okay. if you can spend a little time developing that abstraction and at least the two convergence policies we are already using, I'd appreciate that
< naywhayare>
make sure it passes the tests before you check it in. I recently overhauled a lot of the NMF tests