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/
sumedhghaisas has quit [Ping timeout: 240 seconds]
< jenkins-mlpack> Project mlpack - nightly matrix build build #472: STILL UNSTABLE in 1 hr 37 min: http://big.cc.gt.atl.ga.us:8080/job/mlpack%20-%20nightly%20matrix%20build/472/
Anand has joined #mlpack
< Anand> Marcus : Any inputs?
< marcus_zoq> Anand: Hello, It looks like the one vs all approach is the easiest thing we can do and perhaps the way to go.
< Anand> Yes, it will work
< marcus_zoq> There is another approach by Dietterich and Bakiri 'Solving Multiclass Learning Problems via Error Correcting Output Codes' in which the classes are partitioned into opposing subsets.
< marcus_zoq> This approach forms the basis of the method by Allwein, Schapire and Singer 'Reducing Multiclass to Binary'.
< marcus_zoq> I think the best thing we can do is to implement at first the one vs all approach and then we can implement the Dietterich and Bakiri approach so the user can choose or compare between this two methods.
< marcus_zoq> What do you think, sounds that reasonable?
< Anand> Yes, I went through the paper you are mentioning about. I think we should go with the one vs all approach as of now. But what about creating a single measure out the measure for each class? Will average work for all?
< marcus_zoq> Anand: I think so, yes.
< Anand> Ok.
< Anand> I will make the implementations today. However, I will think of a better approach than average
< marcus_zoq> Sounds good. Btw thanks for the blog post!
< Anand> :)
< Anand> Btw, is every one using mailing list for updates? No blog posts?
< Anand> Should I also do the same? If you want
< marcus_zoq> I think we have to remind the other students to send weekly reports :) Maybe you can send a email to the mailinglist with a link to the blog post or something like that, if that's okay for you?
< Anand> Yeah fine. I will do that
< marcus_zoq> Great, thanks!
Anand has quit [Ping timeout: 240 seconds]
Anand has joined #mlpack
Anand has quit [Ping timeout: 240 seconds]
sumedhghaisas has joined #mlpack
< sumedhghaisas> naywhayare: Hey ryan, got some time??
< naywhayare> sumedhghaisas: I am really busy until my paper deadline this friday
< naywhayare> if it's quick, I can help now, but otherwise it'll have to be later
< sumedhghaisas> Yeah real quick...
< naywhayare> ok, go ahead
< sumedhghaisas> naywhayare: I wanted to ask why all the functions in update rules are static??
< sumedhghaisas> as in what if I want to add parameters..
< naywhayare> they're static out of convenience, because the update rule classes don't hold any local variables
< sumedhghaisas> In RALS there are parameters which can be maintained in update rules...
< naywhayare> it'd be easy to make them non-static, and I think the NMF (or now AMF) class will support non-static functions just fine
< naywhayare> I think that NMF/AMF hold an instantiated UpdateRules class, so if the HUpdate() and WUpdate() aren't static that's just fine
< sumedhghaisas> yes... just wanted make sure... and there is a parameter in RALS ...
< sumedhghaisas> which needs to be modified after every iteration...
< sumedhghaisas> I was planing to hold that variable in update rule and update it after each WUpdate and HUpdate call...
< naywhayare> yeah, that will probably work just fine
< naywhayare> and if the user wants to set an initial value for that parameter, they can create the RALSUpdateRules class (or whatever it will be called) themselves and set the parameter
< naywhayare> then call the AMF constructor that takes an instantiated update rule
< sumedhghaisas> yes... and that update rule can be passed to AMF...
< naywhayare> yeah, exactly
< sumedhghaisas> okay... And best of luck for your paper submission :)
< naywhayare> thanks... lots of work to do :(
sumedh_ has joined #mlpack
sumedhghaisas has quit [Ping timeout: 240 seconds]