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/
andrewmw94 has quit [Quit: Leaving.]
Anand has joined #mlpack
Anand has quit [Ping timeout: 246 seconds]
alpha has joined #mlpack
< alpha>
hello
alpha is now known as Guest92398
< Guest92398>
just build mlpack
< Guest92398>
ran the sample covariance computation program as `g++ -I/usr/include/libxml2/ first.cpp `
< Guest92398>
had to link against -lmlpack -larmadillo
Guest92398 has quit [Ping timeout: 246 seconds]
andrewmw94 has joined #mlpack
sumedhghaisas has joined #mlpack
< sumedhghaisas>
naywhayare: Hey ryan, should we change the row_iterator and col_iterator too??
< sumedhghaisas>
changing reference to pointer I mean...
< naywhayare>
sumedhghaisas: let's leave that as-is for now, and we can later suggest to Conrad that it could be changed
< sumedhghaisas>
naywhayare: the reason I wanted to do that is... I am currently overloading operator==
< sumedhghaisas>
so for row_iterator its better to compare the pointers to the matrix...
< sumedhghaisas>
but I will just compare it with memory address of the reference for now...
< naywhayare>
yeah, just do that for now. we should keep our changes simple for now, then suggest more complex changes later
< sumedhghaisas>
okay... I think I will be done by tonight... I will send you the code by mail??
< naywhayare>
add the files to arma_extend/ and commit them; that'll be fine
< sumedhghaisas>
ahh yes... I forgot that I am making changes in arma_extend... sure... I will do that...
< naywhayare>
you can also make the changes to arma_extend.hpp so that the row_col_iterator gets included with ARMA_MAT_EXTRA_PROTO and ARMA_MAT_EXTRA_MEAT
< sumedhghaisas>
Yes I already did that for testing...
< naywhayare>
and then you can write tests for it in arma_extend_test.cpp
< naywhayare>
ok, great
< naywhayare>
yeah, the tests for this should be pretty straightforward
< sumedhghaisas>
okay... I am little confused about the test... but I guess I will just read arma_extend_test ...
< sumedhghaisas>
exactly what all should I test??
< naywhayare>
make sure it behaves the same as Mat::iterator
< naywhayare>
so, operator++, operator=, operator==, operator!=, operator-- are all things you should check
< naywhayare>
and you can just make sure it's doing the same thing as Mat::iterator
< naywhayare>
it's a pretty simple test, but half the reason for it is to make sure that if someone changes something later, it'll still work
< sumedhghaisas>
okay... I will right the tests too...
< sumedhghaisas>
and can you just go through the implementation of the complete incremental learning once?? Its mostly correct but still sometimes I make some silly mistakes...
< naywhayare>
sure, I will try to find some time to do that today
< sumedhghaisas>
okay thanks :)
< sumedhghaisas>
naywhayare: this is the implementation of Mat<eT>::row_iterator::operator*()
< naywhayare>
why not just hold the position in the matrix, and then calculate the row or column when it's requested?
< naywhayare>
i.e. row = position % n_rows, and col = position / n_rows (integer arithmetic)
< sumedhghaisas>
I didn't get you...
< naywhayare>
internally you are holding variables row and col
< naywhayare>
why not just hold 'position'
< naywhayare>
and when the user calls operator++(), just increment position
< naywhayare>
when dereferencing, you can just return M.at(position)
< naywhayare>
oh, hang on; you are talking about row_iterator, not your implementation
< naywhayare>
sorry, nevermind then :)
< sumedhghaisas>
ohh okay... row_iterator does not implement col() or row()...
< naywhayare>
yeah -- I thought you were talking about your row_col_iterator
< naywhayare>
sorry about that
< sumedhghaisas>
but there is no difficulty in implementing row() or col() in row_iterator... its anyway holding row and col...
< sumedhghaisas>
yeah I got that :)
< sumedhghaisas>
naywhayare: and mat::row_iterator it2 = t.begin(); is not a valid....
< sumedhghaisas>
I think providing a simple overload can make it work...
< sumedhghaisas>
but again... we can combine these small things and make another request to conrad later :)
Anand has joined #mlpack
< naywhayare>
don't you need to do t.begin_row() for that to work?
< sumedhghaisas>
t.begin() returns pointer to starting position of first row... but it won't work... cause basic iterators of Mat does not store row or col...
< sumedhghaisas>
so cannot copy the position from there...
< sumedhghaisas>
but row_iterator can be initialized from row_col_iterator... its only matter of copying the location...
< sumedhghaisas>
do you think it has any application??
< sumedhghaisas>
maybe if user wants to start a row search from some calculated position ...
< sumedhghaisas>
and that calculated position is calculated using row_col_iterator... :)
sumedhghaisas has quit [Ping timeout: 240 seconds]
< naywhayare>
andrewmw94: it seems like the R tree isn't done yet, so I'm going to pull it from the 1.0.9 release; we can have another release when it is ready to go. does that seem reasonable?
< marcus_zoq>
Maybe udit can rewrite the perceptron to use a row vector instead of column vector, like the naive bayes classifier, so that we don't need to transpose all the time.
< naywhayare>
hmm... the perceptron code I see already uses a row vector instead of a column vector
< naywhayare>
did you mean that it should use a column vector?
< marcus_zoq>
Ah yeah, right.
< marcus_zoq>
So maybe we should change NormalizeLabels ...
< naywhayare>
yeah; I think that will happen when #350 gets solved
< naywhayare>
but that'll break a lot of API, so I'd like to get 1.0.9 out the door first
< naywhayare>
Michael Fox is contributing a revamped SaveRestoreUtility that will break compatibility, so I think the next release will have to be 1.1.0, to give users some warning that reverse compatibility may be broken
< marcus_zoq>
Ah okay, I've changed the necessary lines in the perceptron code, so that it works with the normalization function.
< naywhayare>
ok, do you want to go ahead and commit it?
< marcus_zoq>
It is commit r16859?
< naywhayare>
do you mean the most recent revision? no, I committed r16860 a moment ago
< naywhayare>
I was updating HISTORY.txt... if I forgot anything, feel free to add it
< marcus_zoq>
Sorry: New Revision: 16857
< jenkins-mlpack>
Starting build #2043 for job mlpack - svn checkin test (previous build: SUCCESS)
< marcus_zoq>
I've tried to link to the commit, but trac isn't responding
< naywhayare>
yeah... trac is acting funny at the moment
< naywhayare>
ah, I see the commit now through the email sent to the commit list
< naywhayare>
thanks for fixing that; I hadn't had a chance to test that program very much
< naywhayare>
load average on the Trac machine is 8.05... I'm not sure why
< marcus_zoq>
okay ... the normal load is 0.01?
< naywhayare>
yeah...
< naywhayare>
I don't administrate that system though... I only have an account on it
< naywhayare>
so I can only watch
sumedhghaisas has joined #mlpack
< andrewmw94>
naywhayare: in re. the R tree. Yeah that's fine. I think the R tree is working, but you still need to review it and all. Hopefully the R* tree will be fixed by the end of the day. I have a bug I found when you change the min/max fill stuff to extreme values that I'm working through now. Other than that, it seems to work.
< naywhayare>
okay; so, should I go through rectangle_tree.hpp and rectangle_tree_impl.hpp and take a look?
< naywhayare>
(probably not today, but early next week)
< andrewmw94>
yeah I think so.
< andrewmw94>
I'll be working tomorrow so I can give it another cleanup then.
< andrewmw94>
(assuming I finish this bug with the R* tree)
< naywhayare>
okay, sounds good
Anand has quit [Ping timeout: 246 seconds]
Anand has joined #mlpack
< Anand>
Marcus : Does the scikit perceptron metrics fail bscause the labels are not separated by newlines or is it due to the mapping?
< Anand>
Ok, yes this is the mapping problem indeed!
< Anand>
But, we dont have any thing generic that can give us the true labels that actually exist. We need to parse the train file to extract labels then/
< Anand>
But, we dont have any thing generic that can give us the true labels that actually exist. We need to parse the train file to extract labels then/?
< marcus_zoq>
Anand: Yeah, like we do this in mlpack or weka.
< Anand>
No, actually there was no need to parse files in weka. We had methods to retrieve labels from data instances.
< marcus_zoq>
Anand: Right, so what we can do is, to use the 'X, y = SplitTrainData(self.dataset)' function and then call unique?
< Anand>
Marcus : Yes, we can do this.
< Anand>
Marcus : I have a doubt now! We have the correct true labels for each instance and then we have the predicted labels coming from scikit. Why will these two need mapping?
< naywhayare>
marcus_zoq: ok, shogun 3.2.0 is installed on shoeshine in /opt/shogun/shogun-3.2.0/
< naywhayare>
but I think it's compiled against the wrong python version... hang on
< marcus_zoq>
Anand: Actullay I thought the same thing, so my guess was there is a problem with non continues data because the predicted data doesn't contain the second label.
< Anand>
Marcus : It is not the mapping problem then. May be the accuracy was too less. Should we try after increasing the iterations?
< marcus_zoq>
Anand: Right, it isn't a mapping problem but even if we predict everything wrong, we shouldn't get nan as result.
Anand has quit [Ping timeout: 246 seconds]
Anand has joined #mlpack
< Anand>
Marcus : I need to see what is going wrong. I will do a dry run with the predicted labels and see.
< Anand>
And yes, it cannot be a mapping problem. Something else has gone wrong
< marcus_zoq>
Anand: I get an error if I set predictedlabels = [1, 1, 3] and truelabels = [1, 1, 1] : mpi+=Metrics.MPIArrayClass(all_labels[i], truelabels, predictedlabels)
< marcus_zoq>
IndexError: list index out of range
< Anand>
Marcus : Let me have a look.
< marcus_zoq>
naywhayare: Thanks!
< naywhayare>
marcus_zoq: you need the python3.3 interface, right?
< marcus_zoq>
naywhayare: Right
< naywhayare>
okay... I am recompiling now. should be ready in a few minutes
< naywhayare>
sumedhghaisas: in simple_tolerance_termination.hpp, line 79, c_indexOld can be used without being initialized
< naywhayare>
what should it be initialized to? there aren't enough comments in the file for me to figure out what's going on and make a change, unfortunately
< naywhayare>
reverseStepCount is also not initialized to 0, but I can make that change
< naywhayare>
and the same issue is also in validation_RMSE_termination.hpp, line 98 (c_indexOld isn't initialized)
< naywhayare>
I'm getting this information just by watching valgrind output
< naywhayare>
marcus_zoq: ok, compiled against python3.3; the results are in /opt/shogun/shogun-3.2.0/
< naywhayare>
the python3.3 modules are in /opt/shogun/shogun-3.2.0/lib/python3.3/dist-packages/
< marcus_zoq>
naywhayare: Thanks, I will test everything in a few minutes.
< jenkins-mlpack>
Starting build #2044 for job mlpack - svn checkin test (previous build: SUCCESS)
< naywhayare>
marcus_zoq: let me know if you have any problems; it's not hard to recompile with other flags
< naywhayare>
a bit time-consuming though... there is lots of code in shogun
< marcus_zoq>
naywhayare: Can you reset the permissions?
< marcus_zoq>
naywhayare: 755 should be good :)
< sumedhghaisas>
naywhayare: all can be initialized to zero... sorry for the lack of documentation... I plan to document everything next week...
< sumedhghaisas>
I guess they have to be initialized in Initialize() function... I will do that when I will make a commit of arma_extend...
sumedhghaisas has quit [Remote host closed the connection]
< naywhayare>
marcus_zoq: oops, didn't realize the permissions were wrong
< jenkins-mlpack>
* Ryan Curtin: Ball tree tests for EMST.
< jenkins-mlpack>
* Ryan Curtin: Additional things that have changed. I incorrectly wrote in the last commit
< jenkins-mlpack>
about stuff "I had done" but I'm not sure why, given that each of these
< jenkins-mlpack>
contributions are from people who are other people.
< jenkins-mlpack>
* Ryan Curtin: Some notes on some things I've done.
< jenkins-mlpack>
* Marcus Edel: Fix normalization bug (transpose); Some more comments.
< jenkins-mlpack>
* Ryan Curtin: Point out that there is a known bug.
< jenkins-mlpack>
* Ryan Curtin: Tests for ball trees and BallBound<> by Yash, to solve #250.
< jenkins-mlpack>
* Ryan Curtin: Contribution from Yash to solve #250 and make BallBound usable.
< naywhayare>
can't release until the tests seem to pass... but it takes hours to run the tests... heh
< marcus_zoq>
oh yeah, 5 hours ...
< naywhayare>
worse, the trac server is having a problem and I think the people who run it have left for the weekend...
< naywhayare>
although technically I guess Trac isn't necessary to the release process
< marcus_zoq>
mlpack.org is super slow for me, I guess it's on the same host? The check list for the realease is in track :) And the google webcache dosn't work ...
< naywhayare>
mlpack.org is slow, not just mlpack.org/trac/?
< naywhayare>
those two sites are on separate hosts
< naywhayare>
I can probably get to the checklist by using sqlite3 to manually access a copy of the trac database and dump that particular wiki page... kind of an ugly solution