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/
kaushik_ has joined #mlpack
< kaushik_> rcurtin: hi, just saw you completed the serialization work :)
< kaushik_> I am working on Gaussian Process, but haven't got much time to implement it due to my University work.
< rcurtin> kaushik_: sounds good
< rcurtin> I know how busy university can get, so don't worry, there is no hurry :)
< rcurtin> I am flying home from a weeklong vacation now, so I figured it was a good time to start working on the email backlog :)
< rcurtin> gopala: in case you check the logs, the answer to your question about HMM training labels is that for the mlpack_hmm_train program, you can provide either a single file with labels in CSV (i.e. one label per line) to the --labels_file option
< rcurtin> or if you have multiple sequences you are training on, with a single sequence consisting of an observations file and a labels file, then you can pass the list of observation files (one per line) to --input_file
< rcurtin> and the list of labels files to --labels_file
< rcurtin> I hope this makes sense, if it does not feel free to ask further
< rcurtin> Ramnath: the decision tree format uses boost::serialization to serialize the DecisionTree class; you can just save with --output_model_file file.bin if you are using the mlpack_decision_tree program, for instance
kaushik_ has quit [Quit: Connection closed for inactivity]
rcurtin has joined #mlpack
kaushik_ has joined #mlpack
< zoq> rcurtin: We could add another travis build (clang).
< rcurtin> zoq: maybe a good idea, but it's not too hard to let the matrix build check it after merge and then fix any issues
< zoq> rcurtin: right, maybe we configure the matrix build to send out a mail if something breaks
kaushik_ has quit [Quit: Connection closed for inactivity]
< rcurtin> yes, I should definitely do that
< rcurtin> I keep saying to myself that I will do it once all the builds are passing
< rcurtin> but continue to fail to find the time to fix all of the randon test failures :)
< rcurtin> random*
govg has quit [Ping timeout: 240 seconds]
< zoq> Not sure I get the reason for ignoring the total_timer: https://github.com/mlpack/mlpack/blob/master/src/mlpack/core/util/timers.cpp#L181, since than Timer::Start("total_timer") has no effect.
< rcurtin> I think this is some vestigial code that made sense a long time ago, we should remove that bit
< rcurtin> the original intention was probably to disallow starting that timer twice... but even then the reasoning doesn't fully make sense
< zoq> okay, if there is no reason I'll open another PR.
< zoq> I like the word 'vestigial'
< rcurtin> :)