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/
travis-ci has joined #mlpack
< travis-ci> georgedouzas/mlpack#1 (master - 897b0cd : Ryan Curtin): The build has errored.
travis-ci has left #mlpack []
xiaohong has joined #mlpack
Yashwants19 has joined #mlpack
< Yashwants19> Hi rcurtin, zoq: Do we have association rule learning algorithms.
Yashwants19 has quit [Remote host closed the connection]
xiaohong has quit [Ping timeout: 260 seconds]
xiaohong has joined #mlpack
xiaohong has quit [Ping timeout: 260 seconds]
< jenkins-mlpack2> Project docker mlpack nightly build build #366: STILL UNSTABLE in 3 hr 30 min: http://ci.mlpack.org/job/docker%20mlpack%20nightly%20build/366/
jeffin143 has joined #mlpack
< jeffin143> Zoq : Thought of implementing a feature selection method
< jeffin143> So the idea is : suppose consider features are X1, X2 ,X3 ,X4 ,X5 and target feature is Y1
< jeffin143> I would take correlation coefficient of all with y , and highly correlated means they would be more appropriate * , something sought of heat map* and then choosing some features which are highly correlated with the target variable
< jeffin143> But I couldn't find a paper on it, most of the paper have the other Variant , which includes finding correlation coefficient between all features, example X1x2, x1x3, x1x4 and so on and there if they are highly correlated then just remove one since , both would contribute equally for the target variable , and thus it wouldn't make sense to keep 2 s
< jeffin143> ame features which contributes equally
jeffin143 has quit [Remote host closed the connection]
< zoq> Yashwants19: We don't.
< zoq> jeffin143: I see if I can think of any paper, if that was your question.
xiaohong has joined #mlpack
xiaohong has quit [Ping timeout: 260 seconds]
viki61 has joined #mlpack
viki61 has quit [Remote host closed the connection]
viki64 has joined #mlpack
favre49 has joined #mlpack
< favre49> really liking this new look for freenode :)
< zoq> favre49: new look?
< favre49> zoq:Yes, they changed the site
xiaohong has joined #mlpack
xiaohong has quit [Remote host closed the connection]
xiaohong has joined #mlpack
< xiaohong> I have a question, why I can not declare a Col vector of struct type or how can I declare a vector of Agent's action?
< xiaohong> The action was defined as struct, I use Col<ActionType> to declare a vector action.
< xiaohong> It seems that the compiler said that Mat_meat.hpp:35:3: error: static_assert failed "error: incorrect or unsupported type" arma_type_check(( is_supported_elem_type<eT>::value == false )); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
< zoq> xiaohong: In this case you have to use std::vector
< zoq> xiaohong: But maybe you can also use arma::mat and just store the action and not the overall action type struct?
< zoq> favre49: The design of the webclient?
< xiaohong> I am trying, but some time the action may has more than two attribution? So I choose store the action struct type.
< favre49> zoq: yup
< favre49> Also, i think i discovered the issue. The genomes are being speciated before they are evaluated, and the fitnesses are only being updated in the genome list, not the species list. I'll make the changes and hopefully that'll fix it.
viki64 has quit [Remote host closed the connection]
< zoq> favre49: Nice, btw. thanks for the print update
< zoq> xiaohong: I think in this case we should go with std::vector
favre49 has quit [Remote host closed the connection]
xiaohong has quit [Ping timeout: 260 seconds]
< ShikharJ> sakshamB: Toshal: Are you guys here? Let's wrap this up quickly?
< sakshamB> yes I am here ShikharJ
< sakshamB> I saw your reviews. I will make the changes by tomorrow
< ShikharJ> sakshamB: Okay, so I think I was able to provide the reviews on two of the other open PRs, and they just need minor changes to get merged in. SO we're good on that.
< ShikharJ> sakshamB: Other than that, I see that you pushed a regularizer PR, though I couldn't see the reason why that would be helpful. Can you explain that?
< sakshamB> ShikharJ: the next feature we had discussed was to add orthogonal regularization
< ShikharJ> sakshamB: Hmm, I thought we were done with the features? How many more are left from the ones originally planned?
< sakshamB> ShikharJ: the ones that were originally planned and included in my timeline were virtual batch normalization, minibatch discrimination and label smoothing. Outside the timeline I had listed weight normalization, orthogonal regularization and spectral normalization.
< ShikharJ> sakshamB: Okay, the more the better :)
< ShikharJ> I'm assuming Toshal would be picking up spectral norm next?
< sakshamB> ShikharJ: no actually I was planning to implement spectral normalization after this. Toshal could then continue with his proposed timeline for implement LSGAN and other variants.
< ShikharJ> sakshamB: Okay, take your time with that. I think we're on schedule with everything we planned. Let me know when the regularizer and spectral norm are ready for review.
< ShikharJ> sakshamB: Is there anything else I can help you with? Sorry I overslept half an hour today, and I have to run right now.
< ShikharJ> Let's finish up if there's nothing else to discuss?
< sakshamB> ShikharJ: no nothing else from my side. Have a great week :D
< ShikharJ> sakshamB: You too, I'll be off for now then. Have fun :)
xiaohong has joined #mlpack
< xiaohong> zoq: thx~
favre49 has joined #mlpack
< favre49> zoq I was able to fix it, it's giving good results
< favre49> 9/10 times it crossed 3.6, and 3 or 4/10 reaches very close to 4 (max fitness)
< favre49> sometimes it gets like a 3.55, but I supposed it cannot be avoided considering the randomness. I'll try toying with the parameters to see if I can make it better
< favre49> I'll test the cyclic networks as well soon, I want to revise and clean the code and make a working commit first though
xiaohong has quit [Ping timeout: 260 seconds]
< zoq> favre49: Sounds great, I will continue with the latest version than.
favre49 has quit [Remote host closed the connection]
< akhandait> zoq: Hey
< akhandait> You there?
< akhandait> I will just post it here, if anyone has the time to respond
< akhandait> I understand that we should not use namespaces in the header files because they will then be used in all the files we include the header files in.
< zoq> akhandait: Ideally we can avoid something like using namespace std; in a header file yes.
< akhandait> But isn't this supposed to be for the case when people split interface and implementation in hpp and cpp where the hpp is the header file. We have both as hpp files, so both are header files.
< zoq> that applies for both, in the most common case you include the header file, ond not the header file that contains the implementation
< akhandait> Now, in the mlpack-onnx converter, if we have both the interface and implementation as header files, we would need to constantly call functions with the namespaces which becomes tedious.
< akhandait> Oh, so does that mean we can use namespaces in the impl files?
< zoq> that could be possible, are you planning to implement the converter as an executable with a main function?
< akhandait> Hmm, I am not sure if this is what Sreenik has in mind, but from the code and what I have in mind, no. I think it will be better if we implement it as some class to provide users an API
< akhandait> Hmm, so I see the problem now. If we do it like that, then all the namespaces get included as well.
< zoq> If you like to provide a class that is fine as well.
< akhandait> sreenik: How's your health now?
< akhandait> sreenik[m]: