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>
* andrewmw94: add the missed files.
< jenkins-mlpack>
* andrewmw94: a few miscellanious small changes. Added to CMake.
udit_s has joined #mlpack
cuphrody has quit []
udit_s has quit [Read error: Connection reset by peer]
udit_s has joined #mlpack
govg has joined #mlpack
govg has quit [Changing host]
govg has joined #mlpack
govg has quit [Ping timeout: 265 seconds]
govg has joined #mlpack
govg has quit [Changing host]
govg has joined #mlpack
andrewmw94 has joined #mlpack
govg has quit [Ping timeout: 265 seconds]
sumedhghaisas has joined #mlpack
Anand has joined #mlpack
< Anand>
Marcus : I have made some changes. Have a look now and let me know.
udit_s has quit [Ping timeout: 245 seconds]
< naywhayare>
andrewmw94: sumedhghaisas: sorry about all the Jenkins emails... they should have stopped after last night, and now you should only get emails if your commit breaks something
< naywhayare>
I'm still not sure how Jenkins got your correct emails
< sumedhghaisas>
yeah its fine. :)
< sumedhghaisas>
isnt jenkins connected to my account?? cause I have my email there...
< naywhayare>
jenkins is separate from trac, and it manages user accounts separately
< naywhayare>
I couldn't find a way to integrate the two
< sumedhghaisas>
ohhh....
udit_s has joined #mlpack
Anand has quit [Ping timeout: 240 seconds]
Anand has joined #mlpack
< andrewmw94>
naywhayare: is it ok if I change some things in the allknn_main.cpp file, such as requiring the leafSize to be greater than 0 rather than greater than or equal to 0?
< naywhayare>
andrewmw94: sure, I wonder why the check was >= 0...
< andrewmw94>
yeah, I wanted to check it doesn't use that to represent the default value or something
< naywhayare>
as far as I know it doesn't
< andrewmw94>
also, looking through the code, it appears that the single tree traverser won't work correctly if all of the points are in the root node (ie. there is only one node)
< andrewmw94>
obviously using a tree with so few points is foolish but someone could try to do it
< naywhayare>
I think you're right; probably worth adding a check at the beginning of the traverser or something
< naywhayare>
but I wouldn't worry too much about it... that is pretty unstable code and will probably be overhauled soon, and then overhauled again, and then overhauled again...
< marcus_zoq>
Anand: The code looks good, currently you are writing the tests?
< Anand>
Ok, great! Yes, I am writing the tests. Will push them by tomorrow. I was just doing a dry run for the new code manually to make sure things work fine
< marcus_zoq>
Anand: Sounds like a good plan :)
< Anand>
:)
govg has joined #mlpack
< jenkins-mlpack>
Starting build #1934 for job mlpack - svn checkin test (previous build: FIXED)
Anand has quit [Ping timeout: 240 seconds]
sumedhghaisas has quit [Ping timeout: 240 seconds]
< jenkins-mlpack>
andrewmw94: require kd-trees to have leafSize of at least 1. Add an assert to ensure that the SingleTreeTraverser isn't called on a tree with only one node.
< andrewmw94>
naywhayare: In the BSP tree's singleTreeTraversal code, a fixed number of children, so when you descend you can just get the score for each child. However, with the R tree, you don't know how many children you will have. I think the most sensible way to descend the tree, at least of the obvious methods, is to get the score for each child node, then sort this list, then descend the tree, testing to see if you can prune each sibling b
< naywhayare>
message clipped at "prune each sibling b"
< naywhayare>
but guessing at what you might have written, I think your strategy is reasonable
< naywhayare>
as long as the number of children doesn't get too large, the sorting of the scores won't take too long
< naywhayare>
I think that std::sort is guaranteed to be an O(n log n) sort... but I'm not sure, let's see...
< naywhayare>
(arma::sort would probably be what you want to use, but I think it uses std::sort)
< naywhayare>
(actually, you'd want to use arma::sort_index(), and it does use std::sort, which as of C++11 is required to be worst-case O(n log n), but for C++03 just needs to be expected O(n log n))
govg has quit [Ping timeout: 240 seconds]
< andrewmw94>
I'm confused.
< andrewmw94>
Wouldn't we want to sort the distances, not the arma::*
< andrewmw94>
objects
< andrewmw94>
doesn't score return the minimum distance from the query point to the MBR (assuming nearest neighbors)
sumedhghaisas has joined #mlpack
< sumedhghaisas>
naywhayare: residue in NMF is calculated as...
< sumedhghaisas>
WH = W * H;
< sumedhghaisas>
norm = sqrt(accu(WH % WH) / nm);
< sumedhghaisas>
if (iteration != 0)
< sumedhghaisas>
{
< sumedhghaisas>
residue = fabs(normOld - norm);
< sumedhghaisas>
residue /= normOld;
< sumedhghaisas>
}
< sumedhghaisas>
this is failing when the matrix contains negative entries....
< sumedhghaisas>
exactly how does this work?? is this same as normal RMSE calculation??
< naywhayare>
andrewmw94: sorry, I meant, sort the output of Score(), but store it in an arma::vec before sorting for convenience
< naywhayare>
that's a normal RMSE calculation, but NMF will never converge if you are trying to decompose an input matrix that has negative entries
< naywhayare>
sumedhghaisas: sorry, forgot to address the above message to you
< sumedhghaisas>
okay... But I am using SVD...
< naywhayare>
okay, so what is happening? how is it failing?>
< sumedhghaisas>
what is that acccu function??
< naywhayare>
equivalent to sum(sum(WH % WH))
< naywhayare>
accu(WH % WH) returns the sum of the squared elements of WH
< sumedhghaisas>
umm... its giving normal results for positive matrices...
< sumedhghaisas>
but not with negative entries...
< sumedhghaisas>
okay... there must be some error in my code... I will check again...
< naywhayare>
yeah, that RMSE calculation looks fine to me
< udit_s>
naywhayare: hey !
< naywhayare>
udit_s: hello there
< udit_s>
I've just finished the decision stump...
< naywhayare>
okay, good to hear
< udit_s>
Was hoping you could have a look at it - I'll start optimizations now and documentation tomorrow.
< naywhayare>
sure... do you mind if I wait until after my paper deadline and look at it this weekend?
< naywhayare>
27.5 hours left...
< udit_s>
sure, though I will be joining you on Saturday quite late...
< naywhayare>
okay, sounds good
< naywhayare>
next week I will be a much better mentor than I have been...
< udit_s>
it's actually fine. no really. :)
< udit_s>
I have implemented the bucket binning we talked about (conceptually) - sorting and then gathering into buckets- ranges and all.
< udit_s>
assuming completely non-categorical data
< naywhayare>
great! I'm glad to hear it worked out
< udit_s>
anyways I'll brief you in a mail about the features, and everything else I've modfied.
< udit_s>
all the best for your paper !
< naywhayare>
ok, sounds good; thanks!
udit_s has quit [Quit: Leaving]
< sumedhghaisas>
naywhayare: Finally ... BatchSVD is working ...
< sumedhghaisas>
But its too sensitive to the learning parameter...
< sumedhghaisas>
Probably IncrementalSVD will be better...
< sumedhghaisas>
NMFALS is giving residue of 9 * e-11
< sumedhghaisas>
BatchSVD is giving 6 * e-9...
< sumedhghaisas>
not that bad... advantage would be BatchSVD can also decompose matrix with negative entries...
< sumedhghaisas>
and regularization can be applied....
< naywhayare>
sounds good to me; how do the runtimes compare?
< sumedhghaisas>
umm... SVDBatch more time... can be justified as its a gradient descent variant... BatchWithMomentum will improve that time...
< naywhayare>
okay
< sumedhghaisas>
Should I keep BatchSVD as an update rule??
< sumedhghaisas>
Maybe I will add momentum to it... So BatchSVD will be its special case with momentum equals zero...
< naywhayare>
that sounds like a good idea
< sumedhghaisas>
okay... I should get t it... Paper finished??
< naywhayare>
not even close
< sumedhghaisas>
:(
< naywhayare>
yeah...
< sumedhghaisas>
proofs over??
< naywhayare>
I think I have the proofs correct; I just have to run the numerical experiments...
sumedh_ has joined #mlpack
sumedhghaisas has quit [Ping timeout: 252 seconds]