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/
< SinghKislay>
I will be looking forward for your valuable feedbacks. Thankyou
< rcurtin>
riaash04: also arma::norm(x - y, 2) <= tol might be useful
SinghKislay has quit [Ping timeout: 256 seconds]
vivekp has quit [Ping timeout: 244 seconds]
addy0309 has quit [Ping timeout: 256 seconds]
vivekp has joined #mlpack
vivekp has quit [Ping timeout: 250 seconds]
vivekp has joined #mlpack
srivathsa has joined #mlpack
uytgyu has joined #mlpack
< uytgyu>
hello
uytgyu has quit [Client Quit]
aman_p has joined #mlpack
khan93 has joined #mlpack
khan93 has quit [Client Quit]
srivathsa has quit [Ping timeout: 256 seconds]
xyz__ has joined #mlpack
Suryo has joined #mlpack
< Suryo>
zoq: an update for you.
< Suryo>
Thanks for pointing me to the email archives. I've read and understood the ideas that were set.
< Suryo>
To be honest, a lot of the ideas that I had were already brainstormed on. For example, instead of specifying constraints using matrices, I too thought that it would be good to pass them as function pointers.
< Suryo>
And also, I thought that it would be good to have implementations for solving binary valued problems.
< Suryo>
However, one point of difference is that the variant that I've worked on is based on preserving the feasibility of particles in the swarm and not based on using penalties for the constraints.
< Suryo>
And I think that it would be good to have both variants would be nice.
< Suryo>
So overall, I think that as a first step, it would be a good idea to focus on (i) lbest (ii) gbest variants for (i) continuous (ii) discrete (iii) binary valued problems with (i) penalty and (ii) feasibility-preserving based methods for handling constraints
xyz__ has quit [Quit: Page closed]
niteya has joined #mlpack
< Suryo>
The last thing that I have to think over is whether it would be good to code the PSO methods that work with specific methods of handling constraints, or if the constraint handling methods should also be templated.
< niteya>
Hello , For gsoc I was thinking of implementing automatic differentiation for differentiable and differentiable separable functions using jets. Please let me know what you think about this idea.
< Suryo>
I think that it would be good to separate the methods that can handle constraints from the PSO variants themselves.
< Suryo>
Except, I haven't thought of a design for the same.
niteya has quit [Client Quit]
< Suryo>
zoq: kindly let me know what you think. Thanks.
< Suryo>
Based on your feedback, I'll think over what should be done.
Suryo has quit [Quit: Page closed]
aman_p has quit [Ping timeout: 245 seconds]
Xyz__ has joined #mlpack
Xyz__ has quit [Ping timeout: 256 seconds]
Xyz__ has joined #mlpack
Xyz__ has quit [Client Quit]
Soonmok has joined #mlpack
govg has joined #mlpack
srivathsa has joined #mlpack
Xyz__ has joined #mlpack
Xyz__ has quit [Client Quit]
srivathsa has quit [Ping timeout: 256 seconds]
govg has quit [Quit: leaving]
favre49 has joined #mlpack
Kd_ has joined #mlpack
< Kd_>
Why build mlpack_test take infinity amount of time
< Kd_>
Sorry I mean it take huge amount of time to build mlpack _test and specially ann_layer and feedforward_network is there any other way to do it
< Kd_>
This building hang my computer
Kd_ has quit [Client Quit]
kanishq24 has joined #mlpack
kanishq24 has quit [Ping timeout: 250 seconds]
kanishq24 has joined #mlpack
favre49 has quit [Quit: Page closed]
kanishq24 has quit [Ping timeout: 246 seconds]
kanishq24 has joined #mlpack
< zoq>
Suryo: Sounds like a good plan to me (1-3, continues values are probably the most important).
< zoq>
Suryo: Not sure it's a good idea to separate them, I guess it would be nice if the user could use the same optimizer and is not forced to select the constrained implementation. But we can definitely split up the logic into different parts.
< zoq>
Kd_: You could disable the ann test.
< zoq>
Kd_: Also you could build with m -jx, were x is the number of jobs you like to use to build the code.
Suryo has joined #mlpack
< Suryo>
zoq: I think i gave you a wrong impression of splitting. I'll try to elaborate a bit over here.
witness has joined #mlpack
< Suryo>
So imagine that we have lbest and gbest as the basic pso methods. These are coded into templates with one pso.impl method - that's what I have currently done.
< Suryo>
And that kind of follows the style of all the methods in ensmallen
< Suryo>
Now imagine that there's method1 and method2 of handling constraints. Imagine these to be penalty based, and feasibility preserving methods, respectively.
< Suryo>
A user should be able to select: (i) the variant of PSO to be used and (ii) the variant of constraint handler to be used
< Suryo>
And in order to ensure that this is possible, I think that it's best to program the constraint handling methods as templates, so that this logic can be separated from the pso variants.
< Suryo>
I didn't mean to separately program constrained and unconstrained pso, if that's what I gave the impression of.
< Suryo>
If you think this is reasonable, then I'll begin working on it soon. Thanks!
< Suryo>
And naturally, the user can feed it constraints. Based on (i) the pso variant selected (default choices if nothing is specified) (ii) if constraints are included, and (ii) whether method1 or method2 of constraint handling is selected (with default choices if nothing is selected by the user), the PSO function should run.
< Xain>
hey my name is zain from Manipal and I'm interested in the GSoC project on NEAT. I've read up on NEAT and it's variants, but I haven't see anything on using it as an optimizer. Could you show me where it has been used that way?
Xain has quit [Client Quit]
addy0309 has joined #mlpack
aman_p has joined #mlpack
kd_ has joined #mlpack
< kd_>
Hey how many slots do we have in gsoc..??
kd_ has quit [Client Quit]
PJ1527 has joined #mlpack
< PJ1527>
Hi, liked the idea of mlpack and hence came here to contribute.
< PJ1527>
I was thinking about working this summer as gsoc student for implementing ANN applications in mlpack
< PJ1527>
I have few ideas in mind : actually ML is used in variety of domains such as speech, image, text, medical data/signals, etc. So I was wondering to include atleast one real life application from each of these domains, such as a digit recogniser from spoken data, some sentiment analysis or something like that from twitter data, generating Shakespeare plays, a image classification
< PJ1527>
Then also was thinking about implementing a recommender system
< PJ1527>
Now we can divide these applications based on difficulty and arrange them for users, these applications not only used Neural nets but will also enable user to understand various aspects of using ML, like splitting data, balancing data, different metrics, etc.
< PJ1527>
Please get back if this rough sketch kind of thing is expected, then I can start by understanding your codebase and hence maybe write a succesful proposal at the end
addy0309 has quit [Ping timeout: 256 seconds]
PJ1527_ has joined #mlpack
PJ1527_ has quit [Client Quit]
PJ1527 has quit [Ping timeout: 256 seconds]
pranit has joined #mlpack
< rcurtin>
kd_: we won't know how many slots we have for GSoC until after the application process
< rcurtin>
PJ1527: the idea of adding a bunch of models to the models/ repo is nice, I think it could make a nice proposal
< rcurtin>
actually if I remember right there is an idea on the Ideas page about that (but I am not 100% sure), so maybe there are some more details available there
pranit has quit [Ping timeout: 256 seconds]
kanishq24 has quit [Ping timeout: 244 seconds]
kanishq24 has joined #mlpack
< zoq>
Suryo: Thanks for the clarification, so this sounds like we use a policy based design for the optimizer type and the constrains type; sounds like a good idea to me.
< rcurtin>
gitdub going crazy again :(
Suryo has joined #mlpack
< zoq>
Somehow gitdub includes the two merge commits
< Suryo>
zoq: thanks for the feedback. So I don't know what a policy based design exactly is, but I'll study it.
< Suryo>
Also, there's a pull request that I opened, #86. rcurtin has marked it as 'needs review'. If by any chance you review it, then please don't merge it. I want to work on the constrained version of PSO as a part of it.
< rcurtin>
Suryo: no worries, I just set up mlpack-bot on that repository so normally mlpack-bot would label it like that :)
< rcurtin>
two approvals are needed before merge, so it wouldn't be immediately and suddenly merged, especially if you said it wasn't ready yet :)
< Suryo>
Yeah... I'm not rushing with things. Want to br sure before I ask for a review.
< rcurtin>
usually I just take a look at the PRs to see when they look like they are ready for a review
< rcurtin>
but it's not clear to me how I could get a bot to figure that out, unless we asked contributors to specifically ask for a review. maybe I could at least have mlpack-bot tag it only when all CI tests pass
< Xain>
Hey guys I think you missed it but could you please answer my question about NEAT?
favre49 has quit [Client Quit]
Xain has quit [Ping timeout: 256 seconds]
kanishq24 has quit [Read error: Connection reset by peer]
kanishq24 has joined #mlpack
favre49 has joined #mlpack
Suryo has joined #mlpack
< Suryo>
rcurtin: if you may allow me to give you my opinion on this...
< Suryo>
This is inherently a difficult problem. What does it mean for a pull request to be mergable? It's different for different cases.
< Suryo>
For example, for a certain pull request, the tests may themselves pass, but that would not necessarily mean that the code can be merged.
< Suryo>
Unless there's some sort of real indicator for this, it's difficult. To tag would in itself be a good idea.
< Suryo>
Okay, not merge, but basically ask the admins for a review
< rcurtin>
yeah, agreed. definitely we can't do automated merges or anything
< Suryo>
To me, it kind of seems like the halting problem, but again, that might be a long shot :)
< rcurtin>
the goal with mlpack-bot was just to make things a little bit easier by having a little bit of automation that could save us some time and automatically organize things a bit better
< Suryo>
Maybe you could generate a summary of the required tests? Such as, for pso, the tests are under the pso directory, so the bot could summarize what specific tests are being passed.
< Suryo>
And some specifics of the algorithms, such as parameters and hyperparameters being used.
< Suryo>
I believe that could make things easier for you guys.
favre49 has quit [Quit: Page closed]
< Suryo>
But yes, that wouldn't necessarily give the admins a glimpse of the code that's changed.
< Suryo>
Summarising changes wouldn't be a good idea according to me because GitHub already does that...
< Suryo>
Anyway... These are my two cents. Hope you don't mind :)
kanishq24 has quit [Read error: Connection reset by peer]
< rcurtin>
no worries, I appreciate the feedback :)
kanishq24 has joined #mlpack
< Suryo>
Maybe there could be a reduction that might establish or contradict my points. Haha, just something that crossed my mind!
< rcurtin>
I think the easiest thing for me to implement for now is to only mark 'needs-review' on PRs that have all tests passing. that won't be perfect, but it will at least tell people at a quick glance what *might* be ready for review
kanishq24 has quit [Read error: Connection reset by peer]
< rcurtin>
mlpack-bot is Probot, so it's all Javascript, and I get unhappy as I write more javascript, so I'd like to keep it simple :)
kanishq24 has joined #mlpack
< Suryo>
Probot. Hmm. I'm checking it up.
favre49 has joined #mlpack
kanishq24 has quit [Read error: Connection reset by peer]
< Suryo>
Okay this is interesting
< Suryo>
If I have time, would it be okay if I took a look at the mlpack bot?
< rcurtin>
sure, if you like, but I'd prefer to keep it as simple as possible
< rcurtin>
if mlpack-bot gets more complex it's more likely to do the wrong thing, or be hard to debug, or be hard to understand
kanishq24 has joined #mlpack
< Suryo>
Okay, noted. Thanks though!
< rcurtin>
sure :)
riaash04 has joined #mlpack
kanishq24 has quit [Read error: Connection reset by peer]
kanishq24 has joined #mlpack
riaash04 has quit [Ping timeout: 256 seconds]
kanishq24 has quit [Read error: Connection reset by peer]
sreenik has joined #mlpack
kanishq24 has joined #mlpack
Soonmok has quit [Quit: Connection closed for inactivity]
bhavya01 has joined #mlpack
< bhavya01>
Hi! I was looking at the mlpack translator project and I think the idea of using onnx as a connecting link will be the better than having separate translators for separate libraries, as many other toolkits already have translators to convert into that format and vice versa.
favre49 has quit [Ping timeout: 256 seconds]
bhavya01 has quit [Quit: Ex-Chat]
Suryo has quit [Remote host closed the connection]
kanishq24 has quit [Read error: Connection reset by peer]
< rcurtin>
bhavya01: agreed, ONNX seems useful to me also
< riaash04>
I can't understand why the appveyor build is failing in isomap pr, the job ends on k_means_impl.cpp file (with error code 1) which is not touched in this pr.
< riaash04>
Any suggestions on how I can understand the error?
< rcurtin>
riaash04: link to failing appveyor build log?
aman_p has quit [Remote host closed the connection]
< rcurtin>
riaash04: sorry about that, had some client issues
favre49 has joined #mlpack
< rcurtin>
the actual problem in the build is in k_nearest.hpp; do a search on the page for "error " (the space is important), and you'll find it
< rcurtin>
"error C2131: expression did not evaluate to a constant"
< rcurtin>
the windows builds have massive amounts of output... it's often hard to dig through and figure out what went wrong. but the ctrl+f "error " has saved me many times :)
< riaash04>
rcurtin: thanks a lot. I'll look into fixing the error.
< rcurtin>
sreenik: I think you're right, if you want to open a PR I'll merge the change. just a one-character change I guess :)
< sreenik>
Yes. I'll do it right away
rick_ has quit [Ping timeout: 246 seconds]
< rcurtin>
sreenik: actually there are a few other things that significantly improve the performance of the DigitRecognizer and the CNN version if you want to play with them
< rcurtin>
I found these once but never had time to clean it up and put it in a PR
< rcurtin>
- ITERATIONS_PER_CYCLE should be the number of points in the dataset
< rcurtin>
- BATCH_SIZE can be larger, usually a power of 2 is used, but that is not a huge deal
< rcurtin>
- the data should be normalized to be between 0 and 1
< rcurtin>
- other initializations work way better than RandomInitialization
< rcurtin>
- at least for DigitRecognizerCNN, the MaxPooling layer should have its last constructor parameter as false
< sreenik>
Yes some of these had struck me too. I will try to optimize it as much as I can
< rcurtin>
if you want to play with it please do feel free. but also don't feel obligated :)
< rcurtin>
I just haven't had time to actually put something together for it
< rcurtin>
it's a pretty good feeling to run it after those changes though and see how much better the performance is :)
< sreenik>
Yes. That's a different feeling altogether. a feeling of contentment
< rcurtin>
:)
sreenik has quit [Quit: Page closed]
khan93 has joined #mlpack
kanishq24 has quit [Ping timeout: 246 seconds]
khan93 has quit []
kanishq24 has joined #mlpack
khan93 has joined #mlpack
< khan93>
Hi. I am uzair . I am trying to write a custom mlpack command line tool.
< khan93>
I have followed the bindings tutorial on the mlpack website.
< khan93>
The code compiles but its throws a segmentation fault. If i run the compiled file with the --help tag, it shows the information. But if i try to run the file with inputs there is a always segmentation fault.
< khan93>
Any kind of help will be appreciated . Is there a certain type of format for generating bindings (like the one followed in src/method one .hpp file, one impl.hpp file and one main.cpp file). I am just using a single main file and compiling it manually.
< rcurtin>
khan93: you could try backtracing with gdb, but my best guess is that you are accessing a parameter with incorrect type
< rcurtin>
like if you define 'PARAM_STRING_IN("string", ...)'
< rcurtin>
and then write 'CLI::GetParam<int>("string")' this will crash, usually with a segfault (if I remember right)
< rcurtin>
so that would be the first place I would look
< rcurtin>
otherwise I would try to narrow down exactly where the segfault is happening with gdb or similar
< rcurtin>
it may not be a CLI::GetParam<>() access at all, it could be something else
< rcurtin>
you can also compile with debugging symbols (with CMake this is '-DDEBUG=ON') and that might be helpful also
< khan93>
Thanks rcurtin. I am compiling with --DDEBUG=ON but i will look at my code again if i am using incorrect types
kanishq24 has quit [Read error: Connection reset by peer]
< rcurtin>
sounds good. gdb is your friend for things like this :)