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/
ironstark has quit [Ping timeout: 258 seconds]
ironstark has joined #mlpack
< rcurtin>
zoq: at line 190 of lstm_impl.hpp, do we need to change 'cell2GateInputWeight' to 'arma::repmat(cell2GateInputWeight, 1, batchSize)'?
< rcurtin>
I'm having trouble using the LSTM in some testing code for batchSize > 1, and I think this is the issue but I wanted to check what you thought before I started making changes
< rcurtin>
I think I must be doing something wrong though, since RecurrentNetworkTest uses batchSize > 1 and has no problems...
< zoq>
hm, unless cell2GateInputWeight % cell.cols(forwardStep - batchSize, forwardStep - batchSize + batchStep) does not apply for each col, I guess you would have to use repmat, but I think it does.
< zoq>
But if you have some issues, I guess there is some hidden bug.
< rcurtin>
I'm guessing I've encoded my data wrong, so I will have to double-check that
NakulSabharwal has joined #mlpack
< NakulSabharwal>
Hello! I am Nakul. I'm very interested in projects of mlpack. So... what I should do to join one of these projects?
sourabhvarshney1 has joined #mlpack
NakulSabharwal has quit [Ping timeout: 260 seconds]
< sourabhvarshney1>
I am not getting why is the error occuring in my Pull Request
sourabhvarshney1 has quit [Ping timeout: 260 seconds]
sourabhvarshney1 has joined #mlpack
sourabhvarshney1 has quit [Ping timeout: 260 seconds]
vivekp has quit [Ping timeout: 240 seconds]
lozhnikov has quit [Ping timeout: 258 seconds]
lozhnikov has joined #mlpack
vivekp has joined #mlpack
vivekp has quit [Ping timeout: 248 seconds]
vivekp has joined #mlpack
QuasarSuperstar has joined #mlpack
< QuasarSuperstar>
hello
< zoq>
QuasarSuper: Hello there!
< QuasarSuperstar>
yay somebody is alive in here
< QuasarSuperstar>
:)
< QuasarSuperstar>
Usually when a new user stumbles in a channel for a highly specified topic, that user has a problem
< QuasarSuperstar>
this time is no different
< QuasarSuperstar>
I have problems getting mlpack to work
< zoq>
we can also just talk about random stuff :)
< QuasarSuperstar>
I like random stuff too
< QuasarSuperstar>
like mexican food and jet engines
< zoq>
great I guess we should solve the issue first
alsc has joined #mlpack
< QuasarSuperstar>
but alas, I have issues with boost I think(?)
< QuasarSuperstar>
so I installed armadillo, lapack and all that, pretty much followed everything in the guide to the latter
< QuasarSuperstar>
tried to run an example I found online
< QuasarSuperstar>
/tmp/cc6pn5Wr.o: In function `void boost::serialization::throw_exception<boost::archive::archive_exception>(boost::archive::archive_exception const&)':
< QuasarSuperstar>
knn_example.cpp:(.text._ZN5boost13serialization15throw_exceptionINS_7archive17archive_exceptionEEEvRKT_[_ZN5boost13serialization15throw_exceptionINS_7archive17archive_exceptionEEEvRKT_]+0x25): undefined reference to `boost::archive::archive_exception::archive_exception(boost::archive::archive_exception const&)'
< QuasarSuperstar>
Also I get a ton of warnings about H5 stuff and some packages not linking I guess
< QuasarSuperstar>
Sorry I'm a bit of a linux noob
< QuasarSuperstar>
/usr/bin/ld: warning: libarmadillo.so.6, needed by /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libmlpack.so, not found (try using -rpath or -rpath-link)
< zoq>
miqlas: Hello, setting -j4 if you already have RAM problems is probably not the best idea. One option might be to set -DBUILD_CLI_EXECUTABLES=OFF, in case you don't need the executables.
< QuasarSuperstar>
well that's the output I get, and how do I set that?
< miqlas>
zoq: nah, i got this results with -j 4, but as it bailed out i had a ramdisk 1g or so, so now i try without the ramdisk
< QuasarSuperstar>
and i just checked, no, echo $LD_LIBRARY_PATH returns nothing
< zoq>
QuasarSuper: How did you install armadillo? And where is libarmadillo.so located?
< zoq>
miqlas: Probably an easy fix is to increase swap?
< QuasarSuperstar>
in /usr/bin
< QuasarSuperstar>
I first tried building it, that didn't work
< QuasarSuperstar>
then I read that it automatically installs when apt-get installing libmlpack-dev
< QuasarSuperstar>
so I did that
david_ has joined #mlpack
< zoq>
hm, it's probably picking up the wrong version, are you sure the path is /usr/bin and not /usr/local/lib?
david_ is now known as QuasarSuperstar2
< QuasarSuperstar2>
sorry, timeout
< QuasarSuperstar2>
how do I check that?
QuasarSuperstar has quit [Ping timeout: 255 seconds]
< alsc>
ls /usr/lib/libarmadillo.so.*
QuasarSuperstar2 is now known as QuasarSuperstar
< QuasarSuperstar>
ls: cannot access '/usr/lib/libarmadillo.so.*': No such file or directory
< QuasarSuperstar>
ls: cannot access '/usr/local/lib/libarmadillo.so.*': No such file or directory
< QuasarSuperstar>
so..
< alsc>
is mlpack installed in one of those dirs?
< alsc>
libmlpack I mean
< alsc>
what does sudo apt-get install libarmadillo-dev give you?
< QuasarSuperstar>
hm doesn't seem that way, weird
< QuasarSuperstar>
libarmadillo-dev is already the newest version (1:6.500.5+dfsg-1).
< alsc>
miqlas: you can also -DBUILD_TESTS=OFF
< alsc>
there are options for switching off the bindings in the main CMakeLists if you dont need them too
< miqlas>
alsc: i need the tests to proof it is reliable on haiku
< QuasarSuperstar>
there is some armadillo and mlpack stuff in /usr/lib/x86_64-linux-gnu
< alsc>
I see
< miqlas>
alsc: theese stuffs are really good to check how good or bad haiku can handle enormous loads , and in the same time, mlpack got some big dependecy, which also got plenty other deps, so in the same time i can see how good they plays together
< miqlas>
but thanks for your help, i already seen the options in the cmake file
< miqlas>
oh, and i got 6 gb physical and 6 gb for virtual memory
< miqlas>
and it is a 64 bit haiku, so it can address all of them
< miqlas>
oh, and i build mlpack only with armadillo, boost, hdf5, lapack, openblas, and with superlu
< miqlas>
is there any other useful dep what i should port?
< miqlas>
arpack and atlas is the only 2 other dep what i recognized in the cmake modules folder, and the amd/intel stuff, Haiku got none of them.
< alsc>
sorry miqlas no idea. looks like you’ve got plenty of memory but I am not the expert here. did it work with -j 2
< alsc>
?
< alsc>
QuasarSuperstar: for the time being you could add that path as an -L library include path
< QuasarSuperstar>
fair enough
< alsc>
but definitely strange that those libs haven’t been installed in /usr
< miqlas>
alsc: it tops nicely with -j2 too, but seems to be ok now
< QuasarSuperstar>
I'll try that and reinstalling them
< miqlas>
is there any mlpack developer here?
< alsc>
weird also because it shouldnt find the headers before giving linker errors
< miqlas>
mlpack depends on hdf5 and superlu (at least for me), but it doesn't warns if they are missing. I think the mlpack devs should implement a check for it, and update the readme files according it.
< zoq>
QuasarSuper: I guess if you install the hdf5 package it should at least solve the first warnings
< zoq>
miqlas: mlpack does not depend on hdf5, but if you build armadillo with hdf5 support it does.
< miqlas>
i did the hddf5 port and yes it depends on hdf5
< miqlas>
ah. building mlpack takes ages on my X200. Let's make a dinner while it compiles
< QuasarSuperstar>
I removed all the packages, mlpack, armadillo, hdf5
< QuasarSuperstar>
then just let apt-get install libmlpack-dev do its thing
< QuasarSuperstar>
same result
alsc has quit [Quit: alsc]
alsc has joined #mlpack
< QuasarSuperstar>
welp
< QuasarSuperstar>
so there is one libarmadillo.so in /usr/lib but that is supposedly broke
< QuasarSuperstar>
broken
< QuasarSuperstar>
says type: link (broken)
< QuasarSuperstar>
also I have libarmadillo.so.8 in that folder
< QuasarSuperstar>
how do I link .so.6 to that?
< QuasarSuperstar>
ok figured that out
< QuasarSuperstar>
now
< QuasarSuperstar>
whats mkl_rt?
< QuasarSuperstar>
all I can find out about it is that it's some part of python/scipy?
david_ has joined #mlpack
< david_>
grrr
david_ is now known as QuasarSuperstar2
QuasarSuperstar has quit [Ping timeout: 255 seconds]
QuasarSuperstar2 is now known as QuasarSuperstar
< QuasarSuperstar>
/usr/bin/ld: warning: libmkl_rt.so, needed by /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libarmadillo.so, not found (try using -rpath or -rpath-link)
< QuasarSuperstar>
is mkl the intel math kernel library?
< QuasarSuperstar>
I even went and installed python and scipy
< QuasarSuperstar>
and I still get that error when compiling
< anerishah97>
Hello! I am Aneri Shah, and I am really interested and want to start contributing to mlpack, however I am relatively new to open source development. I checked out the list of issues on the github page and will try out to solve the easy ones. Any advice or suggestion?
< zoq>
anerishah97: Hello, just go with the one you find interesting.
< QuasarSuperstar>
alrighty
< anerishah97>
Okay, thank you @zoq :)
< QuasarSuperstar>
building now
< zoq>
QuasarSuper: Okay, let me know if you run into any issues, afterwards we should check if you can build a simple program.
< zoq>
You should also see some sort of warning if you configure mlpack.
< miqlas>
haven't seen or haven't noticed.
< miqlas>
but as we do recipes for the ports and as the recipe clearly defines the requiments, there will be no problem in the future as it already defined hdf5 for mlpack
< zoq>
okay, great
< miqlas>
almost ready ... small troubles with the packaging. (we have no includes folder)
< miqlas>
-s
< miqlas>
guys, is there any nice sample program for mlpack what shows the features? like picture ocr or something like that?
< rcurtin>
but depending on the Armadillo version you might need an #ifdef for it; I believe that some Armadillo version older than 6.500.0 loads HDF5 matrices transposed, but 6.500.0 and newer do not
< miqlas>
i got armadillo 8.200.1
< rcurtin>
ok
< rcurtin>
if that's the version distributed in Haiku and users will always have > 6.500.0, then you can take that diff as-is
< rcurtin>
I'll include the CMakeLists change in your package, thank you for taking the time to figure that out :)
alsc has quit [Quit: alsc]
< rcurtin>
(however that'll be in the git master branch, so it'll be a part of the mlpack 3.0.0 release, but not 2.2.5 of course)
< brni>
yeah, its open and there is currently no open PR. Is there anything i should know prior to working on this. This issue was first opened in february it seems.
< rcurtin>
brni: no, I think the issue is still fresh; the decision tree program hasn't actually been modified since then
< miqlas>
rcurtin: haiku users will have alvays >6.500 , as earlier version was never ported
< rcurtin>
a lot of people said they would work on it but nobody actually produced any code
< miqlas>
let's update our "ancient" armadillo then
< brni>
rcurtin: okay, thank you for prompt reply. I'll start with it then.
< rcurtin>
brni: if you're not very familiar with the decision tree code or with mlpack command-line programs, I would say a nice "warmup" would be to add support to the program so that you can use either GiniGain or InformationGain
alsc has joined #mlpack
< rcurtin>
for either that or the original problem, the key will be in modifying the DecisionTreeModel structure so it can hold multiple types; as an example you could take a look at NeighborSearchModel or RangeSearchModel or similar
< rcurtin>
alsc: sorry I dropped out last week, I was at a conference---I have looking at the code you sent on today's todo list :)
< miqlas>
rcurtin: thanks for upstreaming my patch
< rcurtin>
miqlas: no problem---if you have any other issues please do report them and we can get a fix in :)
< miqlas>
rcurtin ;)
< miqlas>
just updated the armadillo port, and have seen it could use arpack too and we still donn't have ARPACK
< miqlas>
then lets port it
< rcurtin>
miqlas: newer Armadillo actually comes with an internal reimplementation of ARPACK from a GSoC student
< rcurtin>
I think that one is enabled by default if I remember right
alsc has quit [Quit: alsc]
< miqlas>
rcurtin: there is stil lsome strange software what need only arpack but not armadillo
< miqlas>
so better to port it before somebody else does it
< miqlas>
hi from the haikuporter team, btw
< rcurtin>
ah, good point
< rcurtin>
I think arpack was easy to build
< rcurtin>
I met some Haiku folks at the Google Summer of Code mentor summit, nice project, nice people :)
< rcurtin>
(I can't remember who they were though :( )
< QuasarSuperstar>
ok followed all the instructions
< QuasarSuperstar>
mlpack_knn: error while loading shared libraries: libmkl_rt.so: cannot open shar
< QuasarSuperstar>
still that stupid libmkl_rt.so
< QuasarSuperstar>
what is that?
< rcurtin>
QuasarSuperstar: I only sort of followed the discussion from this morning, do you have Intel MKL installed at all?
< QuasarSuperstar>
well I've been asking if that's what it is
< rcurtin>
Armadillo can use multiple different LAPACK and BLAS backends, and MKL is one of them... if Armadillo is trying to use MKL on your system, I'd expect that you have MKL installed
< rcurtin>
yep, that is exactly MKL :)
< QuasarSuperstar>
guess...not?
< rcurtin>
how did you install Armadillo?
< QuasarSuperstar>
package manager
< rcurtin>
what OS?
< QuasarSuperstar>
linux mint
< rcurtin>
that's built on Debian
< QuasarSuperstar>
yeh
< rcurtin>
at least the Debian armadillo package doesn't use MKL (and shouldn't since MKL isn't open-source)
< QuasarSuperstar>
sooo why does it depend on it?
< QuasarSuperstar>
weird
< rcurtin>
of this I am not sure...
< rcurtin>
your system has libarmadillo.so in /usr/lib/, right?
< rcurtin>
what is the output of 'ldd /usr/lib/libarmadillo.so' (or whatever the path of armadillo is)?
< QuasarSuperstar>
lemme check
< QuasarSuperstar>
i think it was in some sub directory of that
< rcurtin>
can you do that in a wider terminal? that cuts the version number: 6.500.5+df...
< QuasarSuperstar>
1:6.500.5+dfsg-1
< rcurtin>
ok, thanks
< rcurtin>
hm, I am really not sure what is going on here... we can continue trying to figure out why it is linked against the MKL if you like
< rcurtin>
or alternately you could uninstall that package and install armadillo from source, which I think would be the easier idea
< rcurtin>
then reconfigure and rebuild mlpack
< QuasarSuperstar>
yeah, I've been pulling my hair for a while
< rcurtin>
I'm curious to know what's happened but at the same time you just wanted to use mlpack, not debug an entire system full of strangeness :)
< QuasarSuperstar>
so build armadillo from source too?
< rcurtin>
my next question in that direction would be whether or not libmkl_rt.so is anywhere on the system, but your call whether or not you want to keep digging
< rcurtin>
yeah, build armadillo from source (it's pretty easy)
< rcurtin>
I think I can give all the commands from memory basically...
< QuasarSuperstar>
I did search the whole lib folder for it
< rcurtin>
then unpack the source and it's just './configure' 'make' 'sudo make install'
< rcurtin>
so very easy to remember :)
< QuasarSuperstar>
true
< QuasarSuperstar>
I probably hammered in sudo apt-get install libwhatever-dev and remove and autoremove and make and cmake and install and so on in all combinations thinking I must be doing something wrong
< QuasarSuperstar>
anyway
< QuasarSuperstar>
I'm a linux nap, what is the best way to remove and kill armadillo and all its appendages before reinstalling?
< miqlas>
arpack is ready :Ö
< rcurtin>
QuasarSuperstar: hm, apt-get purge libarmadillo* should be fine
< rcurtin>
miqlas: :)
< miqlas>
and all the tests passed
< QuasarSuperstar>
oh purge, that sounds better than remove
< QuasarSuperstar>
purge all the things!
< miqlas>
format c: /s
< QuasarSuperstar>
rm -rf
< QuasarSuperstar>
good old days where the endall solution was format c:
< QuasarSuperstar>
enema of the noughties
< QuasarSuperstar>
and nineties too I guess
< miqlas>
Found ARPACK: /boot/system/develop/lib/libarpack.so :)
< miqlas>
the tensorflow guys broked my haiku port :(
< rcurtin>
ok now this is the strangest thing I heard all day
< miqlas>
thanks for god mlpack got no billions of in-tree 3rdparty deps
< miqlas>
rcurtin: what?
< rcurtin>
I received a phone call from FedEx... apparently, someone _stole_ the fedex truck, and my package fell out of the back of it while the truck was being stolen
< miqlas>
oh
< rcurtin>
now I have to go pick up the package at their location because some random person picked up the package and brought it to the fedex store
< rcurtin>
I'm very confused
< miqlas>
have you got a car? you can follow them and shout them: you bastards you stole my package! and lost my package!
< QuasarSuperstar>
lol
< rcurtin>
apparently this happened way before the package even got to my neighborhood, so it's like 20 miles away
< QuasarSuperstar>
so, arpack
< QuasarSuperstar>
libarpack2-dev? or libarpack++2-dev
< miqlas>
oh, i just noticed, i'm working on 3 laptop simultan :S
< miqlas>
the end is near.
< rcurtin>
QuasarSuperstar: just libarpack2-dev, although technically that is optional
< QuasarSuperstar>
oki
< QuasarSuperstar>
and ive seen a bit about armadillo versions of mlpack and armadillo
< QuasarSuperstar>
so 7.800, 7.960 or 8.200?
< rcurtin>
any version is fine, probably newest is best
< QuasarSuperstar>
so somebody decided to revive it?
< miqlas>
hmm, wiki says '91-2001
< miqlas>
QuasarSuperstar: correct. it happend in 2001 as Be went down
< miqlas>
aaaaand we wil lhave a beta soon (TM)
< QuasarSuperstar>
well guess I found one of "small number of enthusiasts@
< QuasarSuperstar>
"
< QuasarSuperstar>
lol
< miqlas>
uhum. i used to read about BeOs in '98 or '99 and since them i'm with the project
< QuasarSuperstar>
So you will have mlpack natively?
< miqlas>
uhum
< QuasarSuperstar>
hmmmm
< QuasarSuperstar>
I am intrigued
< miqlas>
just published the recipe right now
< miqlas>
QuasarSuperstar: we got no cuda and fancy things like that
< QuasarSuperstar>
aw
< miqlas>
so you won't get accelerated ml on haiku
< QuasarSuperstar>
is that in the pipeline tho?
< miqlas>
i have no idea about gpu support in mlpack, but we have no support for it
< QuasarSuperstar>
The place I work at has a few tesla cards, so...
< miqlas>
QuasarSuperstar: yes, but nobody working on gpu support right now
< miqlas>
and if somebody starts it will be generic 3d acceleration, not an opencl/cuda thing
< QuasarSuperstar>
cuda would be nice
< miqlas>
at least not first
< QuasarSuperstar>
but ok
< QuasarSuperstar>
rebuilding mlpack...again
< miqlas>
do not ask why i port heavy things like tensorflow and stuff, my ports already got a title in haikuports team: "NobodyWillEverUseIt(TM)"
< QuasarSuperstar>
ahh
< QuasarSuperstar>
so I thought to just retry ldd /usr/lib/x86_64-linux-gnu/libarmadillo.so
< QuasarSuperstar>
and this line popped up in it again
< QuasarSuperstar>
libmkl_rt.so => not found
< QuasarSuperstar>
even though I completely rebuild armadillo
< QuasarSuperstar>
T_T
< QuasarSuperstar>
darn you mkl
< QuasarSuperstar>
Can I find out where this mkl is hiding?
< QuasarSuperstar>
or when configuring armadillo, how do I tell it to not use mkl
< QuasarSuperstar>
or hdf5, cause that's been causing me a pain too
< QuasarSuperstar>
wait... ryan curtin, rcurtin, is that you?
< rcurtin>
QuasarSuperstar: can you paste the output of the armadillo ./configure command?
< rcurtin>
and yes, I am ryan :)
< QuasarSuperstar>
hah cool
< QuasarSuperstar>
sec
< rcurtin>
miqlas: yes, but now I can say when I give talks that mlpack is available on Haiku also :)
< miqlas>
do that!
< miqlas>
you know, i do the mathematical stuff for haiku, so plenty libs and things. almost nobody would use it, but you know how much pain if you want to port softwareA, what requires softwareB, and it requires libC, what requires libD, and it requires BLAS or ARMADILLO, or LAPACK or stuff liek that
< miqlas>
so maybe my work is invisible, it helps us to get real-word softwares for haiku
< rcurtin>
heh, I am sure some server somewhere is getting quite warm...
< miqlas>
for sure
< miqlas>
but it is a vm, so the server gets pretty warm
< rcurtin>
yep
< rcurtin>
we have a build server that we use to heat the town of Springfield, Oregon by running many builds each day
< miqlas>
the stuff gets built in chroot, that's why it cannot find git
< miqlas>
we don't want provide git for the build process", as we want complete control about the sources, so it isn't okay if the built stuff just pulls stuff from external source with git.
< miqlas>
if it is possible i prefer to use github provided sources. i don't like to generate load on the project own webserver if it isn't required.
< rcurtin>
seems like a simple packaging format, nicer to read than debian's :)
< rcurtin>
fair, I can agree with that reasoning. also it's likely that github will have slightly better uptime than mlpack.org (although we haven't really had many downtime issues in 2 years with this hosting)
< miqlas>
the build server is aktually pretty fast compared to my small laptop
< miqlas>
with core2duo ultra lov voltage cpu :)
< rcurtin>
I have a little chromebook and when I compile mlpack on it, it takes typically over an hour...
< rcurtin>
I think ccache could help a lot, but I have never actually bothered to try it
< miqlas>
i used to build gcc on this thing, THAT was fun.
< miqlas>
you know if something wrong with the recipe, the build process just bails out, we have no control over it from the outside, so recipe change -> testbuild -> fail -> recipe change -> build -> built, but bails out at packaging -> recipe change -> builds, packages
< miqlas>
daaaays
< rcurtin>
yep
< rcurtin>
really slow iterative process
< miqlas>
then somebody told, if it built once, then i don't need to rebuild it from scratch, i can explicitly define it is already built, so it starts with INSTALL()
< miqlas>
rcurtin, and the fact that i have nothing to do with CS doesn't makes my life easier.
< rcurtin>
:) I think at least for something like compiling and packaging, CS knowledge isn't *that* necessary, moreso just experience with the command line and related utilities
< miqlas>
there is 2 small problem in my mlpack recipe, i defined strip hovewer i don't use it, so i'll clean that up in a next revision.
< miqlas>
true, but you have to get builtt it first to be able to package it
< rcurtin>
fair---well let me know if you have any build problems with your recipe and I can help try to debug
< miqlas>
ok, the math libs like lapack doesn't really requires extensive patching, but php, blender, caffe, opencv and vim required plenty.
< miqlas>
rcurtin, according to my test, only that hdf5 test: /sources/mlpack-mlpack-2.2.5/src/mlpack/tests/load_save_test.cpp(637): fatal error: in "LoadSaveTest/LoadHDF5Test": critical check test.n_rows == 4 has failed [2 != 4] bug exist on haiku
< miqlas>
and i can fix it in armadillo, so no changes required (AFAIK) in mlpack
< miqlas>
so i have to go to sleep
< miqlas>
bye guys
< miqlas>
and thanks for the help
< rcurtin>
sure, talk to you later :)
< rcurtin>
I don't think you need to fix the HDF5 code in Armadillo (unless you want to just disable HDF5 there)
< rcurtin>
you can just use the patch I sent earlier; with Armadillo 6.500.5 and newer, Armadillo no longer transposes HDF5 matrices on load, so the code in mlpack's load_impl.hpp is incorrect
< rcurtin>
or to be more specific, mlpack's load_impl.hpp that shipped with version 2.2.5 (or older) is incorrect when used with Armadillo >= 6.500.5
alsc has joined #mlpack
< zoq>
wow, the discussion continued
< rcurtin>
yeah, an active day in #mlpack :)
< zoq>
rcurtin: Did you get your package? Nice that someone was so kind to bring it in.
< rcurtin>
yeah, I did just an hour ago actually; drove up to the store and picked it up
< rcurtin>
no damage either
< rcurtin>
so today I am lucky :)
< zoq>
nice :)
< alsc>
hey guys, do you remember the question about monitoring the loss and being able to stop the loss during gradient descent?
< alsc>
no to stop the loss , bad paste:)
< alsc>
well I wonder if you think they could be useful features
< zoq>
Yeah, I guess we haven't had time to take a closer look at the code yet.
alsc has quit [Read error: Connection reset by peer]
alsc has joined #mlpack
< rcurtin>
zoq: I see, it looks like the test does not fail for batch size > 1 because it never actually runs batch size > 1
< rcurtin>
all of the tests in recurrent_network_test.cpp except SerializationTest build the network by calling Train() on a single point at a time
< rcurtin>
only SerializationTest does otherwise, and the SimpleSGD optimizer uses a batch size of 1... if I change it to 2, I get 'error: addition: incompatible matrix dimensions: 4x10 and 4x2'
< rcurtin>
so I will go ahead and make changes as needed to LSTM and add some tests
< zoq>
ohh, okay, if you don't have time to take a look at the issue let me know.
< rcurtin>
sure, I think I can debug it at least for LSTMs quickly
< rcurtin>
zoq: alsc: for the early termination of the optimization, I wonder if we could benefit by adding a template parameter to the SGD<> class---a termination policy (just like for the AMF class)
< rcurtin>
that could allow the user to control termination based on some condition they were concerned with, like validation error or something like this
< rcurtin>
and if the user is interested in only setting a maximum number of iterations or calculating the validation error, we can ignore the "extra" objective calculations currently in SGD<> to accelerate things a bit
< alsc>
like a callback, interactively, called each iteration?
< rcurtin>
yeah, a 'templated' callback so there is no extra overhead to call it :)
< alsc>
ah yeah sounds good!
< rcurtin>
I'd be curious what zoq thinks, we'd need to make sure it is easy enough to use
< rcurtin>
since the optimizer doesn't have access to the model itself, it might be a bit tricky to compute validation error, but I think it is possible
< alsc>
I’m plotting the loss, sometimes when it starts descending too slowly I’d just stop it there
scott__ has joined #mlpack
< alsc>
I see what you mean with running validation, yeah that would be nice indeed
scott__ has quit [Client Quit]
< rcurtin>
let's see what zoq thinks; maybe there is a better way to accomplish the same type of functionality
< zoq>
eah, how do we calculate the validation error, besids that this sounds like a clean solution to me.
< rcurtin>
maybe the user has to pass the network itself to the termination policy? but that feels a bit awkward
< rcurtin>
for me the comparison would be with Keras (and similar) where you can trivially add 'callbacks' to the network
< alsc>
if I can access the model from the callback, I’d just classify against a validation set myself.. could be external
< rcurtin>
wait, hang on---the optimizer _does_ have access to the model
< rcurtin>
since the optimizer's FunctionType is actually just the model itself
< zoq>
via the function
< zoq>
right
< rcurtin>
so we can pass the FunctionType (which will be FFN<> or RNN<> in this case) to the termination policy, which can then assume an FFN<> or RNN<> and call Classify() or whatever
< rcurtin>
yeah, ok, that fixes the only issue I had with the idea then :)
< alsc>
😎
< zoq>
So who likes to implement the idea? Might be a good starter task.
< rcurtin>
yeah, I guess we should write it up as an issue
< alsc>
I can do it in the context of some work I am doing
< alsc>
calmly as things are being a bit hectic. will ping you when I have a first implementation
< zoq>
If alsc likes to work on it, I think we don't have to come up with an issue :)
< rcurtin>
sure, that sounds fine to me
< alsc>
word then
< rcurtin>
the methods/amf/ code should have an example of a TerminationPolicy type, but that was made for a different context... I think the idea could be adapted either way
< rcurtin>
alsc: I looked at the bestRankingClass() function too, I think we could adapt that into a KNNClassifier or something if you want
< rcurtin>
my only thought is we could templatize the 'distanceType' so that a user can use an arbitrary distance weighting scheme
< alsc>
sounds good
< alsc>
not that great with those maps atm
< alsc>
better ideas?
< rcurtin>
actually this is really similar to the code for decision trees... we have to count up the number of elements of each class
< rcurtin>
for (size_t i = 0; i < distances.n_elem; ++i)
< rcurtin>
counts[selectedLabels[i]]++;
< alsc>
ah yeah
< rcurtin>
but, hm, I am not 100% sure I am understanding everything right, is that for just one query point or for the whole indices/distances matrices?
< rcurtin>
in any case the basic idea should be straightforward
< alsc>
for the whole indices/distances
< rcurtin>
maybe instead of counts[selectedLabels[i]]++, if the weighting strategy is templatized, something like 'counts[selectedLabels[i]] += ComputeWeight(distances[i])' ??
< rcurtin>
or something kind of like that
< rcurtin>
but I guess, counts actually has to be a matrix, since you want the number of points of each class for each query point
< rcurtin>
anyway I have to run and get dinner for now; talk to you later
< alsc>
so you want to classify a whole matrix you mean^
< alsc>
ok, I go to bed instead. bon appetit and talk later
deepanshu_ has quit [Quit: Connection closed for inactivity]