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/
< rcurtin>
I don't think I like string parsing in bash either but I accidentally got good at it :(
AndroUser2 has joined #mlpack
AndroUser2 has quit [Ping timeout: 248 seconds]
AndroUser2 has joined #mlpack
gmanlan has joined #mlpack
< gmanlan>
rcurtin: you there?
< rcurtin>
gmanlan: yeah, alternating between drilling holes in this board and waiting for my travis Python builds to fail :)
< gmanlan>
:) I'm back after a lot of traveling
< rcurtin>
nice, hope the trip went well :)
< rcurtin>
or trips perhaps :)
< gmanlan>
yep, all good - got something for the team:
< gmanlan>
early version! a lot to do, but it's a start
< rcurtin>
oh wow, this is awesome
< rcurtin>
I like the simplicity of the front page---there are only four main links under the "why mlpack" section
< gmanlan>
I have tried to maximize users adoption, which means we need to reduce friction (a.k.a. a lot of text)
< rcurtin>
yeah, agreed
< gmanlan>
I couldn't figure out how to glue doxygen with the website
< gmanlan>
any trick?
< rcurtin>
ahh, it's pretty ugly. what I currently do is I generate HTML from a series of scripts before using the site generator
< rcurtin>
in any case, I can work on that part when we're ready to put the whole thing together, if you like
< rcurtin>
or, I can provide a bunch of static Doxygen-generated HTML files that you can then just drop into place
< gmanlan>
sounds good
< gmanlan>
I spent a lot of time on just formatting
< gmanlan>
but I guess the CSS would be reused for the doxygen part, mostly
< rcurtin>
yeah, there are other little bits to the CSS that need to change for doxygen, but I can adapt what you have on the other pages for that (unless you want to do it)
< gmanlan>
sounds good - in that case I will let you handle the Doxygen front and I will finish the front page details such as the distribution channels stuff
< gmanlan>
I just posted the website in #1892 to collect feedback
< gmanlan>
anything you hate about the website?
< rcurtin>
definitely nothing I hate :)
< rcurtin>
I do wonder if we could find a more appropriate background image, but I'm not sure exactly what
< gmanlan>
(Y)
< gmanlan>
for the hero banner?
< rcurtin>
yeah
< rcurtin>
I'll think about it but I don't currently have any ideas
< gmanlan>
yeah, I'm on the same boat - tried many different ones but couldn't find a good one - I ended up using a generic (pseudo randomly generated) triangles background
< gmanlan>
maybe we can create something in relationship with the logo (tree/nodes) - but it needs to be very soft/lightweight
< rcurtin>
yeah, agreed
< rcurtin>
anyway overall I think it's awesome. a huge improvement
< gmanlan>
cool - I will continue working on it next week
< rcurtin>
I'm working on one of the other pieces right now, which is easy Python installation from pip in at least linux and hopefully OS X; I think Windows might be possible with the tool I'm using, but I don't know how hard it will be...
< rcurtin>
distributing Python packages that are actually compiled C++ libraries though is... tedious
< gmanlan>
excellent - yes Windows is giving us many issues
< gmanlan>
unfortunately (or fortunately?) in my environment Windows is the 1st choice - so we need to go that extra mile to get python working there
< rcurtin>
yeah, we can definitely get it going, just a question of how much pain before we get there :)
< gmanlan>
haha, agreed
< gmanlan>
ok - I have to run - feel free to post further thoughts about the website in 1892 - I will continue from there
< gmanlan>
good luck and reach out if you need me to try a new python build in Windows
< rcurtin>
sounds good, thanks! I just posted an update comment there, I meant to do that earlier
< gmanlan>
(Y)
gmanlan has quit [Quit: Page closed]
AndroUser2 has quit [Ping timeout: 248 seconds]
AndroUser2 has joined #mlpack
AndroUser2 has quit [Ping timeout: 248 seconds]
AndroUser2 has joined #mlpack
AndroUser2 has quit [Ping timeout: 272 seconds]
AndroUser2 has joined #mlpack
AndroUser2 has quit [Ping timeout: 248 seconds]
AndroUser2 has joined #mlpack
Suryo has joined #mlpack
< Suryo>
rcurtin, zoq: some updates. I'll be typing slowly.
< Suryo>
I ran all the test cases with random seeds based on time. I can't believe that I had overlooked this earlier, but I'm still getting used to things within ensmallen.
< Suryo>
The entire test suite, as a part of my pull request, PR#117, that includes 10 new test functions, fail 21/25 times. To put it in percentages, the expectation of failure is about 85%.
< Suryo>
The most common failures are the CNE tests for the following: SchafferFunctionN4, HolderTableFunction, CrossInTrayFunction.
< Suryo>
It is exactly these three functions that motivated me to use CNE tests at the beginning of this week.
< Suryo>
As per my discussion with you (rcurtin and zoq) earlier, we had decided to use gradient-based methods to test the functions that I programmed but these three functions are non-differentiable and hence I thought of using CNE to test them (okay, I'll admit that they have expressions of gradients, but because they all have the absolute value operator within them, the expressions of the gradients become really really messy with imaginary n
< Suryo>
So yeah, they're 'considered' to be non-differentiable.
< Suryo>
After testing these three (and getting lucky), I proceeded to test the remaining 7 functions within CNE as well. Surprising that in these 21 failures that I encountered, none of those failed.
< Suryo>
So there are a couple of things that we could do. First, and the least intensive of all: let me tweak my tests so that they can pass but I'll make sure that the initial point is chosen such that there is some minimum amount of optimization being done.
< Suryo>
And then I proceed with PSO.
< Suryo>
Second, I could spend a little more time thinking over these failures and about the implementation of CNE. One opinion that I have about CNE is that like the policy-based design for PSO, we should have a kind of better policy-based design for CNE, such that the user may get to choose things like: (1) elitism (2) the creation of initial solutions (3) number of children after a crossover (4) parent selection method, etc.
< Suryo>
The reason I say that it is similar to the idea I had for PSO is that I had decided to have the following (keeping in mind constrained optimization problems): (1) whether the initial solution set should be strictly feasible (2) lbest or gbest, etc. and program templates for each of these. So my idea is kind of like that.
< Suryo>
What I'm concerned about, however, is that if I follow the second route as I have stated, then I might be spending less time on my primary goal, and that is working on PSO. And as it is, at the current rate, I'm about a week behind my stated schedule, and I'm wondering if that is going to be a problem.
< Suryo>
But as I had mentioned to zoq earlier, the schedule that I had created had about two weeks for testing, etc. towards the end and the development of new test functions will pay it forward so maybe it isn't a big problem yet.
< Suryo>
I'm wholly willing to follow either way into this and thought of tweaking CNE a little bit anyway, but I will wait for you to recommend to me what course of action you would prefer the most at this point of time and I will work based on that.
< Suryo>
Provided that we take another look at my schedule before proceeding.
< Suryo>
Lastly, here's another observation (but it's more like a report of sorts). The following tests also failed: QHSGDTestFunction (line 28), BBSBBLogisticRegressionTest (line 42).
< Suryo>
I could share the test log that I generated with you, but this is pretty much everything summarised. Let me know if I should email the output of the test runs to you.
< Suryo>
At another level, I'm kind of intrigued. See, the tests failed for non-differentiable functions. Sketchy, but I'm wondering if the nature of differentiable and continuous functions inherently render some advantages to metaheuristic optimizers, even though they may have multiple minima. Maybe just the smoothness helps a bit? Just a thought, and we don't have to pursue it here.
< Suryo>
Let me know your thoughts on this. Also for anyone else reading this who may have comments, I would love to hear any feedback on the matter.
Suryo has quit [Quit: Page closed]
Suryo has joined #mlpack
< Suryo>
And this is entirely on a different note, for anyone who is into gaming - what are your thoughts on Google Stadia? :))
< favre49>
Suryo: In my experience, CMA-ES has always worked better than CNE. I'm not sure about the details of what you're doing, but maybe you could try CMA-ES (granted, that has some problems as well. There's a PR open that I have to get back to some time)
Suryo has joined #mlpack
< favre49>
Also, in the code, numElite is set to 0. Thus, in the Reproduce() code, when a scalar is chosen, wouldn't it be choosing from [0,-1] causing an error if it chooses -1?
< favre49>
It's also very odd that CNE is only choosing parents from the elite population, vs doing something like rank or tournament selection
< favre49>
Choosing parents only from the elite population would definitely make it converge far too quickly in the local minima
< favre49>
I agree that a policy based implementation for the different selection methods should exist, though.
< favre49>
I think ryan also mentioned that anomaly of using size_t for the fitness instead of double. Maybe if you address these anomalies it would work better?
< Suryo>
favre49: thanks for your inputs! Yeah, I agree with all your views. Thanks for the time.
< favre49>
no problem :)
favre49 has quit [Quit: Page closed]
< Suryo>
Regarding numElites: line 51 in cne_impl.hpp sets a value for numElites based on selectPercent. That's one of the things that had come to my mind earlier today, and yeah it is possible that elitism implemented this way for selecting parents could be problematic.
< Suryo>
I would recommend having numElites to preserve an elite population after reproduction.
< Suryo>
And yes - regarding the code anomaly, Ryan has been working on it and we should put in some effort in rectifying such nuances.
< Suryo>
zoq, rcurtin: these comments from favre49 are things we cannot afford to ignore.
< conrad__>
please test and report any regressions :)
conrad__ has left #mlpack []
AndroUser2 has quit [Ping timeout: 272 seconds]
AndroUser2 has joined #mlpack
AndroUser2 has quit [Ping timeout: 248 seconds]
< zoq>
Suryo: Don't like the idea to tweak the tests; first, there is no guarantee they will pass most of the times. And what is the purpose of the test anyway if we set the starting point really close to the solution. Also, it's possible that the implementation is wrong, will check again to make sure we didn't miss anything.
< zoq>
Not sure the priority here should be to improve the CNE method so that it will work against most of the problems. If we can improve the method great, but I wouldn't call it CNE anymore.
< zoq>
Anyway, I agree the favre49 there are multiple options that we could take a look at to improve CNE, but personally, I think PSO has more opportunities. However, I'm fine if you like to focus on CNE for now, we can adjust the schedule accordingly, don't see an issue here.
< zoq>
conrad__: Nice, will take a look at the new release for sure.
Suryo has joined #mlpack
< Suryo>
zoq: No I'm not insisting that I spend too much time on CNE right now, especially because we have a plan for PSO. So what about the test functions themselves? Should I test it with CMA-ES and see if they pass? And if they do, then would you merge it so that I can use these functions to test PSO?
< zoq>
yeah, testing against CMAES sounds like a good solution.
< toshal>
zoq ShikharJ rcurtin: Do we have a layer which is a wrapper around other layer in our ANN's? If yes let me know it's name. It looks like the weight norm layer would be a wrapper around other layer. So I thought it would be great to know if there is any other layer.
< toshal>
I will upload the template code of weight norm layer soon. Don't worry.
< toshal>
Also let me know whether there will be some fundamental error in implementing this.
KimSangYeon-DGU has joined #mlpack
ImQ009 has joined #mlpack
ImQ009 has quit [Quit: Leaving]
ImQ009 has joined #mlpack
KimSangYeon-DGU has quit [Quit: Page closed]
< toshal>
ShikharJ: Are we meeting at 9:30 today?
< rcurtin>
is anyone using git LFS to store large files? mlpack is apparently over the 1GB quota, but I haven't figured out what is using the space
< rcurtin>
or rather, I should ask, is anyone using git LFS in an mlpack organization repository?
< zoq>
not that I'm aware
< zoq>
did you receive a notification?
< rcurtin>
yeah, I did
< rcurtin>
I think I see what it is---it's the datasets in mlpack.org/datasets/
< rcurtin>
but those haven't been touched for months, so I'm not sure why we've only received the notification now
< zoq>
hm, perhaps we can deactivate lfs?
< rcurtin>
we use LFS for the actual .tar.gzs for each release though
< rcurtin>
so probably the better solution is to just move the datasets to somewhere else
< zoq>
I see
< rcurtin>
let me think about the right place to do that, but probably I can just put them on ratml.org/ or something like this
< toshal>
rcurtin: Okay. Does storage of savannah matters?
< toshal>
I transferred one csv file it was somewhat big upto 127 MBs. I don't know if that's the reason.
< rcurtin>
toshal: not at all, that's not LFS
< rcurtin>
:)
< toshal>
Yes, It does not matter. I guess someone would have downloaded the dataset's. Git LFS has 1 GB bandwidth limit as well. This is just a guess.
< rcurtin>
yeah, what's surprising to me is just that we've been storing those datasets for a very long time but this is the first notification I've received about the limit
favre49 has joined #mlpack
vivekp has joined #mlpack
vivekp has quit [Ping timeout: 272 seconds]
vivekp has joined #mlpack
< toshal>
ShikharJ: I am here. Are you there?
< toshal>
Luckily I am on time today.
< ShikharJ>
toshal: Ack, sorry.
< ShikharJ>
toshal: sakshamB: Let's chuck that meeting for today. I had a meeting today in the morning, so forgot about this.
< sakshamB>
alright no problem :)
< ShikharJ>
sakshamB: toshal: In case you guys have something to share, please feel free.
< sakshamB>
I just wanted reviews for minibatchdiscrimination and inception score PRs
< sakshamB>
and should I open a PR for VirtualBatchNormalization? ShikharJ
< ShikharJ>
sakshamB: Yeah, feel free. I should be able to complete all pending review today.
favre49 has quit [Ping timeout: 256 seconds]
< sakshamB>
ShikharJ: alright thanks!
< ShikharJ>
toshal: What's your status?
< ShikharJ>
sakshamB: Sorry about today. Won't happen in the future I promise.
< sakshamB>
not a problem as I said before ShikharJ
< ShikharJ>
sakshamB: toshal: Just for clarification, we're keeping the same meeting time as 7pm IST on Mondays and Fridays. I'll keep a calender reminder to be sure on it.
< ShikharJ>
sakshamB: On the MiniBatchDiscrimination layer, I'd suggest to first push in Marcus' suggested changes, so that I can review further?
< toshal>
ShikharJ: Hi
< toshal>
I just want a review on my serialization PR.
< toshal>
I am testing dual optimizer code. I will upload the template code for weight norm tonight
< toshal>
Sorry I just went off.
< ShikharJ>
toshal: Okay, sounds good, after that I think only a couple of things will be left to be done in the next two weeks and we can call the first phase a success :)
< ShikharJ>
toshal: I'll provide the review my tonight (you should be able to have a review by morning in India :) ).
< ShikharJ>
toshal: What about label smoothing? Are you stuck somewhere?
< ShikharJ>
If you need help, just let me know.
< toshal>
No label smoothing is done just in case if you find something problematic those changes would only be required to be done.
< toshal>
After serialization you can review that as well
< toshal>
zoq: ShikharJ: I was having one doubt. When do we include a layer directly in `layer.hpp` and when we include it through `layer_types.hpp`
< toshal>
It looks like it's related to boost variant support. Correct me if I am wrong.
< sakshamB>
ShikharJ: yes I just pushed those changes.
< toshal>
sakshamB: Do you know the previous doubt I have asked?
jeffin143 has joined #mlpack
< jeffin143>
Hi , can anyone help me debug a little chunk of code
< jeffin143>
The above function is used to return a pair of unordered map and deque , but it throws up an error : cannot bind non-const lvalue reference of above type to an rvalue of above type
< toshal>
jeffin143: add const to your return type it should work.
< toshal>
It will become const std::pair<std::unordered_map<boost::string_view, size_t, etc.
< jeffin143>
Would that allow me to modify the values inside the pair..???
< toshal>
Ah No I don't think so. To which variable are you returning it?
< toshal>
rvalue references are used to point to tempoaaries which should not get changed.
< toshal>
i.e constant
< jeffin143>
So the problem is I want to return both mappings variable and stringq variable as a pair so that I can change both at a time*
< jeffin143>
Like a setter function for two objects*
< sakshamB>
jeffin143: the variables you are returning are temporary variables created inside the function?
< jeffin143>
No, it is class data members*
< jeffin143>
Not a temporary variable
< jeffin143>
sakshamB : so intially I had two function to edit map and the other one for editing deque , but I want it be edited at once * and that is why wanted to use pair
< toshal>
i.e You are calling Mappings() = something in order to edit both of it correct?
< jeffin143>
Yes
< sakshamB>
jeffin143: the pair you are returning is a temporary. You can’t return a reference to it.
< toshal>
make_pair() will create a new object before
< toshal>
passing.
< toshal>
sakshamB: Yes you are correct.
< jeffin143>
So , basically to dodge it , I have to make a pair my class member and then return it
< jeffin143>
Possibly
< toshal>
Yes. So that a new temporary object is not created.
< ShikharJ>
toshal: Yes, you are correct regarding layers.
< ShikharJ>
toshal: Sorry once again for disconnecting, I have meetings throughout the day, so I'll be on and off on IRC.
< toshal>
ShikharJ: no problem.
< toshal>
jeffine143: Don't keep mappings and string q as two different data members. Make it's pair as a member and pair.first instead of mappings variable and pair.second
< jeffin143>
Yeah sounds reasonable
gmanlan has joined #mlpack
< gmanlan>
rcurtin: you may want to update the website link @ the github repo header (mlpack: a scalable C++ machine learning library -- http://www.mlpack.org/) - it's http and not https
< rcurtin>
oh, sure, easy fix :)
< rcurtin>
done :)
< gmanlan>
(Y)
< lozhnikov>
jeffin143: You should return a pair of references instead of a reference to a pair. Try to use std::tie() instead of std::make_pair().
< zoq>
toshal: Every layer in layer_types.hpp either depend on another layer defined in layer.hpp (e.g. Recurrent makes use of the Linear layer internally) or they can take/store a layer (e.g. MultiplyMerge is able to merge different layer).
< zoq>
toshal: That should answer your other question as well, everything in layer_types.hpp could take a layer as input.
< toshal>
zoq: Thanks, that helped me to get some references.
ImQ009 has quit [Read error: Connection reset by peer]
gmanlan has quit [Quit: Page closed]
jeffin143 has quit [Read error: Connection reset by peer]