verne.freenode.net changed the topic of #mlpack to: http://www.mlpack.org/ -- We don't respond instantly... but we will respond. Give it a few minutes. Or hours. -- Channel logs: http://www.mlpack.org/irc/
vivekp has joined #mlpack
sourabhvarshney1 has joined #mlpack
vivekp has quit [Ping timeout: 240 seconds]
vivekp has joined #mlpack
arunikayadav42 has joined #mlpack
sourabhvarshney1 has quit [Ping timeout: 260 seconds]
sourabhvarshney1 has joined #mlpack
vivekp has quit [Ping timeout: 264 seconds]
vivekp has joined #mlpack
arunikayadav42 has quit [Quit: Page closed]
alsc has joined #mlpack
alsc has quit [Quit: alsc]
sourabhvarshney1 has quit [Ping timeout: 260 seconds]
Quasar has joined #mlpack
sourabhvarshney1 has joined #mlpack
manish7294 has joined #mlpack
< manish7294>
Hello, I am new here and I would like to work on Generative adversarial network. Could you please suggest me any algo implementation on which I can work on.
QuasarSuperstar has joined #mlpack
Quasar has quit [Ping timeout: 256 seconds]
sourabhvarshney1 has quit [Ping timeout: 260 seconds]
< QuasarSuperstar>
so I tried to get mlpack to also work on windows 10's linux bash console
< QuasarSuperstar>
just needed to build armadillo properly
< QuasarSuperstar>
:)
govg has joined #mlpack
sourabhvarshney1 has quit [Ping timeout: 260 seconds]
sourabhvarshney1 has joined #mlpack
arshdeep has joined #mlpack
< arshdeep>
HI
< arshdeep>
anybody?
arshdeep has quit [Client Quit]
< zoq>
arshdeep: Hello, there!
sourabhvarshney1 has quit [Ping timeout: 260 seconds]
manish7294 has quit [Ping timeout: 240 seconds]
manish7294 has joined #mlpack
sourabhvarshney1 has joined #mlpack
sourabhvarshney1 has quit [Client Quit]
alsc has joined #mlpack
govg has quit [Ping timeout: 260 seconds]
< zoq>
rcurtin: Looks like sometimes we still run into some apt-get problems (#1166), not sure but as a last resort we could just remove the lock and move on?
< alsc>
hey guys, can anybody explain me why in the ANN tests, the sigmoid layer is always used right after the input layer and not as I would expect after the hidden layer?
< alsc>
do you have any idea about what should indicate me to try and add a Dropout layer?
< alsc>
I wish there was a nice guide with stuff like: first do a vanilla feedforward network. if results arent good enough, then test this. it it takes forever to train, test that… and so on
< rcurtin>
zoq: kind of insane that we are having these issues... I guess removing the lock forcefully is something we could try, but if another apt process is running it could make things weird
< alsc>
looks cool! I am working on way less sophisticated/shallow networks, with 1D feature vectors… in my mind I kind of wanna push this to the maximum before starting using many layers
< alsc>
also because it should work on embedded devices so I can’t afford too many coefficients… I wanna squeeze the last bit of performance through data preprocessing and classic ANN settings
< zoq>
I guess, for finetuning you could use the hyperparameter optimization method?
< rcurtin>
I'm not sure I've heard any reports of anyone using it yet, so if you wanted to give it a try I'd be happy to help out and adapt any feedback into the tutorial and code
< alsc>
I will definitely go through it, thanks. my optimization method is super brute force at…
< alsc>
I am creating all the permutations of all the parameters in a yaml input file and test the validation accuracy of each configuration step
< alsc>
so I am definitely up to test something more refined also because what I do can take ages and test lots of configurations that I know dont make too much sense
< alsc>
ah ok that’s more or less what this code does up to when it speaks about gradients… “In some cases we may wish to optimize a hyperparameter over the space of all possible real values, instead of providing a grid in which to search.”
alsc has quit [Ping timeout: 240 seconds]
manish7294 has quit [Ping timeout: 264 seconds]
manish7294 has joined #mlpack
alsc has joined #mlpack
Quasar has joined #mlpack
QuasarSuperstar has quit [Ping timeout: 264 seconds]
< rcurtin>
alright, the sticker onslaught begins... I emailed all old mlpack contributors and offered to mail them stickers
< rcurtin>
so I think I'll spend a lot of time at the post office in the next while
alsc has left #mlpack []
alsc has joined #mlpack
brni has quit [Ping timeout: 260 seconds]
< zoq>
rcurtin: Let me know, if I should mail some too, it might be faster and cheaper from europe.
< rcurtin>
sure, I'll coordinate and let you know where stickers need to go
< rcurtin>
ah oops, typing faster than I was thinking
< rcurtin>
I hadn't gotten back around to checking on that one yet, thanks for pointing it out
< manish7294>
Hi, there is only mean square error implementation in ann. So, I want to ask whether I can implement mean absolute error or any other loss function.
< zoq>
There is also cross entropy and negative log likelihood, but if you like to see another one e.g. mean absolute error as you said please feel free.
< miqlas>
but interestingly this recipe worked for me locally. Still investigating.
< rcurtin>
miqlas: I guess I am not sure enough about haiku to know exactly the way things need to be
< rcurtin>
mlpack.pc won't be generated if pkg-config isn't found, by the way
< rcurtin>
so maybe simply that would be a solution (but that's not very good for anyone who might want to use pkg-config and mlpack on haiku... but I bet that set of people is very small anyway...)
< miqlas>
it built with pkgconfig locally
< miqlas>
and the .pc file got installed too
< miqlas>
rebuilding right now locally, as i cannot post-mortem investigate the build-bot build folder as it gets purged.
< miqlas>
so it will be a fun night with plenty fan-noise
< rcurtin>
heh
< rcurtin>
you might have to do what we did with travis... add lots of "echo" and "ls" to try and figure out the state of the system on the buildbot...
< miqlas>
hmm... no, that won't help
< miqlas>
i need to find where the pkgconfig file gets installed. And where does it gets the path.
< miqlas>
because only the path is wrong.
< miqlas>
at the end of the main cmakefile i see this:
< miqlas>
but where does the DESTINATION comes from?
< rcurtin>
I think I hardcoded that DESTINATION because every system I found with pkgconfig put it there
< rcurtin>
if that needs to change maybe we can make it more flexible, but like I said I dunno where it is supposed to go on haiku :)
s1998 has joined #mlpack
s1998 has left #mlpack []
s1998 has joined #mlpack
< miqlas>
rcurtin: it should go into $libdir/pkgconfig
< miqlas>
nothing fancy
< miqlas>
just let us pass an absolute path to cmake, like -DPKGCONFIG_INSTALL_PATH or something
< miqlas>
rcurtin: does the binaries mandatory for the lib?
< miqlas>
i think no.
< miqlas>
It seems one can compile mlpack without them. (BUILD_CLI_EXECUTABLES)
alsc has quit [Quit: alsc]
< rcurtin>
miqlas: sure, do you want to put together a patch again for something like PKGCONFIG_INSTALL_PATH?
< rcurtin>
and yeah, the binaries are not mandatory but I think they are the most useful part of the library for an end user
< rcurtin>
some distributions package these separately from the library; debian has libmlpack, mlpack-bin, and mlpack-dev if I remember right
alsc has joined #mlpack
< miqlas>
rcurtin: i don't want to remove the cli stuff, but outsource them from the main package. The point is: i can imagine that user application would be depend on mlpack, so one needs to install the main package. But if one have no interest in developing new things then the cli stuff is useless.
< miqlas>
so i defined an extra package for the cli stuff, what depend on the main package.
< rcurtin>
yep, that sounds similar to what the other packagings do
< miqlas>
so the main package will contain only the lib. the cli package will contain all the cli apps, and the devel package all the headers and pc file
< rcurtin>
yeah, exactly, I think that is the best way to do it
< miqlas>
rcurtin: sorry, i'm not very good with cmake, and no idea how to patch the pkgconfig install section what doesn't break the hell on other platforms.
< miqlas>
I suppose i just comment the .pc install part now and manually copy it to the right place.
< miqlas>
or something.
< rcurtin>
hm, you can do that if you like; let me get the code that would be needed, hang on
< rcurtin>
up at the top, under all of the option()s, you could do
< miqlas>
this is the include folder, so it got all the header files.
< rcurtin>
right, I see, if you want to patch that also you can do it in the same way as PKGCONFIG_INSTALL_PATH
< miqlas>
yep, it is a PITA to adjust all the ports but it was so on BeOS so we cannot change it.
< rcurtin>
I could also see someone on Windows also wanting to adjust that in some situations so allowing the install include path to be set could be useful
< miqlas>
rcurtin: but if i understood you right i don't have to patch the pkgconfig stuff if i define the CMAKE_INSTALL_PREFIX right?
< rcurtin>
*could be useful for more than just Haiku
< rcurtin>
miqlas: yes, that is true, if you can use CMAKE_INSTALL_PREFIX to get what you need there is no need to update
alsc has joined #mlpack
< miqlas>
Haiku is love, Haiku is life.
< rcurtin>
er, 'no need to patch'
< miqlas>
rcurtin, currently my recipe doesn't defines CMAKE_INSTALL_PREFIX, so i try first to define it instead patching the cmake files
< rcurtin>
miqlas: sure, sounds good, it will be the easier way to go
< rcurtin>
to be honest copying all the files for the include directory might be the easiest thing to do also
< miqlas>
the include dir location already handled by my recipe
< miqlas>
lets the party begin!
< miqlas>
# hp mlpack
< miqlas>
(hp = haikuporter executable)
< miqlas>
Umm...
< miqlas>
Manually-specified variables were not used by the project: CMAKE_INSTALL_BINDIR CMAKE_INSTALL_DATADIR CMAKE_INSTALL_DOCDIR CMAKE_INSTALL_INCLUDEDIR CMAKE_INSTALL_LIBDIR CMAKE_INSTALL_MANDIR
< miqlas>
So then why on earth did i specified them ? :D
< miqlas>
yeah, they are ignored as no handling implemented in the cmake files.
< rcurtin>
yeah, you can only specify CMAKE_INSTALL_PREFIX and things will be installed to ${CMAKE_INSTALL_PREFIX}/include or bin or whatever else
< miqlas>
ok, i see.
< miqlas>
removed the unneeded stuff. cleaned things a bit up , now it can run
< miqlas>
-- Found PkgConfig: /boot/system/bin/pkg-config (found version "0.29.2")
< miqlas>
looks good
< miqlas>
you know, in haiku everything packaged, and if somebody installs a package, like mlpack, the package gets downloaded and moved in a special location. It hovewer doesn't gets extracted. Never.
< miqlas>
The package-daemon recognizes the package and virtually populates the file-system. On the fly.
< miqlas>
So if you remove the package, in the same time all the virtually extracted file goes dissapear
< miqlas>
thats why all the system folder read-only
< miqlas>
actually almost 95% of the system disk is read only, as they just virtually extracted files
< miqlas>
strange concept, but it lets us to easily create an temporary chroot environment, attach the required packages (declared in the recipe), and build the softwares in this closed environment
< miqlas>
absolute control over the dependencies
< rcurtin>
right, it is nice to be able to do that to make sure that the package isn't writing where it shouldn't
< miqlas>
yep. But one still can compile stuff in the home folder with the traditional way as in linux, as the home folder is not read-only.
< miqlas>
actually it isn't true, as partially it is also read only, but you got the point
< miqlas>
nah, i go watching movies
< miqlas>
bye and thanks for your help
< rcurtin>
sure, enjoy your movies :)
< miqlas>
Just checked the build folder, and i see this:
< miqlas>
file(INSTALL DESTINATION "${CMAKE_INSTALL_PREFIX}/lib/pkgconfig" TYPE FILE FILES "/sources/mlpack-mlpack-2.2.5/build/lib/pkgconfig/mlpack.pc")
< miqlas>
that path looks ok
< miqlas>
so bye
< miqlas>
rcurtin: Absolutely important question: how about backwards compatibility?
< alsc>
I would reeeeeally like to speed up the compilation time on mac, can you give some advice?
< alsc>
I am using just ANN related stuff… can I instantiate some templates in a translation unit other than where main() is? I have never done this
< rcurtin>
alsc: you can use 'extern templates' to do that, we do it in src/mlpack/core/data/load.cpp for instance
< rcurtin>
you could also try using ccache, I've never tried it but it could really help (or so I hear)
< alsc>
ah yes, I had looked at the file before.. so for example what could I instantiate?
< alsc>
I actually have all the mlpack related things wrapped/hidden by other files that I am not touching, still it takes a lot to compile
< alsc>
does that matter at all? shall I still do the extern template thing I guess
< rcurtin>
hmm, it depends on what is actually slow in the compilation
< rcurtin>
reducing the amount of stuff you include is helpful where possible
< rcurtin>
s1998: it fails because the code is failing to build; look at the 'console output'
< alsc>
I am using just FFN<NegativeLogLikelihood<>>, the templated Add for layers and RMSProp, in a translation unit that should have already been compiled. still whenever i touch a line in a user code, it takes really long
< alsc>
ok I think I nailed it :)
< s1998>
oh, okay
< rcurtin>
alsc: good to hear you got it worked out; if you see any ways to help accelerate compilation that could be changed in the core library we can definitely incorporate those changes