verne.freenode.net 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/
kris1 has left #mlpack []
mikeling has joined #mlpack
chenzhe has quit [Ping timeout: 240 seconds]
< zoq>
kris1: There is an issue for that: https://github.com/mlpack/mlpack/pull/487 and in addition someone could just use typeid(object).name() or something similar as a simple indentifier.
trapz has joined #mlpack
< mikeling>
rcurtin: ping
ironstark has quit [Remote host closed the connection]
trapz has quit [Ping timeout: 264 seconds]
trapz has joined #mlpack
trapz has quit [Quit: trapz]
< rcurtin>
mikeling: you have to leave a message, it's not likely that I can help in real-time :)
< rcurtin>
but I am here for a few minutes now :)
< mikeling>
rcurtin: ok, I will leave a message on the GitHub. I jut wondering the relateship between weight, label and number of classes
< mikeling>
for quick , I just want to make the weight have the same length of classes like if we have two classes of data
< mikeling>
we only have two kind of weights, each classes have one weight
trapz has joined #mlpack
< mikeling>
actually, I just think it's more like "if we have two kinds of label, we want two weight for it, each **kind** of label have its correspond weight"
< rcurtin>
no, the weights are for each point not for each class
< rcurtin>
so weights.n_elem should be equal to data.n_elem
< rcurtin>
(not numClasses)
< rcurtin>
does that make sense? so the idea is that each individual observation has some weight, not that each class is weighted differently
< mikeling>
so we still need keep the same length between labels and weights?
< rcurtin>
yes, labels.n_elem should be equal to weights.n_elem
< mikeling>
so? what's the meaning of the weight is 0? I mean if some labels' weight is 0 and some labels's weight is not.
< mikeling>
how we calculate the gain
< mikeling>
in decision stump
< mikeling>
we sum up all the weight and each class's weight.
< rcurtin>
if the weight is 0, then the point should not affect the training result at all
< rcurtin>
the weight is the 'influence' or 'importance' of the point
< mikeling>
how about all the weight is 0?
< mikeling>
when we test it
< mikeling>
we set all the weight as zero
< rcurtin>
if every single weight is 0 then I guess the gain will also be 0... it should be equivalent to if there are no points at all
< mikeling>
ah, make sense! all the things seems clear to me now.
< rcurtin>
ok, great :)
< rcurtin>
I am sure there are papers that talk about weighted decision tree learning, but I don't have a link to one or know a specific one
< rcurtin>
if you searched you could probably find one, but it sounds like you have it figured out either way :)
< mikeling>
yep, thank you for your help!
trapz has quit [Quit: trapz]
vinayakvivek has joined #mlpack
vivekp has quit [Ping timeout: 264 seconds]
vivekp has joined #mlpack
pvsakdn has joined #mlpack
pvsakdn has quit [Client Quit]
pvskand has joined #mlpack
< pvskand>
how should I test mlpack_linear_regression on the tests that have been written?
< pvskand>
bin/mlpack_test -t linear_regression?
< pvskand>
No worries! I figured it out :)
< pvskand>
How to make the ann module? I am trying make mlpack_ann but it's returning error!
shuanak has joined #mlpack
shuanak has quit [Client Quit]
diehumblex has joined #mlpack
aashay has joined #mlpack
shikhar has joined #mlpack
pvskand has quit [Ping timeout: 260 seconds]
shikhar has quit [Ping timeout: 260 seconds]
Nax has joined #mlpack
Trion has joined #mlpack
Trion has quit [Ping timeout: 240 seconds]
thyrix has joined #mlpack
< zoq>
Has anyone checked the DatasetMapperImputerTest test?
< zoq>
It looks deterministic, so I guess there is some error.
Nax__ has joined #mlpack
Nax has quit [Ping timeout: 260 seconds]
travis-ci has joined #mlpack
< travis-ci>
mlpack/mlpack#2061 (master - 96d201e : Tham): The build was broken.
< rcurtin>
zoq: yeah, maybe this is because of what Tham just committed
< rcurtin>
I guess I have to debug that before releasing mlpack 2.2.0 then... hopefully I can get that all done today
< zoq>
rcurtin: Do you plan to include the updated SGD class as well?
Trion has joined #mlpack
furqan has joined #mlpack
furqan has quit [Client Quit]
< rcurtin>
zoq: yeah, I guess I can, it is easy to port
< rcurtin>
I'll have to take a look through the list of all changes between 2.1.1 and now and see which PRs are easy to backport and which aren't
< zoq>
hm, I'm pretty sure it would break the backward compatibility since right now I can't just use SGD as before (e.g. if someone used ``template<typename> class OptimizerType`` somewhere), we could rename the class to SGDType and make an alias.
< rcurtin>
oh, right... in that case, it will be a bunch of extra work to do that, so I will skip that for 2.2.0
< rcurtin>
if we do want to provide that support, it will be easy to backport that as 2.2.1 in the future weeks
< zoq>
rcurtin: I agree
< vivekp>
On top of latest git master, build is failing with someerrors in tests/load_save_test.cpp: https://paste.debian.net/922276/
< zoq>
vivekp: Do you have mlpack header files in /usr/local/include?
< vivekp>
zoq: Yes, I do. Not exactly in /usr/local/include but they are there in mlpack folder in that directory
shikhar has joined #mlpack
< zoq>
vivekp: What is the path?
< vivekp>
Not sure, if it's because I'm building just mlpack_test with make -j4 make_test
< rcurtin>
zoq: vivekp: I know what the issue is, I am about to commit a fix
< rcurtin>
give me 5/10 minutes
< rcurtin>
it is confusing to me why the Jenkins build is not failing when this is a pretty obvious issue that should cause a failure...
< zoq>
rcurtin: I'm not sure vivekp has the same issue we talked about, he can't build the code after the latest commit.
< rcurtin>
yes, this one is a separate issue that I just encountered
< zoq>
ah okay
< rcurtin>
because Tham's PR now uses extern template definitions for Load(), now load_impl.hpp is not included
< rcurtin>
but load_impl.hpp contains Lakshya's new overloads for vectors and row vectors
< rcurtin>
so the fix is to move Lakshya's implementations
< vivekp>
zoq: sorry, had to reboot the system (that multi-job make with multiple sessions running wasn't going well)
< vivekp>
zoq: path is /usr/local/include/mlpack
< rcurtin>
fix pushed
< zoq>
vivekp: I think you can run into some issues if you have some outdated header files in /usr/local/include/mlpack but let's see if the latest commit fixes your problem :)
< vivekp>
Thanks, rcurtin. zoq: Initiating build now
< Nax>
rcurtin: (PR#930) should I create PR for jenkins-conf repo to add Dockerfile or not need yet
< rcurtin>
Nax: I would say, right now that Dockerfile is a nice proof-of-concept but it doesn't do anything to get us closer to having many Docker images we can use, so I don't see a need to include it in the jenkins-conf repo right now
< Nax>
Ok thanks!
Trion has quit [Ping timeout: 240 seconds]
< Nax>
rcurtin: I am working on nuget package. Where should I include its files?
< pvskand>
How to make the ann module? I am trying make mlpack_ann but it's returning error!
< vivekp>
Looks like it's going to take sometime. Halfway through so far :)
< vivekp>
I'll report back when it's done
< zoq>
pvskand: There is no executable for the ann code.
< rcurtin>
vivekp: yeah, the tests can take a long time to build
< pvskand>
zoq: how do I test it then?
< zoq>
pvskand: You could run the tests or write your own executable. The reason we don't provide an executable for the ann code is, there is no single model that you could use.
Trion has joined #mlpack
< vivekp>
rcurtin: build completed successfully. Thanks for the fix.
< rcurtin>
sure, sorry that the build got broken... that's something ideally we should avoid :)
Trion2 has joined #mlpack
Trion has quit [Ping timeout: 260 seconds]
Trion2 has quit [Ping timeout: 256 seconds]
< Nax>
zoq: Thanks!
Trion has joined #mlpack
Trion has quit [Quit: Have to go, see ya!]
trapz has quit [Quit: trapz]
isn0gud has joined #mlpack
travis-ci has joined #mlpack
< travis-ci>
mlpack/mlpack#2063 (master - 5148a92 : Ryan Curtin): The build is still failing.
< rcurtin>
wow, so it turns out there are a huge number of commits to merge for mlpack-2.2.x, I think I am going to have to take some time and figure out the right way to do this
< rcurtin>
cherry-picking commits is a bad idea because it's so easy to miss a few
< rcurtin>
so I guess I will probably not be able to release 2.2.0 today, it may take a little longer
< rcurtin>
plus I have to fix the imputation bug anyway...
< zoq>
rcurtin: Maybe Tham has an idea, I can comment on the issue an ask him what do you think?
< rcurtin>
yeah, sure, go ahead
< rcurtin>
I am trying to debug it anyway because I want to understand boost::spirit :)
< rcurtin>
I think his intention in the end is to replace a lot of the armadillo parsing with boost::spirit, so it would be good if multiple people understood the code
< rcurtin>
actually hang on I think I see the bug
< zoq>
I just glanced over the code and at least for me there are a couple of things that aren't easy to get.
< zoq>
okay :)
< rcurtin>
yes, I think I will also go over the code and try to add some comments
< rcurtin>
and fix the style too, it's very unlike the rest of the mlpack code :)
< zoq>
I agree
< zoq>
but overall a really nice improvement
< rcurtin>
yeah, definitely, a speed boost for loading data is very important since basically every application needs to load data
< rcurtin>
I have a minor concern here, I think I may have discovered that there is some redundant work here that will make the parser scale poorly, but I am not sure yet... if that's the case I'll open an issue and Tham will probably know what to do
< zoq>
Yeah, he is the expert here
< rcurtin>
great... I fixed the first bug and introduced a second one :)
travis-ci has joined #mlpack
< travis-ci>
mlpack/mlpack#2067 (master - 177f076 : Ryan Curtin): The build is still failing.