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: Remove oneClass and defaultClass variables. There is a shortcut that can be taken when all the labels are the same, but the Entropy() function does not appear to be working correctly.
govg has joined #mlpack
andrewmw94 has left #mlpack []
sumedh__ has joined #mlpack
sumedh_ has quit [Ping timeout: 264 seconds]
oldbeardo has joined #mlpack
luis_ has joined #mlpack
< oldbeardo>
sumedh__: there?
luis_ has quit [Client Quit]
< oldbeardo>
marcus_zoq: could you help me in making a commit?
< oldbeardo>
I have tested the build with my code included, it works properly
< marcus_zoq>
oldbeardo: Okay, sounds good. So your ready to commit your changes?
< oldbeardo>
marcus_zoq: yes, I just deleted the old code for the same module
< marcus_zoq>
oldbeardo: So you need a step by step guide?
< oldbeardo>
marcus_zoq: sort of, I have some files to add, and I have modified the corresponding CMakeLists
< jenkins-mlpack>
Starting build #1968 for job mlpack - svn checkin test (previous build: SUCCESS)
< jenkins-mlpack>
* siddharth.950: Removing old cosine_tree code.
< jenkins-mlpack>
* sumedhghaisas: * Changes in AMF abstraction, Termination policy is made first template parameter
< jenkins-mlpack>
* fixed minor formatting issues
< marcus_zoq>
siddharth.950
< marcus_zoq>
:)
< marcus_zoq>
oldbeardo: so you can use svn status to check your changes, svn add <file> to add your new files.
< marcus_zoq>
oldbeardo: and as you already did svn commit -m "commit message" to commit your changes.
< marcus_zoq>
oldbeardo: There is no magic behind a simple commit.
< marcus_zoq>
oldbeardo: Right now, you should have received a mail that informs you that you break the build with your change.
< oldbeardo>
marcus_zoq: okay, I will commit the changes within 5 minutes, let's see if the build is successful
< oldbeardo>
marcus_zoq: I get this message
< oldbeardo>
svn: Aborting commit: '/home/mlpack/trunk/src/mlpack/core/tree/cosine_tree' remains in conflict
< marcus_zoq>
oldbeardo: svn resolved cosine_tree
< oldbeardo>
marcus_zoq: svn: '/fastlab/mlpack/trunk/src/mlpack/core/tree/cosine_tree' path not found
< marcus_zoq>
oldbeardo: is this another repo because the path is different? So your removed the cosine_tree with svn rm cosine_tree right?
< oldbeardo>
marcus_zoq: I deleted the cosine_tree folder using the url of the repo
< oldbeardo>
but I want to add the new files to the same folder
< marcus_zoq>
oldbeardo: So you do something like that svn add path/to/the/folder and then svn add new files right?
< oldbeardo>
marcus_zoq: yes, but since the folder does not exist anymore it is having problems adding the files
< marcus_zoq>
oldbeardo: I'm just asking to be clear you created the folder with mkdir folder and after that svn add folder svn add files?
< oldbeardo>
no, I had copied the folder somewhere else, so I just copied it back
< oldbeardo>
marcus_zoq: but yes I did the svn add part correctly
< marcus_zoq>
oldbeardo: Can you move the folder with mv and then use svn mkdir folder to create the folder. Afterwards you move the files into this folder?
< oldbeardo>
marcus_zoq: I did that, I get a warning saying 'cosine_tree is already in version control'
< marcus_zoq>
oldbeardo: And this isn't the right version? You can remove a file from version control with svn rm --keep-local file.
< oldbeardo>
marcus_zoq: I didn't get you, what is the right version?
< marcus_zoq>
oldbeardo: right version = updated version -> The cosine_tree folder with your changes.
< marcus_zoq>
oldbeardo: So if this folder is under version control, you can't just commit you updated files?
< oldbeardo>
marcus_zoq: I don't think so, because I did svn revert and still says that the folder is in version control
< oldbeardo>
marcus_zoq: that was an answer to your earlier question
< oldbeardo>
marcus_zoq: if I try to commit, I get this message
< oldbeardo>
svn: Aborting commit: '/home/mlpack/trunk/src/mlpack/core/tree/cosine_tree' remains in conflict
< oldbeardo>
sorry wrong message
< oldbeardo>
svn: '/fastlab/mlpack/trunk/src/mlpack/core/tree/cosine_tree' path not found
< marcus_zoq>
oldbeardo: Okay, maybe this before you you that make a backup :) 1. svn revert -R . 2. svn update 3. check for the cosine_tree folder
< marcus_zoq>
oldbeardo: Back in a few minutes...
govg has quit [Ping timeout: 252 seconds]
govg has joined #mlpack
govg has quit [Changing host]
govg has joined #mlpack
< oldbeardo>
marcus_zoq: it was a stupid mistake from my side, the folder I was copying had the old '.svn' folder in it
< jenkins-mlpack>
Starting build #1969 for job mlpack - svn checkin test (previous build: FAILURE -- last SUCCESS #1967 8 hr 31 min ago)
< marcus_zoq>
oldbeardo: I'm glad you solved the problem.
< oldbeardo>
marcus_zoq: me too, at least the build hasn't failed till now
< jenkins-mlpack>
siddharth.950: Adding new cosine_tree code.
oldbeardo has quit [Quit: Page closed]
jose__ has joined #mlpack
< jose__>
Hi
< marcus_zoq>
jose__: Hello!
< jose__>
I compiled and installed mlpack with 64bit enabled armadillo. I tried running kernel_pca program on GroupLens100k.csv, sample data file given in mlpack. But it is failing with segmentation fault at memory allocation. i have 16GB RAM
< jose__>
How much RAM do I need to test the program kernel_pca on GroupLens100k data
< marcus_zoq>
jose__: Okay, let me check this should be a memory problem.
< marcus_zoq>
jose__: Your are right, it's a memory problem, matrix dimension (100000 * 10000).
< jose__>
yup
< jose__>
how do I handle if my data file has more than 100000 data points
< jose__>
is there an alternate or its never possible with mlpack
< marcus_zoq>
jose__: The problem is the kernel matrix (kernel_pca_impl.cpp, line 101). Maybe we can find a proper way to workaround this.
< jose__>
the only way I find is to estimate kernel matrix, then its almost new algo implementation
< jose__>
suggest some thing better that takes not more effort to work around
< marcus_zoq>
jose__: Right now, I can't think of a good way to do solve this.
< marcus_zoq>
naywhayare: Maybe naywhayare knows a nice solution.
< jose__>
hope u hv discussed with him
< marcus_zoq>
jose__: At this moment, he's sleeping :)
< jose__>
oops
< marcus_zoq>
Jose__: He's in a different timezone.
andrewmw94 has joined #mlpack
sumedh__ has quit [Ping timeout: 240 seconds]
jose__ has quit [Quit: Page closed]
Anand has joined #mlpack
sumedhghaisas has joined #mlpack
Anand has quit [Ping timeout: 246 seconds]
govg has quit [Ping timeout: 240 seconds]
govg has joined #mlpack
govg has quit [Changing host]
govg has joined #mlpack
< andrewmw94>
naywhayare: I think I have the tests and tree construction working. I still need to test the traverser and sometime when you are free, I want to ask you about a memory management problem I have
< jenkins-mlpack>
Starting build #1970 for job mlpack - svn checkin test (previous build: FIXED)
sumedhghaisas has quit [Ping timeout: 240 seconds]
govg has quit [Quit: leaving]
govg has joined #mlpack
govg has quit [Changing host]
govg has joined #mlpack
sumedhghaisas has joined #mlpack
< naywhayare>
andrewmw94: I am free now
< andrewmw94>
ok. So my question is this:
< andrewmw94>
I have a method softDelete(), which currently does nothing
< andrewmw94>
I want it to delete a node and it's bound object, members etc.
< andrewmw94>
but it needs to leave the child nodes and the points intact
< andrewmw94>
I need to keep the normal destructor as it is, since that is what users will assume they use to delete the RTree
< andrewmw94>
but I'm not sure how to delete just the one node, since calling delete will delete the children as well
< andrewmw94>
does C++ have a nice way to do this?
< andrewmw94>
I guess I could do something like changing all of the pointers to child nodes and points so that they are null and then calling delete on that node?
< naywhayare>
can you explain the reason why you want to delete a node but leave the children intact?
< andrewmw94>
when I split a node, it seemed simpler to just create two new ones and delete the old one, unless it is the root node of course
< naywhayare>
I'm not sure that that would be simpler
< naywhayare>
at least in terms of runtime / number of allocations
< naywhayare>
you could reassign all the children to the two new nodes then delete the old node
< andrewmw94>
I'm not sure either. It eliminates the shuffling of points/nodes to keep them in the right order
< naywhayare>
I think that would work. but that's what you already suggested
< andrewmw94>
the problem with that is that the destructor deletes all of the child nodes, so that you can call it on the root node to delete the whole tree
< andrewmw94>
I think I can just assign all of the pointers to the children so they point to NULL to get arround that though
< naywhayare>
right -- but if you remove all the children of the old node befoee you call the destructor, that should be fine
< naywhayare>
*before
< andrewmw94>
alright, I'll try that then. Thanks
< naywhayare>
yeah, I think that is the best option, if you are not just subtracting points from the old node to create the new node
< naywhayare>
and then keeping the old node as one of the two new nodes
< andrewmw94>
I don't remember why I didn't do it that way originally. Maybe this was just the first way I thought of
< andrewmw94>
or maybe I had a reason. My notes are all messy from debugging
< naywhayare>
either way is fine, but I think keeping the old node might be slightly faster (though I haven't thought through all the details, so my intuition could be wrong)
< andrewmw94>
It seems like it would be, but it also seems like I would have wanted to do it that way unless I thought of a good reason not to do so.
< andrewmw94>
but I can't remember the reason.
< naywhayare>
the potentially big cost is the (possibly) O(N) splitting of the node's points (a std::vector<arma::vec*>, I think) into two other std::vector<arma::vec*> objects
< naywhayare>
but even if you just subtract some points from the first vector into the other vector, the memory costs are about the same. you have to resize both of them
< naywhayare>
which is roughly the same as allocating two new ones, copying points into either of the two new ones, then clearing the original one
< naywhayare>
...I think
< andrewmw94>
yeah... I think it may have just been me being lazy. Like: "I can use existing code to expand two new bounds or I can write my own to shrink a bound"
< marcus_zoq>
andrewmw94: It's always a pleasure to read your blog posts!