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>
* Marcus Edel: Use the maxIterartion as template parameter.
< jenkins-mlpack>
* Marcus Edel: Scale the transformed data matrix.
< jenkins-mlpack>
* Marcus Edel: Center the reconstructed approximation and the kernel matrix.
govg has quit [Quit: leaving]
oldbeardo has joined #mlpack
< oldbeardo>
naywhayare: I sent you a mail, I would like to discuss about some problems I was facing
oldbeardo has quit [Client Quit]
sumedhghaisas has joined #mlpack
< sumedhghaisas>
naywhayare: hey sorry for these delay... was busy in interviews... you free right now
< sumedhghaisas>
I read your mail. I will complete everything before tomorrow.
jbc_ has quit [Quit: jbc_]
< sumedhghaisas>
naywhayare: and I am getting jenkins build mails all the time :(
oldbeardo has joined #mlpack
< oldbeardo>
sumedhghaisas: hey, you wrote svd_wrapper, what is it supposed to do?
< oldbeardo>
naywhayare: please ping me once you are here
< sumedhghaisas>
oldbeardo: it is basically wrapper for all SVD factorizers which are incompatible with CF module...
< sumedhghaisas>
I was thinking of adding QUIC_SVD and regularized SVD to iy...
< sumedhghaisas>
currently it just supports arma::svd...
< oldbeardo>
oh okay, no need for that, I have already written an Apply() method for Reg SVD
< oldbeardo>
writing one more for QUIC SVD
< sumedhghaisas>
oldbeardo: ohh okay then... I will just keep it for arma::svd
< sumedhghaisas>
oldbeardo: have you talked anything about cf_main to naywhayare
< oldbeardo>
sumedhghaisas: no I haven't, I just got a net connection today
< sumedhghaisas>
ohh okay...
< naywhayare>
oldbeardo: sorry for the slow response, I am awake now
< naywhayare>
I sleep in on the weekends :)
< naywhayare>
sumedhghaisas: which jenkins emails are you getting? I don't think it should be sending you any emails now
< oldbeardo>
naywhayare: no problem, I have one issue that I wanted to talk about
< oldbeardo>
naywhayare: if you see my mail attachment, I can talk to you about it
< naywhayare>
sure, go ahead... I might respond a bit slow since I am preparing breakfast
< naywhayare>
ok, let me download the attachment
< oldbeardo>
naywhayare: if you look at the update code in cf_impl.hpp
< oldbeardo>
I have slightly modified GetRecommendations()
< oldbeardo>
*updated
< oldbeardo>
this has been done with a template specialization of FactorizerTraits defined in cf.hpp
< oldbeardo>
now, this builds fine when I do a make
< naywhayare>
okay, I see the new FactorizerTraits class and how it's used
< oldbeardo>
but when I compile the code using CF with Reg SVD, it fails because Reg SVD does not have an Apply() function with the data taken in as sp_mat
< naywhayare>
ah, right... so, here is what is happening
< oldbeardo>
I tried to work around this by making a template of Apply() with a typename MatType
< naywhayare>
despite the fact that at compile-time it can be determined that the Apply() function with sp_mat will never be called, the compiler is still trying to instantiate it
< naywhayare>
so the thing to actually do is to have a "helper" template function that actually calls the right Apply()
< naywhayare>
take a look at neighbor_search/neighbor_search_impl.hpp
< naywhayare>
there's a problem of the same sort: a constructor of a tree needs to be called, but the signature depends on some traits of the tree
< naywhayare>
so there are these two templatized BuildTree() functions
< naywhayare>
the last argument to these, the 'boost::enable_if_c<...>', is SFINAE which ensures that the right version of the function is instantiated for the right TreeType
< naywhayare>
so if RearrangesDataset is true (which of course is known at compile-time), then the compiler can't instantiate the second version of BuildTree() and it will ignore it
< naywhayare>
if it's false, the compiler can't instantiate the first version and it will ignore that one
< naywhayare>
so I think you can adapt this pattern to your case by having something like two ApplyFactorizer() functions, which use boost::enable_if_c<...> with IsCleaned as the condition
< naywhayare>
let me know if I can give a better explanation of SFINAE or what's actually going on and why the BuildTree() stuff works... this is "weird template" territory so it gets really complex really fast :)
< oldbeardo>
okay, yes this is a bit confusing, but as far as I understand, I will have to make two functions for this
< oldbeardo>
and this will go into CF, right?
< naywhayare>
yeah, probably member functions of CF
< oldbeardo>
okay, thanks, I dealt with this in the code that I provided by making cleanedData an arma::mat, but that's not a good solution
< naywhayare>
hm, so there is actually another solution
< naywhayare>
we can make cleanedData of type arma::mat when IsCleaned is true
< naywhayare>
and of type arma::sp_mat otherwise
< naywhayare>
but that's a bit trickier
< naywhayare>
do you think that would be a better solution?
< sumedhghaisas>
naywhayare: I am getting mails since a week now...
< sumedhghaisas>
lot of them...
andrewmw94 has joined #mlpack
< naywhayare>
sumedhghaisas: for which build?
< sumedhghaisas>
:)
< oldbeardo>
yeah, this one seems a bit complicated
< naywhayare>
oldbeardo: actually, I think it's easier than I thought
< sumedhghaisas>
I deleted them all ... I will tell you if I get more...
< oldbeardo>
naywhayare: how's that?
< naywhayare>
sumedhghaisas: ok. there were some issues this week but they are resolved now, so you should only get emails if you actually break the build, hopefully :)
< sumedhghaisas>
okay :
< naywhayare>
oldbeardo: add a type to FactorizerTraits, which right now just contains a bool IsCleaned
< naywhayare>
add something like 'typedef MatType arma::sp_mat'
< naywhayare>
and then when IsCleaned is true, you can have 'typedef MatType arma::mat'
< oldbeardo>
naywhayare: actually there will be an issue with that solution
< sumedhghaisas>
okay.. since siddharth is implementing his own Apply functions I have changed SVDwrapper to ArmaSVDwrapper
< naywhayare>
oldbeardo: oh, did I overlook something?
< oldbeardo>
naywhayare: .n_nonzero is used for estimating rank, which is not a member of arma::mat
< naywhayare>
ah, I see; in the case of dense matrices, then, I guess you just use n_cols?
< naywhayare>
for that problem we could use an SFINAE solution, like BuildTree(), for calculating the rank
< naywhayare>
actually just simple template specialization will work, no SFINAE needed
< naywhayare>
hm, actually you don't even need templates...
< naywhayare>
size_t EstimateRank(arma::mat&) { // use n_cols }; size_t EstimateRank(arma::sp_mat&) { // use n_nonzero }
< sumedhghaisas>
oldbeardo: naywhayare: what is IsCleaned?? just little confused...
< oldbeardo>
naywhayare: I guess a BuilTree() like solution would be easier for .Apply()
< oldbeardo>
*BuildTree()
< jenkins-mlpack>
Starting build #2098 for job mlpack - svn checkin test (previous build: SUCCESS)
< oldbeardo>
sumedhghaisas: I made a templatized class called FactorizerTraits which has a variable called IsCleaned
< sumedhghaisas>
for CF
< sumedhghaisas>
??
< oldbeardo>
this will determine whether to use factorizer.Apply(cleanedData) or factorizer.Apply(data)
< oldbeardo>
yes
< sumedhghaisas>
ohh okay...
< naywhayare>
oldbeardo: I'm not sure a BuildTree() solution is actually easier for Apply() because there is still the problem of which matrix type to hold for CF
< oldbeardo>
naywhayare: we always need cleanedData, for GetRecommendations to work
< oldbeardo>
it is used in the algorithm written in the module
< naywhayare>
right, but if IsCleaned is true (i.e. if the user is using your implementation of regularized SVD), then they'll pass an arma::mat; otherwise they'll pass arma::sp_mat
< sumedhghaisas>
I was just changing cf_main to accomodate all the factorizers... I will do that after you commit the code... that way it will be simpler...
< oldbeardo>
naywhayare: I think the user always passes arma::mat
< oldbeardo>
naywhayare: arma::sp_mat is created within the module
< naywhayare>
oldbeardo: yes, you are right, I see
< naywhayare>
then perhaps you are right that the BuildTree()-like approach is the best
< oldbeardo>
okay, I'll get on it then
< sumedhghaisas>
naywhayare: oldbeardo: I think there should some way for user to pass data cleaned by his way...
< sumedhghaisas>
cause some users may processes data in different ways...
< naywhayare>
sumedhghaisas: maybe an empty factorizer that doesn't do anything plus calling CleanedData() to modify the internally held arma::sp_mat?
< sumedhghaisas>
naywhayare: I didn't get you...
< naywhayare>
maybe a user who wants to clean data his own way can do something like this:
< naywhayare>
where NothingFactorizer doesn't actually do anything, and would be used in cases where the user wants to supply their own cleaned data
< naywhayare>
is that what you meant? or maybe I misunderstood?
< sumedhghaisas>
humm... true but this is little odd.. but can we do something like this...
< sumedhghaisas>
CF<AnyFactorizer> cd(data,...);
< sumedhghaisas>
cf.CleanedData() = cleaned_data;
< naywhayare>
yeah, you could do that, it would just take longer because whatever factorizer is being used will still be run
< sumedhghaisas>
yes thats right... user wants to use CF but with his own cleaned data....
< sumedhghaisas>
cause currently CF supports no preprocessing...
< sumedhghaisas>
naywhayare: okay I checked every factorizer and termination policy again again... and also the tests are passing... how should I add them to cf_main??
< sumedhghaisas>
user should be given option to choose any termination policy with any update function right.. but what about special termination policies like complete_incremental_termination??
< naywhayare>
sumedhghaisas: I don't know if we need to make the termination policy accessible to the user
< naywhayare>
the idea is that the CF program is simple and doesn't have a million options like the C++ code :)
< naywhayare>
so maybe it's better to just give the user the choice of "use SVD", "use regularized SVD", "use complete incremental SVD", "use incomplete incremental SVD"
< naywhayare>
with no mention of which termination policy to use... you could just use the default for that factorizer type
< naywhayare>
what do you think?
< sumedhghaisas>
okay so we make simple_tolerance_termination default??
< naywhayare>
yeah, that sounds good to me
< sumedhghaisas>
okay... I think siddharth is still making some changes... I think the cf_main is going to be changed completely :)
< sumedhghaisas>
naywhayare: okay lets see if I am able to add just one initialization policy to AMF... paper mentions that its better than random initialization...
< sumedhghaisas>
it requires a random noise uniform distribution...
< sumedhghaisas>
any MLPACK function for creating such a distribution??
< naywhayare>
just a uniform distribution? you could use the randu() functions for armadillo matrices
< naywhayare>
I'm not sure I completely understand what you mean
< sumedhghaisas>
okay... Do you have that paper with you?? the one with SVD Bacth and Incremental learning??
< naywhayare>
let me pull it up
< sumedhghaisas>
on page 4...
< sumedhghaisas>
last paragraph...
< naywhayare>
yeah, you can just use randu() for n(r)
< naywhayare>
randu() * r, that is
< sumedhghaisas>
r is the range right??
< naywhayare>
yeah
< sumedhghaisas>
and how will I test this initialization function??
< sumedhghaisas>
cause I think there are no tests for intialization functions...
< sumedhghaisas>
I mean ... for RandomInit and RandomAcolInit
< naywhayare>
yeah, the guy who wrote them did not write tests for them...
< naywhayare>
you could test this initialization function by taking the average of all values in the initial matrix and making sure it is close to sqrt((V - a) / f)
< naywhayare>
like equation 7 without the noise
< sumedhghaisas>
okay... assuming noise is negligible...
< sumedhghaisas>
naywhayare: another issue... they mention 'a' as lower bound... its not same as lowest value of the matrix right?? so either we have to take it from user or in this case just use the lowest value...
< sumedhghaisas>
what do you think??
< naywhayare>
I think we can just use the lowest value
< jenkins-mlpack>
Starting build #2099 for job mlpack - svn checkin test (previous build: SUCCESS)
< sumedhghaisas>
naywhayare: currently testing framework of MLPACK does not show which test is running... just shows how many tests are being run... also the log output is also reflected on the same terminal window... it can be made better.. for my little library I output the tests like this...
< sumedhghaisas>
Running 26 test cases...
< sumedhghaisas>
Starting test NormalParsingTest... [PASSED]
< sumedhghaisas>
Starting test MultipleArityErrorTest... [PASSED]
< sumedhghaisas>
Starting test StratifiedNegationTest... [PASSED]
< sumedhghaisas>
Starting test StratifiedRecursionTest... [PASSED]
< sumedhghaisas>
Starting test HeadSafetyTest... [PASSED]
< sumedhghaisas>
Starting test NotSafetyTest... [PASSED]
< sumedhghaisas>
Starting test OrBoundTest... [PASSED]
< sumedhghaisas>
Starting test BaseDependencyTest... [PASSED]
< sumedhghaisas>
Starting test InputDependencyTest... [PASSED]
< sumedhghaisas>
Starting test InitDependencyTest... [PASSED]
< sumedhghaisas>
Starting test LeaglDependencyTest... [PASSED]
< sumedhghaisas>
Starting test RoleUndefinedTest... [PASSED]
< sumedhghaisas>
Starting test LegalUndefinedTest... [PASSED]
< sumedhghaisas>
Starting test TerminalUndefinedTest... [PASSED]
< sumedhghaisas>
Starting test GoalUndefinedTest... [PASSED]
< sumedhghaisas>
Starting test NormalReasonerTest... [PASSED]
< sumedhghaisas>
Starting test QuestionTest... [PASSED]
< sumedhghaisas>
Starting test OrQuestionTest... [PASSED]
< sumedhghaisas>
Starting test NotQuestionTest... [PASSED]
< sumedhghaisas>
Starting test DistinctQuestionTest... [PASSED]
< sumedhghaisas>
Starting test RecursiveDependencyTest... [PASSED]
< sumedhghaisas>
Starting test EraseTest... [PASSED]
< naywhayare>
I thought you could set Boost program options to give more output like that
< sumedhghaisas>
Starting test Question1Test... [PASSED]
< sumedhghaisas>
Starting test Question2Test... [PASSED]
< sumedhghaisas>
Starting test CreateDSTest... [PASSED]
< sumedhghaisas>
Starting test LoadDSTest... [PASSED]
< sumedhghaisas>
*** No errors detected
< sumedhghaisas>
[100%] Built target test
< sumedhghaisas>
do you think we should add the same to MLPACK??
< oldbeardo>
naywhayare: sumedhghaisas was there a reason for removing 'data' form the CF class?
< naywhayare>
is that standard boost test functionality?
< sumedhghaisas>
I redirect all the other output to a separate log file
< oldbeardo>
*from
< sumedhghaisas>
no... I added simple header file to do all this stuff.. its not that complex...
< naywhayare>
can you point me to the file you used so I can take a look?
< naywhayare>
oldbeardo: I think it is because that was only used in the constructor, once we shifted the factorization to the constructor
< sumedhghaisas>
sure should I send it to you?? or you can take a look at it in my git codebase...
< oldbeardo>
naywhayare: okay, but Reg SVD will need it to operate, should I put it back?
< naywhayare>
I can look in git, just tell me where
< naywhayare>
but regularized SVD is done entirely at the time of the constructor
< naywhayare>
so if the data matrix is held as a temporary in the constructor, then there is no problem
< oldbeardo>
well, I will be calling ApplyFactorizer(), so that will need 'data' to be present as a class member
< sumedhghaisas>
naywhayare: okay.. its in repo libgdl... src/libgdl/tests/libgdl_test.cpp and libgdl_test.hpp
< naywhayare>
just add data as an argument to ApplyFactorizer()
< sumedhghaisas>
there I define some preprocessor directives... I add them to every test...
< oldbeardo>
naywhayare: that will complicate things a little, how will I know whether to call it with 'data' or 'cleanedData'?
< naywhayare>
call it with both, and then in ApplyFactorizer(), just use the appropriate one
< oldbeardo>
sorry, that was dumb, I can always call it with just 'data', since cleanedData is already a part of the class
< naywhayare>
that works too
< oldbeardo>
naywhayare: how do I declare ApplyFactorizer() in cf.hpp?
< naywhayare>
with the exact same signature as you did in cf_impl.hpp
< naywhayare>
but you don't need to specify the default argument (the '= 0' part)
< oldbeardo>
naywhayare: I already tried that, it gives me this:
< naywhayare>
hang on... I think that maybe ApplyFactorizer() can't be a member of CF
< naywhayare>
I think that for any given FactorizerType, the compiler will try to instantiate all member of CF<FactorizerType> and issue an error if it can't...
< naywhayare>
whereas if ApplyFactorizer() is a standalone function and the compiler can't instantiate one overload, it's okay
< naywhayare>
templates are weird... :(
< naywhayare>
I have to step out for a few minutes... I will be back later
< jenkins-mlpack>
saxena.udit: Decision Stumps modified, along with adding Classify() function to AdaBoost. Other minor changes (renaming).
< oldbeardo>
naywhayare: sorry, was having dinner
< naywhayare>
not a problem, I was just letting you know I was back :)
sumedhghaisas has quit [Ping timeout: 272 seconds]
sumedhghaisas has joined #mlpack
< oldbeardo>
okay, how should I make that work? you said it cannot be a part of CF
< naywhayare>
yes, make ApplyFactorizer() a standalone function at the top of cf_impl.hpp
< naywhayare>
then you can call ApplyFactorizer() from the CF implementation, where you would normally be calling FactorizerType::Apply()
< jenkins-mlpack>
Starting build #2100 for job mlpack - svn checkin test (previous build: SUCCESS)
< oldbeardo>
yes, thanks, it got built just before you sent me this
< naywhayare>
ok, cool
< oldbeardo>
naywhayare: I just sent in a new commit, could you have a look?
< sumedhghaisas>
naywhayare: did you look at the code
< sumedhghaisas>
??
< naywhayare>
sumedhghaisas: I was taking a look at Udit's code but I was going to look at yours next
< naywhayare>
oldbeardo: and yours after that
< oldbeardo>
naywhayare: fine, thanks
< sumedhghaisas>
okay no problem :)
< sumedhghaisas>
naywhayare: actually I was talking about the git code... )
< naywhayare>
yeah, that's what I'm looking at :)
< sumedhghaisas>
okay :)
< sumedhghaisas>
naywhayare: I don't think the test for average initialization is checking anything.. cause I am basically writing the same code in the test... while checking I mean...
< naywhayare>
hm. that's not a great test, then, but the test will at least check if the implementation is correct if someone comes along later and changes it
< naywhayare>
I can't think of a better way to test it though
< sumedhghaisas>
yeah that too...
< sumedhghaisas>
its a very small thing to test actually...
< naywhayare>
I like the idea of what you've done in libgdl_test.hpp
< naywhayare>
but I want to spend a little time thinking about the best way to adapt it to mlpack...
< naywhayare>
I don't want to add MARK_START, MARK_FAIL, and MARK_END to every test since there are, I think, thousands of tests (well, maybe many hundreds? not sure)
< sumedhghaisas>
yes sure... Even I want to make it better...
< naywhayare>
we can redirect the Log:: output to a file pretty easily; that's not a problem
< sumedhghaisas>
yeah... I thought about that... I am implementing logging in my library now... so that can be taken care of...
< naywhayare>
I think maybe the right thing to do is make an MLPACK_AUTO_TEST_CASE() macro that just wraps BOOST_AUTO_TEST_CASE() and provides the same type of output that you have in libgdl
< sumedhghaisas>
the only thing remains is the test name and passed , failed...
< sumedhghaisas>
hmm.. thats interesting...
< sumedhghaisas>
thats will also print the test case name...
< naywhayare>
yeah, it's not hard to print the test case name, since we would have it in the macro
< sumedhghaisas>
ahh yes...
< sumedhghaisas>
can we also somehow print the [passed] .. if the test passes...
< naywhayare>
yeah, I think that will be a harder part
< naywhayare>
I'm going to open a ticket for this... hang on
< sumedhghaisas>
naywhayare: okay I checked SVDBatch with average initialization ... works perfectly fine... maybe that can be the test for it?? what do you think??
< naywhayare>
what is it testing, just that averageinitialization gives good results?
< sumedhghaisas>
yeah actually :(
< naywhayare>
ah, okay
< naywhayare>
does it test that the results are (on average) better than randominitialization?
< naywhayare>
that might be a decent test
< sumedhghaisas>
okay i=one sec let me print the residue for both the initializations...
< naywhayare>
yeah, you could just run it with randominitialization a handful of times and make sure that the average initialization residue is a bit better than the random initialization average residue
< sumedhghaisas>
yes... on it..
< sumedhghaisas>
its going to take too much time on my laptop :)
< naywhayare>
maybe you could use a smaller dataset for testing?
< sumedhghaisas>
no its fine... I let it run in the background...
< sumedhghaisas>
there is google unit test framework...
< naywhayare>
yeah, I remember looking at it many years ago when I was choosing a framework
< naywhayare>
that and CppUnit I think
< naywhayare>
I ended up choosing Boost since we were already using Boost, and it seems like a lot of stuff in Boost will eventually become a part of the STL sooner or later anyway... who knows what new stuff they'll add for C++14
< naywhayare>
I don't think Boost.Test is very high quality though...
< sumedhghaisas>
yes... and they are already planning C++17...
< naywhayare>
wow, I didn't know that
< sumedhghaisas>
why?? google testing is better??
< naywhayare>
I haven't worked with Google Test in a long time
< naywhayare>
what I liked about Boost.Test is the easy BOOST_AUTO_TEST_CASE() macro
< naywhayare>
but the documentation is a bit unclear sometimes...
< naywhayare>
there are some pages that aren't even written:
< naywhayare>
so I guess when I say it's not very high quality, I really mean mostly the documentation
< naywhayare>
but it's certainly not bad
< sumedhghaisas>
ohh... even Google APi is good...
< sumedhghaisas>
in place of BOOST_AUTO_TEST_CASE()
< sumedhghaisas>
there is Test(test_case_name, test_name)
< naywhayare>
yeah, it's probably changed a bit over time
< naywhayare>
I can't remember the exact reasons for choosing Boost
< naywhayare>
I wonder if the reasoning is in some ticket somewhere from five years ago...
< sumedhghaisas>
but I don't see any major differences in them.. both are almost same...
< naywhayare>
yeah, maybe I just flipped a coin to choose...
< naywhayare>
I can't find any reasoning that I wrote down, but I didn't look very hard
< sumedhghaisas>
hehe...
< sumedhghaisas>
someone wrote this on stack overflow...
< sumedhghaisas>
3 down vote
< sumedhghaisas>
< sumedhghaisas>
If you are already using Boost libraries, then stick to Boost Test Libs. It should take care of your most of your logging requirements. Otherwise, Google-test is recommended. I've used it in a large project and found it easier to use (error messages are easier to locate, boost uses templates).
< sumedhghaisas>
I have never written complicated tests using either of these two libraries. For simple tests, any of them would do fine. Although google-test will save you some compile time.
< naywhayare>
oldbeardo: your changes look great, that idea for ApplyFactorizer() is the way to do it
< naywhayare>
we ought to add a few comments describing what those functions are for, though
< oldbeardo>
naywhayare: thanks, yes I figured you would say that :)
< naywhayare>
also, another concern I wanted to get your thoughts on... is "IsCleaned" the best way to describe what the condition is?
< oldbeardo>
I will add comments
< naywhayare>
it seems like the actual condition is whether or not the factorizer takes (user,item,rating) tuples as an arma::mat or an actual arma::sp_mat
< naywhayare>
unless I am misunderstanding
< naywhayare>
it seems like whether or not the data is cleaned is a little bit orthogonal to the type of matrix the factorizer takes
< oldbeardo>
you are right, I couldn't think of an alternate name
< naywhayare>
hm, let me go wander around and try to think of something
jenkins-mlpack has joined #mlpack
< naywhayare>
oldbeardo: how about "UsesCoordinateList"?
< naywhayare>
I got the idea from the Wikipedia page about sparse matrices
< naywhayare>
the (row, col, value) format is also called "coordinate list"
< oldbeardo>
that sounds good, I'll make that change tomorrow