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/
travis-ci has joined #mlpack
< travis-ci>
mlpack/mlpack#1004 (master - 4fa39b6 : Ryan Curtin): The build was broken.
< zoq>
travis ... hm, I could slightly increase the number of iterations, or use a static starting point.
< rcurtin>
one strategy I have used is to, e.g., try the test three times and make sure it succeeds at least once
< rcurtin>
take a look at the tests for simulated annealing, I think they do this... sa_test.cpp
< zoq>
that's a good idea, thanks for pointing that out
< rcurtin>
sure, glad I could help :)
ajinkya has joined #mlpack
ajinkya has quit [Client Quit]
< marcosirc>
tham: thanks for your feedback! I will try different modifications and see what happens with appveyor...
< marcosirc>
I am thinking how to make NSearch more explicit, without including too many lines of code...
marcosirc has quit [Quit: WeeChat 1.4]
nilay has quit [Ping timeout: 250 seconds]
tham has joined #mlpack
< tham>
marcosirc : I use class to mimic alias template, although not as elegant as alias template, this solution should help you maintain your sanity :)
< tham>
I paste the samples at #693
Mathnerd314 has quit [Ping timeout: 264 seconds]
tham has quit [Quit: Page closed]
nilay has joined #mlpack
< mentekid>
is there a way for the benchmarking system to compare different versions of mlpack?
< mentekid>
Actually, where can I find documentation for the benchmarking system in general?
< nilay_>
zoq tham: if I remove the map options<int, int> and write member functions for each of the class fields, the code looks very redundant. are we sure we want that?
< nilay_>
now that i have started doing it , it looks very weird to me, maybe there is still a better way?
< zoq>
It looks redundant? This are the parameter for the feature extraction class right? https://gist.github.com/zoq/8f3e26c73776a5a30c5b04ec5fe22691 and the rest are the parameters for the StructuredForest class, you don't have to reimplement the feature extraction parameter for the StructuredForest class.
< nilay_>
zoq: yes it does. so we will have just 10 (or 15) methods (member functions) just for these parameters.
< zoq>
Yes, that's right, I don't like the idea to change the behavior of setting the class parameter. I think, it would be weird for a user if we change the setting behavior between classes. If you like you can also provide an interface, to e.g. set the parameter via a Parameter class or something similar.
< rcurtin>
I think it's no problem to have a large number of member functions for parameters; that is how the rest of mlpack works
< rcurtin>
the issue is, in some cases, when you set a parameter with a member function, its value must be validated, so you have to have a method to do that
< rcurtin>
and then for the sake of consistency, it makes sense to have member functions for the rest of the parameters instead of making them public
< nilay_>
rcurtin : i don't get what you mean by your last comment
tham has joined #mlpack
< tham>
nilay_ nilay zoq rcurtin : to reduce redundancy
< tham>
A simple solution is apply private inheritance
< tham>
oops, sorry, it wouldn't work since the user cannot access the member function
< tham>
I think the solution zoq mentiond is worth to give it a try
< rcurtin>
nilay_: I simply meant that we should not make internal class parameters public, because some of the parameters need to be validated after they are set
< tham>
Define a parameter class, set the parameters by it, pass it into the StructuredForest and feature extraction class
< tham>
Let the users set the parameters by member function but not the std::map directly, the benefits are
< tham>
1 : we can make sure the users will not create wrong key
< tham>
2 : we can do the sanity check on the value the user set
< tham>
3 : before/after we return the value, we can do some pre/pos processing on the value
< tham>
In my humble opinion, as a library developer, even reason 1 alone is a strong point to pick it up
< tham>
The drawback of provide better encapsulation is--
< tham>
we need to write more codes
< tham>
We know that in most of the cases, every line of codes are the burden of maintainence, because every line of the codes may bring us bug
< tham>
cause us more times to study the codes, understand what is going on
< tham>
but in this case, I think the benefits are worth
< rcurtin>
tham: when you say "even reason 1 alone is a strong point to pick it up", what do you mean by "pick it up"?
< tham>
rcurtin : I mean, give it a try
< rcurtin>
ah but what is "it" here? :)
< tham>
English is not my mother language, I apologize if my words make you confuse
< rcurtin>
no worries, we can get it figured out :)
< tham>
I should just use pick up?
< rcurtin>
no, "pick it up" is just fine, I am just not sure what "it" is in this case... do you mean, use member functions to set parameters? or std::map?
< tham>
use member function to set parameters, or create a parameters class to set the parameters
< tham>
I think second is better since it could reduce redundancy codes, yet provide some encapsulation
< rcurtin>
okay, I agree :)
< rcurtin>
I think it's definitely true, reason 1 is a very strong reason
< rcurtin>
sorry for the confusion... I thought you meant member functions, I just wanted to make sure before I said I agreed with it :)
< tham>
I think this kind of design choices really do not have a right answer, most of them are come from the experiences of books, some gurus, our ex experiences, knowledge learned from other code bases
< tham>
second I mean create a parameter class to set the parameters
< nilay_>
ok so, how would parameter class look like? we still have to pass the values of our parameters from the main function only.
< tham>
I could write a prototype, please wait a moment