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/
sumedh__ has quit [Ping timeout: 240 seconds]
Anand has joined #mlpack
Anand has quit [Ping timeout: 246 seconds]
Anand has joined #mlpack
Anand has quit [Ping timeout: 246 seconds]
sumedh__ has joined #mlpack
Anand has joined #mlpack
< Anand>
Marcus : I am adding a new 'bootstrap' task to run_benchmark.py. Will it be fine>
< Anand>
?
< Anand>
The RunMetrics(..) method now returns a dictionary containing metric name and result
< Anand>
Also I think we should create a separate 'print' task too to print the table we discussed yesterday. Because, it is not a good idea to print metrics for all libraries and all methods when executing 'print' task of a single method
< Anand>
To do this how should I iterate over the methods to call RunMetrics. In instance.RunMetrics(..), how should I loop over the 'instance'?
< Anand>
Sorry, I meant "'metric' task of a single method" not "'print' task of a single method" above!
Anand has quit [Ping timeout: 246 seconds]
Anand has joined #mlpack
< marcus_zoq>
Anand: Hello, yeah let's add a new bootstrap. I think you iterate through all methods, and store the results into a data structure. Afterwards, you can iterate through the data structure.
< marcus_zoq>
Anand: You can write something like: result = instance.RunMetrics(options) results['methodname'] = results.
< Anand>
Marcus : We have this : instance = methodCall(modifiedDataset[0], timeout=timeout, verbose=False)
< Anand>
How to change the method here?
< marcus_zoq>
Anand: Todo what?
< Anand>
To call instance.RunMetrics()
< Anand>
I mean how do we iterate through all methods?
< marcus_zoq>
Anand: The line 'instance = methodCall(modifiedDataset[0], timeout=timeout, verbose=False)' calls the constructor of the specified method. Currently we use the constructor to set the dataset and some other options. You can use this instance to call the metric or the timing method. 'instance.RunMetrics(options)'. The options parameter is a string which contains additional information for the method (e.g rank). The existing code basis already itera
< Anand>
Marcus : You are saying that the current code already iterates through all methods and all libraries?
< Anand>
Ok, then I guess it should be fine.
< Anand>
The data structure for storing the metrics for all methods should be a global then. I can create a dictionary there, probably
< marcus_zoq>
Anand: Yeah, sounds good.
< jenkins-mlpack>
Starting build #2020 for job mlpack - svn checkin test (previous build: SUCCESS)
< Anand>
Marcus : instance.description gives the method name? If not, how can I get the method name for which we ran the metrics?
< marcus_zoq>
Anand: The 'method' parameter contains the method name (e.g. Linear Regression).
< Anand>
So we are taking results for a particular method for all libraries and then moving to a new method, right? (The library for loop is inside the method loop!)
< jenkins-mlpack>
* combined functions IsConverged and Step of termination policies into IsConverged
< marcus_zoq>
naywhayare: Is it more reliable to use a static bool instead of forward a pointer (mat or vec) to an overloaded function. That points to the select points from the dataset or a completely new matrix? I know there are some hints in the mlpack future paper...
< naywhayare>
marcus_zoq: I'm not completely sure what you mean, can you explain more?
< marcus_zoq>
naywhayare: Maybe this makes my question more clear; Instead of returning void the SelectionPolicy could return a pointer. Which could be used to choose between point indexes and completely new points. Maybe this is a horrible idea...
< naywhayare>
marcus_zoq: ok, I see what you mean
< naywhayare>
but the difficulty I see there is that if you are selecting points, it would need to return a pointer to an arma::Col<size_t>, but if you were making new points, it would have to return a pointer to an arma::mat object
andrewmw94 has joined #mlpack
< marcus_zoq>
naywhayare: Right, this is the basic idea, use the return type as decision rule. Is there something wrong, with this idea, except that it is 'against' the design rules?
< naywhayare>
hmmm... how would you use the return type to make the decision? that's the part I don't get
< marcus_zoq>
naywhayare: I thought I can forward the result of the SelectingPolicy::Select(...) to an overloaded function something like: 'Evalutate( arma::mat* ) { /* special treatment for arma::mat */ } Evalutate( ... ) { /* default treatment */ }'
< naywhayare>
ah, I see what you mean
< naywhayare>
that would be a nice solution because it means no static bool is required
< naywhayare>
it doesn't seem like that's overly complex, either, and the SelectionPolicy is simpler than before, so I'd say give it a shot and see if it works
< marcus_zoq>
naywhayare: Okay, so it's not against the design policy because in general we pass the result matrix by reference?
< naywhayare>
yeah, you don't need to pass by pointer if you're using return type overloading; you can just use a reference
< naywhayare>
plus, the design policy guidelines are only valid until they make something impossible. then they have to change :)
< jenkins-mlpack>
Starting build #2021 for job mlpack - svn checkin test (previous build: SUCCESS)
udit_s has joined #mlpack
< naywhayare>
andrewmw94: rectangle_tree.hpp, line 118
< naywhayare>
the constructor that takes a RectangleTree* is being called implicitly to convert the RectangleTree* to a RectangleTree&
< naywhayare>
it's a bit dangerous to leave that constructor there as-is; some user may end up doing the same thing later and winding up with very weird, difficult to debug results
< naywhayare>
so there are two things that you could do: one is mark the constructor explicit; then the compiler will never try to use it for implicit casts
< naywhayare>
the other is refactoring so that either that constructor isn't necessary, or so that it has a different signature
< andrewmw94>
ok. I really don't know which option is best. That constructor could probably be removed entirely, it just makes the splitting of nodes more messy
< naywhayare>
it's your call. if it's only used internally, you could also mark it private
< naywhayare>
where is it used?
< naywhayare>
oh, sorry, I found it. I was searching in the wrong way...
< andrewmw94>
Is there a reason that the splitType isn't a member class of the BinarySpaceTree?
< andrewmw94>
I just copied that design here, but I think it would work to move SplitType and then make the constructor private
< naywhayare>
it probably doesn't need to be a member of BinarySpaceTree, but it wouldn't be a bad idea if a user could pass an instantiated SplitType object to the constructor
< naywhayare>
for whatever reason, that wasn't done when SplitType was factored out
< naywhayare>
if you wanted to file a bug on trac about it, I wouldn't mind, but I see it as pretty low-priority
< andrewmw94>
yeah, I don't think it makes a difference either way for BSP trees. It's slightly nicer if the R tree matches though, and if that's the case, then I can't make the constructor private.
< andrewmw94>
And I can think of any real cases where the use would want to be able to use that constructor.
< andrewmw94>
can't*
< andrewmw94>
big difference
< naywhayare>
what do you mean by "if the R tree matches"?
< andrewmw94>
I mean it's nice to have the design be as similar as possible
< andrewmw94>
so if SplitType is a member class of one, it would be a member class of the other.
< andrewmw94>
although partially that decision was to allow me to copy BinarySpaceTree whenever I didn't know how MLPACK worked
< naywhayare>
I wouldn't be too worried about that
< naywhayare>
the only part of the API that needs to match is the actual functions that the tree provides
< andrewmw94>
yeah. I just never know whether there was a reason for BSP trees to be like that which will come back and haunt me later.
< naywhayare>
still, templatizing SplitType probably isn't a bad idea, in case there are R tree variants that someone might want to use someday that have different splitting mechanisms
< andrewmw94>
Ahh, SplitType is a template, I just don't have it as a member class
< naywhayare>
well, you don't need to have it as a member class; it's only relevant at construction time
< naywhayare>
so no need to hold on to it in the completed R tree (which is what you get back after calling the constructor)
< andrewmw94>
but I need it to be a member class if I want it to be able to access a private constructor that takes a pointer right?
< naywhayare>
oh! we are talking about different things
< naywhayare>
I'm sorry. everything I've said (or most of it) is irrelevant
< andrewmw94>
ahh. I thought I was just really sleepy
< naywhayare>
no, that's probably me
< andrewmw94>
probably both.
< naywhayare>
ok, I see the problem then
< naywhayare>
so, I would say here that just marking the constructor explicit is good enough
< andrewmw94>
ok. I'll leave it like that for now then.
< naywhayare>
the other option is to provide a constructor that takes everything that's necessary to build a ready-to-go R tree node
< naywhayare>
BinarySpaceTree has a constructor like this, which takes the begin, count, dataset, etc.
< naywhayare>
binary_space_tree.hpp:166, or something like that
< naywhayare>
but that may not be relevant in your situation
< andrewmw94>
yeah. Begin and count aren't the same in the R tree so that doesn't really work.
< naywhayare>
yeah, of course -- I was just suggesting a constructor of a similar manner, which takes everything the R tree node needs to be built by the end of the constructor
< andrewmw94>
I'm not sure if I follow
< andrewmw94>
so the effect would be the same as calling the normal constructor right?
< andrewmw94>
but the difference is that you do some of the processing outside of the constructor and give that as input?
< naywhayare>
that's how that constructor is used in the binary space tree
< naywhayare>
but after a little more reading of what you've done, I'm not sure it's applicable to the rectangle tree
< naywhayare>
so for now you are probably best off by just marking the constructor explicit and moving on
< naywhayare>
eventually when you have it working, I'll make a pass over it and we can talk about refactoring (which is usually pretty straightforward) then
< andrewmw94>
Yeah. I'm not sure if something like that's a good idea. It seems like it's begging the user to insert the node somewhere in the tree, which breaks the guarantee that the leaves are all on the same level.
< sumedh_>
/home/sumedh/mlpack_test/amf/termination_policies/svd_complete_incremental_learning.hpp|60|error: prototype for ‘void mlpack::amf::CompleteIncrementalTermination<TerminationPolicy>::Initialize(const sp_mat&)’ does not match any in class ‘mlpack::amf::CompleteIncrementalTermination<TerminationPolicy>’|
< sumedh_>
/home/sumedh/mlpack_test/amf/termination_policies/svd_complete_incremental_learning.hpp|61|error: enclosing class templates are not explicitly specialized|
< sumedh_>
/home/sumedh/mlpack_test/amf/termination_policies/svd_complete_incremental_learning.hpp|61|error: invalid explicit specialization before ‘>’ token|
< naywhayare>
so, it turns out this is not allowed by the standard, as you pointed out
< naywhayare>
I couldn't remember if this case was illegal or if it was another case that was illegal
< naywhayare>
but you can provide an overload for sp_mat in the definition of CompleteIncrementalTermination
< sumedh_>
the first template is assigned to class and the second template is assigned to the function...