ChanServ changed the topic of #mlpack to: "mlpack: a fast, flexible machine learning library :: We don't always respond instantly, but we will respond; please be patient :: Logs at http://www.mlpack.org/irc/
< kaushal[m]>
<zoq " kaushal: What version of mlpack"> yes I am using the master branch
swarajpande4 has joined #mlpack
swarajpande3 has joined #mlpack
swarajpande4 has quit [Client Quit]
swarajpande3 has quit [Quit: Leaving]
ImQ009 has joined #mlpack
< AakashkaushikGit>
Hey I was thinking to propose a onnx to mlpack translator and vice versa but i later discovered that a similar [idea](https://github.com/mlpack/mlpack/wiki/OldSummerOfCodeIdeas#mlpack-tensorflow-translator) is in the list of ideas that are not applicable this year and that also has a repo but the work there is not complete and still not robust. So what should i do in this regard?
< jeffin143[m]>
Aakash kaushik (Gitter) Contact sreenik seal
< AakashkaushikGit>
I did text him on LinkedIn but he hasn't responded yet.
< jeffin143[m]>
Aakash kaushik (Gitter): might be caught with something else
< AakashkaushikGit>
Yes i have gome through this and also the work done by @iamshnoo
< AakashkaushikGit>
Gone*
< AakashkaushikGit>
> `jeffin143` Aakash kaushik (Gitter): might be caught with something else
< AakashkaushikGit>
>
< AakashkaushikGit>
Yes that might be the case.
< jeffin143[m]>
If I remember correctly zoq was the go to person for this project
< jeffin143[m]>
Also Atharva Khandait (Gitter)
< AakashkaushikGit>
Hey @zoq if you can shed some light on if this project can still be applicable and what the deliverables might be, that would be really helpful ?
< AakashkaushikGit>
@jeffin143 thanks for the help
< AakashkaushikGit>
So i want to discuss which one should i actually work on and which one would be the most beneficial for the project.
rhyse[m] has quit [Quit: Idle for 30+ days]
hemal[m] has joined #mlpack
Axthe has joined #mlpack
Axthe has left #mlpack []
sakshamb189[m] has joined #mlpack
< AakashkaushikGit>
Also @zoq what are we using for the default `InputType` and `OutputType` in `rnn` class ?
< AakashkaushikGit>
that would be `arma::mat` or `arma::cube` ?
< jonpsy[m]>
hi rcurtin in the ```static_checks.hpp``` we check the if the policy has the correct API or not right?
< jonpsy[m]>
for Multi Objective functions, let's add another API which checks if functiontype has ```Evaluate()``` and ```Shuffle()```
< jonpsy[m]>
do you think its viable? shall i open a PR?
< jonpsy[m]>
* hi rcurtin in the `static_checks.hpp` we assert if the policy has implemented required methods or not right?
< rcurtin[m]>
sure, that sounds good to me
< jonpsy[m]>
cool, btw I was thinking on the refactoring thing right? I like ```static_checks.hpp``` was utilized to confirm if a method exist
< jonpsy[m]>
and then on ```SimulatedAnnealing```, you used the ```CoolingSchecdule``` as policy to ctor
< jonpsy[m]>
to outsource schecduling. I was thinking we could do similar for MOO.
< rcurtin[m]>
that seems fine but I would imagine this type of thing would be specific to an optimizer, not to MOO in general
< jonpsy[m]>
true
< jonpsy[m]>
prob is, each policy of the same type has diff num of args. How would you handle it?
< rcurtin[m]>
I don't understand enough about the issue to say
< jonpsy[m]>
lets say ```CoolingSchecdule```
< jonpsy[m]>
we've implemented 2 classes for this policy. ```FastSchecduler```, ```SlowScheduler```.
< jonpsy[m]>
but ```FastScheduler``` needs ```currentIdx``` and ```currentTemp```
< jonpsy[m]>
```SlowScheduler``` needs only ```currentTemp```. How would we handle this?
< rcurtin[m]>
if you have to pass an instantiated `CoolingSchedule` to the constructor of the optimizer this should be no issue---the user will have to call the constructor of `FastScheduler` or `SlowScheduler` themselves
< rcurtin[m]>
or, do you mean that the optimizer must call a function of the scheduler? in this case, pass all arguments that any cooling schedule might reasonably need, then the particular cooling schedule you are implementing can ignore parameters it doesn't need
< jonpsy[m]>
> or, do you mean that the optimizer must call a function of the scheduler? in this case, pass all arguments that any cooling schedule might reasonably need, then the particular cooling schedule you are implementing can ignore parameters it doesn't need
< jonpsy[m]>
yeah i was meaning this
< jonpsy[m]>
can we, add a map to our ```FastSchecduler``` and ```SlowScheduler``` so that it creates and stores parms at runtime
< rcurtin[m]>
I would strongly advise against that. it seems like too much complexity
< jonpsy[m]>
then in ```Evaluate``` it will just take the map, and take what it needs :)
< NippunSharmaGitt>
Hi. I had sent a mail to the public mailing list to propose a possible GSoC project (revamping bindings to support fit, predict interface) about 4-5 days back. I have not received any reply on that. Is it fine for me to assume that it is not good enough for a GSoC project ? Please inform at the earliest.
< rcurtin[m]>
if all you need in either function is `currentIdx` and `currentTemp`, just pass both and ignore one in `SlowScheduler`
< jonpsy[m]>
yes but as more and more schedulers keep getting added
< jonpsy[m]>
each with its own params..
< rcurtin[m]>
Nippun Sharma (Gitter) that just means nobody has had time yet (you can see how busy things are). I was hoping to respond to that today actually
< rcurtin[m]>
jonpsy then we can change the interface as needed as more schedulers get added. that's simple refactoring work and it's an internal API (users should not be calling those functions by hand) so there won't be reverse compatibility concerns
< jonpsy[m]>
very well, thanks for your time
< rcurtin[m]>
👍👍
< NippunSharmaGitt>
@rcurtin okay, looking forward to your reply :)
< RishabhGargGitte>
Hey everyone, I have a quick question related to the `DecisionTree` class. It doesn't have support for pruning the tree, am I right ?
< rcurtin[m]>
correct, there is an issue open for this also
< RishabhGargGitte>
Okay. Thanks @rcurtin . I will look for that issue too :)