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/
tomsun has joined #mlpack
< jonpsy[m]>
hi, i think this question has been asked before. I'm wondering why I get "E: Unable to locate package libstb-dev"
< rcurtin>
fortunately, you can use the CMake auto-downloader for both those libraries
< rcurtin>
(or, rather, it will automatically be used when you build mlpack)
< rcurtin>
(ah, sorry, change "build mlpack" to "configure mlpack with cmake")
< jonpsy[m]>
you mean when i build from source, right?
< rcurtin>
yeah
< rcurtin>
although if you are just trying to get mlpack set up, the libmlpack-dev package should be sufficient (although it may be a little out of date on 18.04)
< jonpsy[m]>
okay then , if i do "sudo apt" it should've said "requirement already satisified" rather than not found then..?
< rcurtin>
nah, in this case, the auto-downloader is just downloading it locally, so apt won't know anything about it
< rcurtin>
sorry for the confusion---these packaging issues on different versions of distros are intricate and confusing :(
< jonpsy[m]>
hehe np. :) i'm only just diving into mlpakc
< rcurtin>
no worries :)
< jonpsy[m]>
mlpack**, sorry xD
< rcurtin>
we do our best to make it easy, but it's always hard to make sure the commands work everywhere with C++ libraries
< rcurtin>
(in fact actually with Python it's the same way, but all the difficulty is hidden inside of PyPI so the user doesn't ever really need to encounter it :))
< jonpsy[m]>
tbh mlpack is one of the most maintained and tightknit repo i've seen in c++
< rcurtin>
thanks! over the years the momentum has built :)
< jonpsy[m]>
good day!
< rcurtin>
:)
< jonpsy[m]>
hey, uh noob question
< jonpsy[m]>
i used doxygen from root directory i got
< jonpsy[m]>
and, if i built it succesfuuly, how do i run this locally? some python server i guess? but at which directory..
petris has quit [Remote host closed the connection]
petris has joined #mlpack
ImQ009 has joined #mlpack
HeikoS has joined #mlpack
< zoq>
jonpsy[m]: There should be a doc folder on the build dir.
< jonpsy[m]>
Yeah, i noticed
< zoq>
jonpsy[m]: python -m SimpleHTTPServer 80
< zoq>
to start a simple http server
< jonpsy[m]>
In that folder, i see
< jonpsy[m]>
And about the error?
< zoq>
have you installed dot after a failed run?
< zoq>
A safe way to test is to delete the doc or the entier build folder.
< jonpsy[m]>
I can try that
< jonpsy[m]>
Thanks
abhisaphire[m]1 has joined #mlpack
RudraPatil[m]1 has joined #mlpack
outmanipulateGi4 has joined #mlpack
vigsterkr[m]1 has joined #mlpack
abhisaphire[m] has quit [Ping timeout: 256 seconds]
RudraPatil[m] has quit [Ping timeout: 256 seconds]
AbishaiEbenezer4 has joined #mlpack
< chopper_inbound[>
Hello everyone! I had a doubt; suppose I have a input of shape (nF, nS, b) and I convert it to matrix of shape (nF * nS, b), then it is possible to feed this input to linear layer with weight of shape (outSize, nF * nS) and bias of shape (outSize, 1), so the final output is (outSize, b). But the number of parameters will be much large in this case. Instead if we directly feed the original input with shape (nF, nS, b)
< chopper_inbound[>
to "some kind of linear layer" having weight of shape (outSize, nF) and bias of shape (outSize, 1), then final output is (outSize, nS, b). In the second case, we are multiplying the same weight matrix to each slice of the input. We have less number of parameters to train now and "probably" more output features if we compare. Can that be achieved by some existing methods in mlpack?
jjb[m]1 has joined #mlpack
KhizirSiddiquiGi has joined #mlpack
SriramSKGitter[m has joined #mlpack
SriramSKGitter[m has quit [Changing host]
SriramSKGitter[m has joined #mlpack
AryamanBhagatGi4 has joined #mlpack
DivyanshKumar[m4 has joined #mlpack
TaapasAgrawalGi4 has joined #mlpack
AryamanBhagatGit has quit [Ping timeout: 256 seconds]
DivyanshKumar[m] has quit [Ping timeout: 256 seconds]
robotcatorGitte4 has joined #mlpack
robotcatorGitte4 has quit [Changing host]
robotcatorGitte4 has joined #mlpack
shrit[m]1 has joined #mlpack
VSaicharanGitte4 has joined #mlpack
robotcatorGitter has quit [Ping timeout: 256 seconds]
shrit[m] has quit [Ping timeout: 256 seconds]
VSaicharanGitter has quit [Ping timeout: 256 seconds]
M_slack_mlpack_U has quit [Ping timeout: 256 seconds]
M_slack_mlpack_U has joined #mlpack
M_slack_mlpack_U has quit [Changing host]
M_slack_mlpack_U has joined #mlpack
srinivasyadav227 has quit [Ping timeout: 256 seconds]
srinivasyadav224 has joined #mlpack
< jeffin143[m]>
zoq (@freenode_zoq:matrix.org) : you there
< jeffin143[m]>
I was trying to write test using catch for mlboard
< zoq>
jeffin143[m]: Sure, what's the issue?
< jeffin143[m]>
Now I was including it using #include<mlbaord/mlbaord.hpp> but this will throw an error , because this file will not be there till I hit make install, but test will be compiled when I hit make -j so how should I run test
< jeffin143[m]>
Like I don't understand the flow
< jeffin143[m]>
Like you included ensmallen header but for ensmallen header is even there without installing
< jeffin143>
Now this include will only work when ? there is ensmallen.hpp file in /usr/bin/include/ ?
< jeffin143>
correct ?
< jeffin143>
zoq[m] : But this file will only be coming in that path when you hit make install ?
< jeffin143>
but the catch test will be compiled before make install -> ? so how does that work like there is no such file in your /usr/bin/include/ dir but still it is able to include that file
< zoq>
jeffin143: No gcc will look in several different places
< jeffin143>
yes but we have to specify the folder using flag -I ?
< jeffin143>
Try adding `#include <mlboard/mlboard.hpp>` this line in mock_test.cpp and it will fail
< jeffin143>
Whenever you are free :)
< zoq>
jeffin143: This is supposed to be a header only project right?
< jeffin143>
yes
< jeffin143>
The issue is , like how should I handle protobuf thins
< jeffin143>
I need to compile them
< zoq>
jeffin143: But only once right? You could push the precompiled headers?
< zoq>
jeffin143: commented on the PR.
< jeffin143>
oh yes , that's right
< jeffin143>
Thanks
< zoq>
jeffin143: I guess you just have to compile the headers if the interface changed?
< jeffin143>
yes
< zoq>
So for me it would make sense to push those as well, if I just wanted to use the board.
< jeffin143>
so you mean push both .h and .cpp files ?
< jeffin143>
that were generated ?
< zoq>
yes, but also include the option to generate them as well
< jeffin143>
but then we have to manually like them against each of the output files ?
< jeffin143>
because in cmake it creates an archive of all the output files which we can link to
< shrit[m]1>
rcurtin as the error says, it is having several positioning names
< zoq>
hm, not sure, have to take a closer look into the project structure to provide an answer here
< shrit[m]1>
But I am not sure where the error is caused from mlpack side,
< rcurtin>
you could add a cout call to the constructor of CLIOption (or is now CMDOption?) printing the details of what is being added, in order to see if something is being added multiple times
< shrit[m]1>
I was able to compile cereal::make_array implementation which is based on boost::serialize
< jeffin143>
pso_name is never intialised to anything after this line how can its length increase
< jeffin143>
I am not sure why that condition becomes true
< jeffin143>
pos_name*
< jeffin143[m]>
My ba
< jeffin143[m]>
Bad there is a for loop 😂
< jeffin143[m]>
Bad*
< jeffin143>
shrit[m]1 : can you try a thing ?
< shrit[m]1>
jeffin143 sorry I did not get what you mean
< jeffin143>
`PARAM_STRING_IN("decomposition_method", "Method used for the principal " "components analysis: 'exact', 'randomized', 'randomized-block-krylov', " "'quic'.", "c", "exact");` -> this line change c to something other like t or q or x
< jeffin143>
name it x and try compiling once ?
< jeffin143>
like put x instead of c !
< shrit[m]1>
Ok I understand
< jeffin143>
also change everything to this "-c" , "-o", "-i" , "-p" -> inside this
< jeffin143>
I think so this format is the actual format for short names
< jeffin143>
I think so It is how PARAM_MATRIX_OUT is working it only takes one character for the last second argument
< jeffin143>
I didn't see the definition of PARAM_MATRIX_OUT
< jeffin143>
but I am sure the error came because when you are passing "-c" -> it is only passing "-" and that is why that error comes , if we are able to pass "-c" , I guess that will solve the issue"
< jeffin143>
when we pass it , I am guessing we pass it as string only -> a string of vectors
< shrit[m]1>
Yes, but we need to be extremly careful when updating cli11
< jeffin143>
but I am not a fan of change the library itself , because that can break something else they are using
< jeffin143>
shrit[m]1 : Exactly
< shrit[m]1>
rcurtin What do you think?
< shrit[m]1>
jeffin143 I did not use mlpack cli enough, so I do not remember, does the user need to use - for the aliases?
< shrit[m]1>
for example the user should enter ./mlpack_pca -c exact ?? in order to work, right?
< shrit[m]1>
Also, this issue is not faced when entering other aliases other than PARAM_STRING_IN
< shrit[m]1>
So, there is something that is missing
< rcurtin>
shrit[m]1: right, ./mlpack_pca -c exact is the way it should be used
< rcurtin>
also ./mlpack_pca --decomposition_method exact should work too in the same way
< shrit[m]1>
Exactly, So all the PARAM in each mlpack_main are only to print the help right?
< shrit[m]1>
and of course they are defining the options
< rcurtin>
yeah, exactly, unless I am forgetting something those are the only ways they are used
< shrit[m]1>
This when trying to cout << util::Param data
< shrit[m]1>
So I cout all the field that being parsed. One interesting thing if I remove the c and keep only empty "". I got the same error but asking to remove: h
< shrit[m]1>
And there is no where to find from where this "h" is coming from
< shrit[m]1>
Even one more magic issue:
< jeffin143[m]>
H is from help
< shrit[m]1>
I added a new option called Omar method
< shrit[m]1>
and Is stopping there now,
< jeffin143[m]>
It depends the ordering of processing
< jeffin143[m]>
Since for some other files it would be different option
< shrit[m]1>
Of course, but what I do not understand, why it is stopping at the end instead of the first
< shrit[m]1>
if CLI11 is not capable of parsing on char options it should had stopped at the very start, not at the end
< shrit[m]1>
that means it is not related to any options from any mlpack_main
< shrit[m]1>
but instead they are related to what is executed after
< jeffin143[m]>
Just keep two option
< jeffin143[m]>
And let's see
< jeffin143[m]>
Two options and then three*
< jeffin143[m]>
shrit , cli11 is capable of parsing on chat
< jeffin143[m]>
Char
< jeffin143[m]>
If the char doesn't match any of the patern it goes to the else part and ther it is set to pos_name = char
< jeffin143[m]>
Then for loop continues
< jeffin143[m]>
And then again when a char comes it goes to else
< jeffin143[m]>
But now pos_name is aldeardy there and hence it throws an error
< shrit[m]1>
terminate called after throwing an instance of 'CLI::BadNameString'
< shrit[m]1>
what(): Only one positional name allowed, remove: h
< jeffin143[m]>
Bool*
jeffin143 has quit [Ping timeout: 245 seconds]
< RyanBirminghamGi>
Hi walragatver and jeffin143!
< jeffin143[m]>
Hi Ryan Birmingham (Gitter)
< walragatver[m]1>
birm: hi
< walragatver[m]1>
So jeffin anything you would like to say?
< jeffin143[m]>
walragatver: Nothing , just a small update that I am currently working on with catch testing
< jeffin143[m]>
Parallel to resolving the comments which is there on the first pr
< walragatver[m]1>
Okay has the error resolved which you were facing in #5
< jeffin143[m]>
No , I am try to avoid using ../ and things in .hpp file
< jeffin143[m]>
Like call using the <> instead of locally finding the headers files
< jeffin143[m]>
I have to look more on cmake
< RyanBirminghamGi>
The fact that 1 and 5 share so many commits makes it interesting to look at
< jeffin143[m]>
Ryan Birmingham (Gitter) 5 is just one commit ahead of 1
< jeffin143[m]>
So just take a look at the last commit I did on 5 , rest is exactly same as other
< RyanBirminghamGi>
yes, so they share 23 commits
< jeffin143[m]>
To run the test I needed those files , and thus made it from that branch
< RyanBirminghamGi>
true!
< RyanBirminghamGi>
No worries, just interesting to look at
< walragatver[m]1>
Okay, so currently the testing is possible using " " instead of <>. Have you used " " currently in PR and completely checked that except this problem there is no other problems?
< rcurtin>
shrit[m]1: sorry, I had to step out for lunch, sorry for the delay
< jeffin143[m]>
No I didn't test it, I had to test it during the night slot , but I am assuming that would work , but anyways I will let you know
< jeffin143[m]>
walragatver : after zoq told what I did , I got into shrits error and hence didn't test mine :)
< jeffin143[m]>
I will do it by night !
< walragatver[m]1>
Okay no problem
< walragatver[m]1>
I think it's better to first completely check by using " ". So that we are assured that except that there is no other problem.
< jeffin143[m]>
Ok walragatver , I will first opt in for that
< walragatver[m]1>
Okay, I will give you a review soon on #1. I think it's quite complete.
< jeffin143[m]>
<rcurtin "shrit: I'm taking a look at http"> rcurtin (@freenode_rcurtin:matrix.org): yes that is the thing shrit need
< rcurtin>
cool, glad to know that I am on the right track :) I was just guessing, only barely familiar with CLI11
< walragatver[m]1>
jeffin143: Next thing I want to ask is what about the windows build? Have you tried building in windows?
< jeffin143[m]>
<rcurtin "cool, glad to know that I am on "> rcurtin (@freenode_rcurtin:matrix.org): anything which does not have a dash is positional name and that can be unique
< jeffin143[m]>
So help and h will not work out but help and -h will work out help is positional name
< jeffin143[m]>
walragatver: no I have very limited net bandwidth
< rcurtin>
wouldn't we need "--help,-h" instead though?
< jeffin143[m]>
And hence I am unable to download a windows image
< rcurtin>
no hurry on this conversation jeffin143[m], I don't mean to interrupt a meeting with walragatver[m]1 :)
< jeffin143[m]>
<walragatver[m]1 "jeffin143: Next thing I want to "> I will try in ci walragatver
< walragatver[m]1>
jeffin143: Okay, no problem.
< jeffin143[m]>
walragatver yes , I don't have a modem , I use jio mobile hotspot and hence it difficult to download an image and then I wouldn't be able to work :)
< walragatver[m]1>
Let me know if you need any help. I am windows installed on my system
< walragatver[m]1>
having*
< jeffin143[m]>
walragatver: it would be great if you can just try once
< jeffin143[m]>
I have never used Mlpack on windows
< jeffin143[m]>
So I have to figure first how to build mlpack on windows
< jeffin143[m]>
So any help would be appreciated
< RyanBirminghamGi>
People seem to have problems with windows, but we do have the tutorial for it, at least to get you started
< walragatver[m]1>
jeffin143: Okay even I have not used that. But I will give it a try.
< shrit[m]1>
rcurtin jeffin143 I think I found the issue behind this
< rcurtin>
shrit[m]1: awesome, hopefully the fix is easy and works :)
< shrit[m]1>
mlpack is removing them in order to be compatible with boost. Also the order is reversed
< shrit[m]1>
this is the question I would like to ask you, Is it easy to fix?
< rcurtin>
I think so, I think line 101 of add_to_po.hpp just needs to be modified to add the dashes first
< walragatver[m]1>
jeffin143: birm: I am done from my side for today.
< walragatver[m]1>
birm: Anything you would like to discuss?
< jeffin143[m]>
walragatver: there is nothing from my side too , will keep you updated on the include thing
< jeffin143[m]>
shrit: let add them back
< RyanBirminghamGi>
walragatver: jeffin143: I've been a little less attentive than I want to be this week, I'm sorry to say.
< jeffin143[m]>
Ryan Birmingham (Gitter): no issues :)
< shrit[m]1>
I agree, but does mlpack parse the dashsed and remove them or not
< shrit[m]1>
Because it will seems as a hack, Also I have to reverse the order or the first letter and the option to be compatible with CL11 (this one is easy)
< rcurtin>
shrit[m]1: I don't think mlpack will do anything special with it if you add the dashes in add_to_po.hpp
< walragatver[m]1>
birm: It's fine no problem.
< shrit[m]1>
Ok I will try to make things works today.
< walragatver[m]1>
jeffin143: birm: Let's conclude the meet. Thank you for your time. Have a nice week ahead!
< shrit[m]1>
considering cereal, I have added support to arma (not sure if it is working, need testing), I think I only left with boost::variant to serialize
< birm[m]1>
walragatver: jeffin143 (@jeffin143:matrix.org) have a good night!
< rcurtin>
shrit[m]1: sounds great---hopefully the armadillo support was easy to adapt from boost::serialization
< shrit[m]1>
cereal seems to serialize boost::variant in their code, but there is nothing included in their documentation
< jeffin143[m]>
birm (@birm:matrix.org): good night
< jeffin143[m]>
walragatver: good night
< shrit[m]1>
rcurtin It was not hard, but not sure if it was the good way to do it. If things are advancing at this level I can finish the migration before the weekend
< shrit[m]1>
*I mean the correct way of serialization
< walragatver[m]1>
shrit: I just got curious. Would we be replacing boost::variant?
< walragatver[m]1>
Basically it would be quite a lot of code change especially in ann
< rcurtin>
walragatver[m]1: I don't think that's currently a goal for now---at least in the embedded setting it doesn't seem like boost::variant causes massive increases in code size
< rcurtin>
(shrit[m]1 correct me if I'm wrong there)
< rcurtin>
it would be a huge amount of refactoring though, yeah; so maybe better to avoid if we can
< rcurtin>
it might also cause slowdown, depending, so if we as a group thought that it was a good idea, we'd probably want to do a few performance simulations too
< walragatver[m]1>
rcurtin: Thanks for the info.
< rcurtin>
everything is always open for discussion of course :) if you thought it would be a good idea to refactor, we could always open an issue for it and see what people think
< shrit[m]1>
I do not think I am going to remove boost::variant. However, we can use std::variant which is standard in c++17
< shrit[m]1>
This migration can be done in a couple of years, when most compilers on most machines support C++17
< rcurtin>
agreed, at least that would let us avoid some boost headers, which might accelerate compile time
< jeffin143[m]>
@shrit:matrix.org: did you manage to get cli11 work ?
< shrit[m]1>
Yes,
< shrit[m]1>
Still, apparently CLI has aleady a help inside
< shrit[m]1>
I am not sure, but it refuse to compile if I added a help
< shrit[m]1>
sorry (refuse to execute)
ImQ009 has quit [Quit: Leaving]
< rcurtin>
shrit[m]1: the only place that adds `help` is in the file bindings/cli/parse_command_line.hpp
< rcurtin>
however... there could be a problem if *two* objects include parse_command_line.hpp
< rcurtin>
so, if parse_command_line.hpp is included when compiling libmlpack.so, then a definition of --help will be in there
< rcurtin>
and then if parse_command_line.hpp is *also* included in a particular binding's code, then a second definition of --help will end up in the final compiled program
< rcurtin>
as far as I can tell, on the mlpack_rpi branch, `parse_command_line.hpp` is only included by `mlpack_main.hpp` if BINDING_NAME == BINDING_TYPE_CLI
< rcurtin>
but if you have a situation where somehow parse_command_line.hpp is being included by two different translation units, it could be the source of the problem
< rcurtin>
if you have a way to reproduce it I can try and dig further if you like
< shrit[m]1>
rcurtin
< shrit[m]1>
Are you around?
< rcurtin>
yep, I am still here :)
< shrit[m]1>
There are some part of code that I do not understand why they are here
< rcurtin>
finally responding to #2440
< rcurtin>
happy to clarify, let me know what you want me to explain?
< shrit[m]1>
in parse_command_line.hpp there are help, version and verbose, and info
< rcurtin>
it's also possible I may be stumped and not understand why we are there, but we'll see :)
< shrit[m]1>
which are parsed by CMD::HasParam
< shrit[m]1>
In this case CLI11 will never see them
< rcurtin>
what do you mean? the PARAM_*() definition should create a global object that, when constructed, will register itself with CLI11
< rcurtin>
CMD::HasParam() is basically a special overload of CMD::GetParam<bool>()
< rcurtin>
it returns true if the user passed the parameter in that particular run; so it presumably would check with CLI11 if the user passed the parameter
< shrit[m]1>
So if I replace CMD::HasParam() by app.count() it should do the same right?
< rcurtin>
yeah, I think that should be fine, let me glance at the current implementation
< rcurtin>
actually I don't think you need to replace the implementation of CMD::HasParam()
< shrit[m]1>
I know, I have commented mlpack part of checking the commands that entered the double command
< shrit[m]1>
I am afraid I commented more than it should be
< rcurtin>
yeah, I see in the branch that the loop that has the comment "Now iterate through the filled vmap" is commented out
< rcurtin>
if you can uncomment and adapt that, the part where it sets param.wasPassed = true and calls SetParam through the functionMap should be sufficient
< rcurtin>
i.e. if you set param.wasPassed = (app.count() > 0) that should be just fine I think
< shrit[m]1>
I see, boost uses variable map, which is not similar in CLI11, I will see how to adapt it
< rcurtin>
yeah, basically all you need to do is iterate over all possible parameters and call SetParam and set param.wasPassed if the parameter was passed
< shrit[m]1>
rcurtin after I had created the loop, I got a strange segfault from SetParam
< shrit[m]1>
you can check my last commit
< shrit[m]1>
I commented the line
< shrit[m]1>
what I understand that boost_any is going to convert any void pointers,
< shrit[m]1>
line 121 in parse_command_line to be more specific
< rcurtin>
shrit[m]1: no problem, I'll take a look, but it might be tomorrow until I get to it
< shrit[m]1>
No worries, it seems that cereal supports boost variant, I had tried to use it on Knn, but all the variants are pointers
< shrit[m]1>
I have seen you comment on #2440 considering this neighbor class. So maybe we need to go into this direction considering this place for variant