| --- Log opened Sun Jul 28 00:00:50 2013 | ||
| shogun-buildbot | build #1412 of deb3 - modular_interfaces is complete: Failure [failed test python_modular] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/1412 blamelist: Soeren Sonnenburg <sonne@debian.org> | 00:05 |
|---|---|---|
| -!- travis-ci [~travis-ci@ec2-54-234-43-199.compute-1.amazonaws.com] has joined #shogun | 00:07 | |
| travis-ci | [travis-ci] it's Soeren Sonnenburg's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: http://travis-ci.org/shogun-toolbox/shogun/builds/9561667 | 00:07 |
| -!- travis-ci [~travis-ci@ec2-54-234-43-199.compute-1.amazonaws.com] has left #shogun [] | 00:07 | |
| shogun-buildbot | build #1287 of deb2 - static_interfaces is complete: Failure [failed compile r_static] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb2%20-%20static_interfaces/builds/1287 blamelist: Soeren Sonnenburg <sonne@debian.org> | 00:08 |
| shogun-buildbot | build #1413 of deb3 - modular_interfaces is complete: Failure [failed compile r_modular] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/1413 blamelist: Soeren Sonnenburg <sonne@debian.org> | 00:28 |
| shogun-buildbot | build #1096 of cyg1 - libshogun is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/1096 blamelist: Evgeniy Andreev <gsomix@gmail.com>, Soeren Sonnenburg <sonne@debian.org> | 00:36 |
| @iglesiasg | good night! | 01:07 |
| -!- iglesiasg [~Fernando@s83-179-44-135.cust.tele2.se] has quit [Quit: Leaving] | 01:08 | |
| shogun-buildbot | build #1414 of deb3 - modular_interfaces is complete: Failure [failed test python_modular] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/1414 blamelist: Evgeniy Andreev <gsomix@gmail.com>, Soeren Sonnenburg <sonne@debian.org> | 01:15 |
| shogun-buildbot | build #1288 of deb2 - static_interfaces is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb2%20-%20static_interfaces/builds/1288 | 01:16 |
| -!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout] | 02:20 | |
| shogun-buildbot | build #414 of nightly_none is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/nightly_none/builds/414 | 03:11 |
| shogun-buildbot | build #471 of nightly_default is complete: Failure [failed test] Build details are at http://www.shogun-toolbox.org/buildbot/builders/nightly_default/builds/471 | 04:52 |
| -!- abinash [~abinash@1.38.21.237] has joined #shogun | 05:07 | |
| -!- abinash [~abinash@1.38.21.237] has quit [Quit: Leaving] | 05:18 | |
| -!- pickle27 [~Kevin@d67-193-243-174.home3.cgocable.net] has joined #shogun | 05:53 | |
| -!- nube [~rho@49.244.123.113] has quit [Ping timeout: 246 seconds] | 06:45 | |
| gsomix | good morning | 06:52 |
| -!- nube [~rho@49.244.127.129] has joined #shogun | 07:00 | |
| pickle27 | gsomix: hey! | 07:16 |
| -!- hushell [~hushell@c-24-21-169-136.hsd1.or.comcast.net] has joined #shogun | 07:19 | |
| -!- pickle27 [~Kevin@d67-193-243-174.home3.cgocable.net] has quit [Quit: Leaving] | 07:31 | |
| -!- foulwall` [~user@222.36.81.211] has joined #shogun | 07:40 | |
| -!- nube [~rho@49.244.127.129] has left #shogun [] | 07:42 | |
| -!- foulwall` [~user@222.36.81.211] has quit [Ping timeout: 240 seconds] | 08:36 | |
| -!- gsomix [~gsomix@95.67.178.31] has quit [Ping timeout: 240 seconds] | 08:49 | |
| -!- gsomix [~gsomix@85.26.234.67] has joined #shogun | 09:07 | |
| -!- foulwall` [~user@222.36.81.211] has joined #shogun | 09:11 | |
| -!- gsomix [~gsomix@85.26.234.67] has quit [Ping timeout: 264 seconds] | 09:14 | |
| -!- nube [~rho@49.244.127.129] has joined #shogun | 09:33 | |
| -!- gsomix [~gsomix@95.67.178.31] has joined #shogun | 09:40 | |
| -!- lambday [67157f37@gateway/web/freenode/ip.103.21.127.55] has joined #shogun | 10:20 | |
| lambday | sonney2k: moin moin :) | 10:20 |
| lambday | sonney2k: lisitsyn: how does our lapack support work? | 10:21 |
| lambday | I mean, is every routine in lapack available or just the ones that are defined in lapack.h? | 10:23 |
| lisitsyn | lambday: every but for some of them we have some wrappers | 10:31 |
| lisitsyn | lambday: I wanted to talk out that thing you have with your tridiagonalization | 10:31 |
| lisitsyn | I am afraid I don't get the exact problem | 10:31 |
| -!- lambday_ [67157d37@gateway/web/freenode/ip.103.21.125.55] has joined #shogun | 10:32 | |
| lambday_ | lisitsyn: sorry I got disconnected :( | 10:32 |
| lambday_ | lisitsyn: please tell me what you think | 10:33 |
| lambday_ | we need a tridiagonal eigen solver for implementing Lanczos | 10:33 |
| lambday_ | and as of now, I don't know if I can use that using eigen3 | 10:34 |
| -!- lambday [67157f37@gateway/web/freenode/ip.103.21.127.55] has quit [Ping timeout: 250 seconds] | 10:34 | |
| lambday_ | lisitsyn: we can use readymade Lanczos implementation from external libs (like, the one you showed me the other day) | 10:36 |
| lisitsyn | lambday_: the matrix you work on is sparse right? | 10:36 |
| lambday_ | lisitsyn: yes... I need that for Lanczos T-matrix | 10:36 |
| lambday_ | lisitsyn: so, this matrix will get huge if the iteration goes on for quite long | 10:37 |
| lambday_ | and using dense matrix won't be an efficient soln for that... | 10:38 |
| lisitsyn | okay I see | 10:38 |
| lambday_ | lisitsyn: so in krylstat, they used a tridiagonal eigen solver from alglib for that | 10:39 |
| lambday_ | while I was checking that, turns out that alglib has taken it from lapack | 10:39 |
| lambday_ | and since we have lapack support, I guess I can use that routine directly? | 10:40 |
| lisitsyn | lambday_: yes sure | 10:40 |
| lisitsyn | lambday_: are you talking about the step that works with tridiagonalized matrix? | 10:40 |
| lisitsyn | or tridiagonalization itself? | 10:40 |
| lisitsyn | there is a nice method implemented in lapack | 10:41 |
| lisitsyn | MRRR | 10:41 |
| lisitsyn | or MR3 | 10:41 |
| lambday_ | the step that works with a tridiagonal matrix (the diagonal and subdiagonals are formed from CG iteration)... its already tridiagonalized | 10:41 |
| lambday_ | what does this method do? | 10:41 |
| lisitsyn | lambday_: T -> eigenpairs | 10:42 |
| lambday_ | lisitsyn: then this is probably exactly what I need :D | 10:42 |
| lambday_ | lisitsyn: but I never worked with lapack :-/ | 10:42 |
| lisitsyn | ah nevermind I'll guide you here | 10:42 |
| lambday_ | lisitsyn: thanks man! :D | 10:43 |
| lambday_ | I'm checking the documentation for MR3 then | 10:43 |
| lisitsyn | lambday_: do you need all eigenpairs? | 10:43 |
| lisitsyn | or? | 10:43 |
| lambday_ | lisitsyn: we need only max/min eig values | 10:43 |
| lisitsyn | lambday_: just one maximal | 10:44 |
| lisitsyn | and just one minimal? | 10:44 |
| lambday_ | lisitsyn: yes | 10:44 |
| lisitsyn | http://www.netlib.org/clapack/CLAPACK-3.1.1/SRC/dstemr.c | 10:44 |
| lisitsyn | lambday_: you need DSTEMR | 10:44 |
| lisitsyn | lambday_: well or SSTEMR if you work with float | 10:45 |
| lisitsyn | lambday_: you'd need to call it twice then I think | 10:45 |
| lambday_ | lisitsyn: ah.. thanks.. | 10:45 |
| lambday_ | lisitsyn: twice? | 10:45 |
| lisitsyn | lambday_: well for max and min | 10:45 |
| lambday_ | lisitsyn: okay | 10:45 |
| lisitsyn | lambday_: in the first case you call it with | 10:45 |
| lisitsyn | [0,1) | 10:45 |
| lisitsyn | like compute 0th eigenpair | 10:46 |
| lisitsyn | and in the second you know | 10:46 |
| lisitsyn | other side | 10:46 |
| lambday_ | lisitsyn: alright... | 10:46 |
| lisitsyn | lambday_: will you call it more than once in your code? | 10:46 |
| lambday_ | lisitsyn: just once | 10:47 |
| lisitsyn | oh then lets not write a wrapper | 10:47 |
| lisitsyn | lambday_: http://www.netlib.org/clapack/CLAPACK-3.1.1/SRC/dstemr.c lets just go through all parameters | 10:47 |
| lisitsyn | I guess you need | 10:47 |
| lisitsyn | JOBZ = 'N' | 10:48 |
| lisitsyn | ? | 10:48 |
| lambday_ | yes | 10:48 |
| lisitsyn | RANGE = 'I' | 10:48 |
| lambday_ | yes | 10:48 |
| lisitsyn | N = size of your matrix | 10:48 |
| lambday_ | N will be equal to Lanczos iteration | 10:48 |
| lambday_ | yep | 10:48 |
| lisitsyn | D = that's diagonal of your T thing | 10:48 |
| lisitsyn | E = subdiagonal | 10:48 |
| lisitsyn | just pointers | 10:48 |
| lambday_ | alright | 10:49 |
| lisitsyn | VL = 0.0 | 10:49 |
| lisitsyn | VU = 0.0 | 10:49 |
| lisitsyn | IL = 1 | 10:49 |
| lisitsyn | IU = 2 | 10:49 |
| lambday_ | why VL and VU=0.0? | 10:49 |
| lisitsyn | lambday_: they are not used here | 10:49 |
| lisitsyn | lambday_: you may set bounds of eigenvalues you need | 10:49 |
| lambday_ | lisitsyn: okay | 10:49 |
| lisitsyn | that's a different mode | 10:50 |
| lambday_ | alright | 10:50 |
| lisitsyn | M - just create some integer before call and pass it by reference | 10:50 |
| lisitsyn | int M; | 10:50 |
| lisitsyn | f(&m) | 10:50 |
| lisitsyn | like that | 10:50 |
| lambday_ | alright | 10:50 |
| lisitsyn | Z = null | 10:51 |
| lisitsyn | LDZ = 1 | 10:51 |
| lambday_ | there is a W | 10:51 |
| lisitsyn | oops | 10:51 |
| lambday_ | which is of length one (since we'll call it once for max and once for min) | 10:51 |
| lambday_ | right? | 10:51 |
| foulwall` | ls | 10:52 |
| lisitsyn | lambday_: for W you'd have to allocate an array | 10:52 |
| lisitsyn | lambday_: no unfortunately it has to be of size N | 10:52 |
| lambday_ | lisitsyn: okay | 10:52 |
| lisitsyn | lambday_: but it shouldn't be a big deal | 10:52 |
| lisitsyn | lambday_: just allocate it once | 10:52 |
| lisitsyn | and use twice | 10:52 |
| lisitsyn | then delete | 10:52 |
| lisitsyn | okay | 10:52 |
| lambday_ | okay... alright | 10:52 |
| lisitsyn | NZC should not be referenced I think | 10:53 |
| lisitsyn | just set it to 1 | 10:53 |
| lisitsyn | ISUPPZ = null | 10:53 |
| lambday_ | okay | 10:53 |
| lisitsyn | TRYRAC - you could play with it | 10:53 |
| lisitsyn | try both false and true | 10:54 |
| lambday_ | lisitsyn: alright.. for accuracy stuffs | 10:54 |
| lambday_ | okay | 10:54 |
| lisitsyn | lambday_: argh I guess you'd still need to call it once to estimate worksizes | 10:54 |
| lambday_ | lisitsyn: once more? you mean thrice?? | 10:55 |
| lisitsyn | lambday_: yeah they use such interface | 10:55 |
| lisitsyn | when you call it once to estimate work sizes | 10:55 |
| lisitsyn | and then work with it | 10:55 |
| lambday_ | lisitsyn: alright | 10:55 |
| lisitsyn | lambday_: but you may try without yet | 10:55 |
| lisitsyn | okay lets pass through all the rest parameters | 10:56 |
| lambday_ | WORK | 10:56 |
| lisitsyn | lambday_: for WORK allocate some thing of size 12*N | 10:56 |
| lambday_ | why 12? | 10:56 |
| lisitsyn | LWORK >= max(1,12*N) if JOBZ = 'N' | 10:57 |
| lisitsyn | lambday_: magic :) | 10:57 |
| lambday_ | :D | 10:57 |
| lisitsyn | lambday_: they want it to be >= 12*N | 10:57 |
| lisitsyn | so WORK = some array of 12*N or 2*12*N | 10:57 |
| lisitsyn | LWORK = size of that array | 10:57 |
| lambday_ | okay | 10:57 |
| lisitsyn | IWORK = some INTEGER array of size 8*N or 8*2*N | 10:58 |
| lisitsyn | and LIWORK = size of that array | 10:58 |
| lambday_ | LIWORK size of that array | 10:58 |
| lambday_ | alright | 10:58 |
| lisitsyn | INFO = some integer variable passed by reference | 10:58 |
| lambday_ | info - reference? | 10:58 |
| lambday_ | yes | 10:58 |
| lambday_ | phew!!! | 10:58 |
| lambday_ | man!!! :( | 10:58 |
| lisitsyn | lambday_: that's okay DSYEVR has even more parameters | 10:59 |
| lambday_ | why so complicated :'( | 10:59 |
| lambday_ | lisitsyn: now I get why Heiko hates it :'( | 10:59 |
| lisitsyn | well there is a reason why they made it that way I think | 10:59 |
| lambday_ | must be | 11:00 |
| lisitsyn | lambday_: now the worst part of our adventure | 11:00 |
| * lambday_ holds his breath | 11:00 | |
| lisitsyn | lambday_: well I'd skip it for now | 11:00 |
| lisitsyn | lambday_: if user doesn't have ATLAS | 11:00 |
| lisitsyn | we'd have to write a simple C++ wrapper | 11:00 |
| lisitsyn | that just calls this function | 11:00 |
| lisitsyn | lambday_: but for now lets just #ifdef HAVE_ATLAS your part of code | 11:01 |
| lambday_ | lisitsyn: umm... okay, alright | 11:01 |
| lambday_ | lisitsyn: I am trying this thing out... in a small example code.. | 11:01 |
| lisitsyn | lambday_: with atlas | 11:02 |
| lisitsyn | your call would be | 11:02 |
| lisitsyn | clapack_dormtr(...) | 11:02 |
| lisitsyn | lambday_: with all these parameters | 11:02 |
| lambday_ | trying | 11:03 |
| lambday_ | lisitsyn: okay | 11:03 |
| lisitsyn | lambday_: ahh one more thing | 11:03 |
| lisitsyn | lambday_: put an assertion that info = 0 after the call | 11:03 |
| lambday_ | lisitsyn: okay.. success check | 11:04 |
| lisitsyn | and better output its value | 11:04 |
| lisitsyn | because if it failed it would be hard to understand anyway | 11:04 |
| lisitsyn | but without error value impossible at all :) | 11:04 |
| lisitsyn | lambday_: you're quite lucky you don't have to compute eigenvectors | 11:09 |
| lambday_ | lisitsyn: that would have been a nightmare I am guessing :-s | 11:10 |
| lisitsyn | lambday_: you'd need to call it once with all LWORK, LIWORK set to -1 | 11:10 |
| lisitsyn | on output they will say you how much memory you need | 11:11 |
| lisitsyn | however they are not going to be changed | 11:11 |
| lisitsyn | that thing will be stored in WORK and IWORK | 11:11 |
| lisitsyn | as integer | 11:11 |
| lisitsyn | WORK[0] to be precise | 11:11 |
| lisitsyn | and then you'd allocate your memory | 11:11 |
| lisitsyn | and then finally call it | 11:11 |
| -!- iglesiasg [~Fernando@s83-179-44-135.cust.tele2.se] has joined #shogun | 11:13 | |
| -!- mode/#shogun [+o iglesiasg] by ChanServ | 11:13 | |
| lambday_ | lisitsyn: allocate my memory for? | 11:13 |
| lisitsyn | lambday_: WORK, IWORK | 11:13 |
| lambday_ | lisitsyn: oh so its not 12*N or 8*N fixed... they will give me how much I need... and I'd do that... alright | 11:14 |
| lisitsyn | lambday_: yes that's implementation dependent I guess | 11:14 |
| lisitsyn | lambday_: 12N and 8N are minimal sizes | 11:14 |
| lambday_ | lisitsyn: alright | 11:14 |
| lisitsyn | lambday_: I'd try 12*N*2 too | 11:14 |
| lisitsyn | just to check performance | 11:14 |
| lambday_ | okay.. I'll check | 11:15 |
| lisitsyn | lambday_: that thing is scary indeed but when you think how much effort would be to write all these algorithms | 11:19 |
| lisitsyn | to test it and to check its accuracy | 11:19 |
| lisitsyn | efficiency whatever | 11:19 |
| lambday_ | lisitsyn: yeah.. | 11:20 |
| lambday_ | lisitsyn: in standard operations, which performs better? lapack or eigen3? | 11:20 |
| lisitsyn | lambday_: lapack is just an interface | 11:21 |
| lisitsyn | lambday_: but it is implemented in MKL | 11:21 |
| lambday_ | to blas? | 11:21 |
| lisitsyn | no | 11:21 |
| lisitsyn | blas is basic linear algebra | 11:21 |
| lisitsyn | lapack is something advanced | 11:21 |
| lisitsyn | like decompositions and solver | 11:21 |
| lisitsyn | s | 11:21 |
| lisitsyn | lambday_: MKL has the best performance on intel cpus | 11:22 |
| lambday_ | okay | 11:22 |
| lisitsyn | but that's predictable | 11:22 |
| lisitsyn | I mean MKL is made by intel | 11:22 |
| lisitsyn | they know how to work with intel processors :D | 11:22 |
| lambday_ | haha :D | 11:22 |
| lisitsyn | lambday_: good thing about eigen3 is that you can use MKL in it | 11:22 |
| lisitsyn | lambday_: anyway eigen3 is ok with multiplications and etc | 11:23 |
| lambday_ | that's awesome | 11:23 |
| lisitsyn | but it is pretty bad with SVD | 11:23 |
| lambday_ | lisitsyn: what about other decompositions? | 11:23 |
| lambday_ | QR etc | 11:23 |
| lisitsyn | lambday_: QR is ok iirc | 11:23 |
| lambday_ | alright | 11:23 |
| lisitsyn | lambday_: they don't have that fancy MRRR too | 11:24 |
| lambday_ | lisitsyn: yeah :( they should :( | 11:24 |
| lisitsyn | multiple relative robust representation | 11:24 |
| lisitsyn | lambday_: their development slowed down a bit it seems | 11:24 |
| lambday_ | err.. what it is for? (I was thinking about this tridiagonal solver) | 11:24 |
| lisitsyn | well that's what happens to mature software | 11:24 |
| lisitsyn | lambday_: yes it is that tridiag solver | 11:25 |
| lambday_ | eigen3 is used by many many projects right? | 11:25 |
| lambday_ | I saw somewhere that Google uses it too | 11:25 |
| lisitsyn | lambday_: yes in their nonlinear least squares solver | 11:25 |
| lisitsyn | forgot its name | 11:26 |
| lisitsyn | which is used for google maps and etc | 11:26 |
| lisitsyn | ceres | 11:26 |
| lambday_ | wow! | 11:26 |
| lambday_ | lisitsyn: one offbit question.. does modern gcc (say, 4.6) produces vectorized instructions already automatically/ | 11:27 |
| -!- foulwall` [~user@222.36.81.211] has quit [Remote host closed the connection] | 11:32 | |
| lambday_ | lisitsyn: did you mean clapack_dormtr or clapack_dstemr ? | 11:38 |
| lambday_ | lisitsyn: I checked with both and it says method doesn't exist.. I have clapach.h in /usr/include... compiling with "g++ lapack.cpp -lshogun -llapack".. am I missing something? | 11:43 |
| -!- gsomix_ [~gsomix@109.169.249.121] has joined #shogun | 11:50 | |
| lisitsyn | lambday_: dstemr indeed | 11:52 |
| -!- gsomix [~gsomix@95.67.178.31] has quit [Ping timeout: 240 seconds] | 11:52 | |
| lambday_ | lisitsyn: tried with " g++ lapack.cpp -lshogun -L/usr/lib64/atlas/liblapack.so" too | 11:52 |
| lisitsyn | lambday_: yes gcc uses SSE and stuff already | 11:52 |
| lisitsyn | lambday_: is there clapack_dstemr | 11:53 |
| lisitsyn | in clapack.h? | 11:53 |
| lambday_ | lisitsyn: nope :| | 11:53 |
| lisitsyn | uhh | 11:53 |
| lisitsyn | that's worse | 11:53 |
| lambday_ | what does this mean? | 11:54 |
| lambday_ | atlas didn't create code for this routine for this arch? | 11:54 |
| -!- dekun [7ae07e1e@gateway/web/freenode/ip.122.224.126.30] has joined #shogun | 11:58 | |
| lisitsyn | lambday_: okay I am back | 12:31 |
| lisitsyn | lets think about it | 12:31 |
| lambday_ | lisitsyn: wb :) I am manually installing a different version of clapack | 12:31 |
| lisitsyn | lambday_: oops! does it have that method? | 12:32 |
| lambday_ | lisitsyn: yep... its 3.1.1 | 12:32 |
| lambday_ | but not installed yet | 12:32 |
| lambday_ | make is tricky for this | 12:32 |
| lambday_ | argh! :( its horrible :( | 12:55 |
| lambday_ | lisitsyn: finally able to compile BUT | 13:13 |
| lambday_ | lisitsyn: this version uses liblapacke.a | 13:14 |
| lambday_ | lisitsyn: the method is LAPACKE_dstemr(..) | 13:14 |
| lambday_ | its 3.4 | 13:14 |
| lisitsyn | lambday_: well just make it work locally | 13:14 |
| lisitsyn | later we will check | 13:14 |
| lambday_ | lisitsyn: alright | 13:14 |
| lambday_ | I can't use shogun's lapack with it as of now | 13:14 |
| -!- votjakovr [~votjakovr@host-46-241-3-209.bbcustomer.zsttk.net] has joined #shogun | 13:15 | |
| lambday_ | lisitsyn: I'll be back soon.. pretty hungry :( | 13:15 |
| lisitsyn | alright | 13:15 |
| @sonney2k | gsomix_, so on a coding spre now? | 13:16 |
| @sonney2k | iglesiasg, did you figure out anything about the build failure? | 13:16 |
| gsomix_ | sonney2k, yep. recently started. | 13:18 |
| @iglesiasg | sonney2k: do you mean the python example? | 13:18 |
| @iglesiasg | sonney2k: AFAIK the build works fine | 13:18 |
| gsomix_ | sonney2k, how is weather? heat? | 13:18 |
| @sonney2k | iglesiasg, nope http://shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/1414/steps/test%20python_modular/logs/stdio | 13:19 |
| @iglesiasg | sonney2k: all right, we are talking about the same. I worked on it yesterday night a while, but didn't manage to solve it yet | 13:20 |
| @iglesiasg | sonney2k: But now I am working on LMNN, I have to make some progress with it. I will work again on that ASAP | 13:21 |
| -!- shogun-notifier- [~irker@7nn.de] has joined #shogun | 13:22 | |
| shogun-notifier- | shogun: Soeren Sonnenburg :develop * 3c5a95b / src/shogun/structure/FactorGraph.cpp: https://github.com/shogun-toolbox/shogun/commit/3c5a95b1da818cef0a47bc456e69bb255e26345f | 13:22 |
| shogun-notifier- | shogun: move ifdef to appropriate place | 13:22 |
| @sonney2k | gsomix_, yes hot but water is 12 C | 13:22 |
| @sonney2k | wind is just changing so I guess it will be 20 C in the evening | 13:23 |
| shogun-notifier- | shogun-data: foulwall :master * 9f3e8b7 / ocr/ocr.svm.gz: https://github.com/shogun-toolbox/shogun-data/commit/9f3e8b7217e46711e12aa9d72e0bf67807bd2afd | 13:23 |
| shogun-notifier- | shogun-data: add the ocr.svm.gz to data/ocr | 13:23 |
| shogun-notifier- | shogun-data: Soeren Sonnenburg :master * 0d0c9d6 / ocr/ocr.svm.gz: https://github.com/shogun-toolbox/shogun-data/commit/0d0c9d67195a18ad2bb9424e5dc49b16fb9c3a39 | 13:23 |
| shogun-notifier- | shogun-data: Merge pull request #9 from ZhengyangL/master | 13:23 |
| shogun-notifier- | shogun-data: | 13:23 |
| shogun-notifier- | shogun-data: add the ocr.svm.gz to data/ocr | 13:23 |
| shogun-notifier- | shogun-demo: foulwall :master * 20cd8b9 / / (12 files): https://github.com/shogun-toolbox/shogun-demo/commit/20cd8b9a0940b2a68dbfb5375c0906b74a8d0136 | 13:24 |
| shogun-notifier- | shogun-demo: perfect ocr | 13:24 |
| shogun-notifier- | shogun-demo: foulwall :master * 58b475a / / (9 files): https://github.com/shogun-toolbox/shogun-demo/commit/58b475a87a575a70c2ac1c806fda012be96865a6 | 13:24 |
| shogun-notifier- | shogun-demo: 1. fixed the preview redrawing bug. 2. fixed the circle turn-white bug. 3. add shogun-data submodule back. 4. put ocr.svm.gz into local/ | 13:24 |
| shogun-notifier- | shogun-demo: Soeren Sonnenburg :master * 08afcfc / / (16 files): https://github.com/shogun-toolbox/shogun-demo/commit/08afcfc810f9c2bdec6f1e8c32a7155fafee8b7c | 13:24 |
| shogun-notifier- | shogun-demo: Merge pull request #16 from ZhengyangL/ocr | 13:24 |
| shogun-notifier- | shogun-demo: | 13:24 |
| shogun-notifier- | shogun-demo: perfect ocr | 13:24 |
| @sonney2k | gsomix_, please also shorten the constructor | 13:25 |
| gsomix_ | sonney2k, yes, I remember. | 13:25 |
| @sonney2k | shogun-buildbot, force build nightly_none | 13:27 |
| shogun-buildbot | build forced [ETA 23m31s] | 13:27 |
| shogun-buildbot | I'll give a shout when the build finishes | 13:27 |
| shogun-notifier- | shogun-data: Soeren Sonnenburg :master * 77d078c / ocr/ocr.svm.gz,ocr/train_data_x.asc.gz,ocr/train_data_y.asc.gz: https://github.com/shogun-toolbox/shogun-data/commit/77d078cf617f3e3fb128c4b7e27761de104954d3 | 13:34 |
| shogun-notifier- | shogun-data: put all ocr data into the ocr dir | 13:34 |
| shogun-notifier- | shogun: Soeren Sonnenburg :develop * ce0aca3 / data/ (5 files): https://github.com/shogun-toolbox/shogun/commit/ce0aca3de8042c8582648b1f9931d03ee1678eaf | 13:37 |
| shogun-notifier- | shogun: move all ocr data into data/ocr | 13:37 |
| @sonney2k | gsomix_, I would like to convert the examples we have to use your csvfile so it would be good to have the stable api | 13:41 |
| lambday_ | lisitsyn: back | 13:41 |
| lambday_ | lisitsyn: apparently it computes perfectly | 13:41 |
| lisitsyn | lambday_: so everything is correctly computed? | 13:42 |
| lisitsyn | you mean eigenvalues? | 13:42 |
| lambday_ | lisitsyn: just checked with a diagonal matrix.. it gives perfect result | 13:42 |
| @sonney2k | gsomix_, so basically I want to get rid of tools/load.py in the python_modular examples | 13:42 |
| lambday_ | lisitsyn: now checking with a true tridiag one | 13:42 |
| @sonney2k | some way to go still | 13:43 |
| lambday_ | lisitsyn: cross checked with octave - perfect! | 13:45 |
| gsomix_ | sonney2k, aha, got it. | 13:45 |
| lisitsyn | lambday_: gut | 13:45 |
| lambday_ | lisitsyn: Germen for good? :D | 13:45 |
| lisitsyn | lambday_: ja | 13:45 |
| lambday_ | ya for spanish :D | 13:45 |
| gsomix_ | sonney2k, now I'm working on quoting and set/get_string_list methods | 13:46 |
| lambday_ | lisitsyn: so, I am working with #include <lapacke.h> (from lapack-3.4.2/lapacke/include), with static lib lapacke.a) | 13:47 |
| shogun-buildbot | build #1097 of cyg1 - libshogun is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/1097 blamelist: Soeren Sonnenburg <sonne@debian.org> | 13:47 |
| lambday_ | lisitsyn: now how can I make it work with shogun's lapack wrapper? | 13:48 |
| lambday_ | lisitsyn: apparently including this lapacke.h and shogun/mathematics/lapack.h in a single file gives error (they made quite a few changes, params shuffled/dropped etc) | 13:48 |
| lisitsyn | lambday_: check shogun/mathematics/lapack.cpp | 13:49 |
| lambday_ | lisitsyn: for example, this new one don't have WORK thing | 13:49 |
| lisitsyn | lambday_: first add these defines | 13:49 |
| lambday_ | lisitsyn: checking' | 13:49 |
| -!- travis-ci [~travis-ci@ec2-54-234-72-29.compute-1.amazonaws.com] has joined #shogun | 13:49 | |
| travis-ci | [travis-ci] it's Soeren Sonnenburg's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: http://travis-ci.org/shogun-toolbox/shogun/builds/9573316 | 13:49 |
| -!- travis-ci [~travis-ci@ec2-54-234-72-29.compute-1.amazonaws.com] has left #shogun [] | 13:49 | |
| lisitsyn | lambday_: next | 13:49 |
| lisitsyn | lambday_: in .h | 13:49 |
| lisitsyn | add clapack_dstemr | 13:50 |
| lisitsyn | or how is it called? | 13:50 |
| lambday_ | lisitsyn: but the problem is, in mathematics/lapack.h it includes lapack.h, I need lapacke.h, can't include these two together | 13:51 |
| lisitsyn | lambday_: nahh nevermind for now | 13:51 |
| lambday_ | lisitsyn: so, new ifdef required? | 13:51 |
| lisitsyn | no | 13:51 |
| lisitsyn | lambday_: hmmmm I think we can do it simpler | 13:52 |
| lambday_ | lisitsyn: how? | 13:52 |
| lisitsyn | lambday_: shogun/mathematics/lapack.h:101 | 13:52 |
| lisitsyn | lambday_: just add dstemr_(...) here | 13:53 |
| lambday_ | lisitsyn: alright | 13:53 |
| lambday_ | lisitsyn: and then what will I do in the cpp? | 13:53 |
| lisitsyn | lambday_: well you may call dstemr_ directly | 13:54 |
| lambday_ | lisitsyn: but that's defined in my clapack.h | 13:54 |
| lisitsyn | lambday_: ohh then try to call it | 13:55 |
| lambday_ | lisitsyn: okay I'm trying.. | 13:55 |
| lisitsyn | I would avoid writing a wrapper here | 13:56 |
| -!- travis-ci [~travis-ci@ec2-54-234-72-29.compute-1.amazonaws.com] has joined #shogun | 14:08 | |
| travis-ci | [travis-ci] it's Soeren Sonnenburg's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: http://travis-ci.org/shogun-toolbox/shogun/builds/9573492 | 14:08 |
| -!- travis-ci [~travis-ci@ec2-54-234-72-29.compute-1.amazonaws.com] has left #shogun [] | 14:08 | |
| lambday_ | lisitsyn: I get a few undefined ref from libshogun, like "/usr/local/lib/libshogun.so: undefined reference to `clapack_dgetrf'", clapack_dgetri, etc.. | 14:17 |
| lambday_ | lisitsyn: when I just add the function declaration in mathematics/lapack.h | 14:18 |
| lisitsyn | lambday_: looks strange for me | 14:20 |
| lisitsyn | is it with atlas or? | 14:20 |
| lambday_ | lisitsyn: there are in lapack.h already! | 14:20 |
| lisitsyn | well but that's undefined reference | 14:20 |
| lisitsyn | so no implementation | 14:20 |
| shogun-buildbot | build #1415 of deb3 - modular_interfaces is complete: Failure [failed test python_modular] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/1415 blamelist: Soeren Sonnenburg <sonne@debian.org> | 14:24 |
| lambday_ | lisitsyn: weird! they are there in clapack.h (for atlas is present).. and implemented in lapack.cpp too | 14:26 |
| lambday_ | oh I see | 14:27 |
| lambday_ | lisitsyn: yippie! | 14:27 |
| lambday_ | :D | 14:27 |
| lisitsyn | lambday_: solved? | 14:27 |
| lambday_ | lisitsyn: yep | 14:27 |
| lambday_ | I was using -llapack so it was using /usr/lib64/lapack.so, not /usr/lib64/atlas/lapack.so | 14:28 |
| lambday_ | phew! | 14:28 |
| lisitsyn | ahh I see | 14:28 |
| lambday_ | so, I am adding this | 14:28 |
| lambday_ | but creating every variable and passing a pointer is surely a pain' | 14:29 |
| lambday_ | :( | 14:29 |
| lisitsyn | lambday_: what do you mean? | 14:30 |
| lambday_ | lisitsyn: all 21 vars should be passed as pointers | 14:30 |
| lambday_ | params I mean | 14:30 |
| lisitsyn | ohhh | 14:30 |
| lisitsyn | haha I see | 14:30 |
| lisitsyn | lambday_: what do you think about adding a wrapper then? | 14:30 |
| lambday_ | lisitsyn: might be better idea | 14:31 |
| lisitsyn | lambday_: like wrap_dsyevr | 14:31 |
| lambday_ | lisitsyn: although I will be using it at one place only but may be it comes handy later? | 14:31 |
| lisitsyn | lambday_: well it would simplify your code anyway | 14:31 |
| lambday_ | lisitsyn: yep | 14:31 |
| lambday_ | I wanna get rid of these working vectors | 14:31 |
| lambday_ | allocate 12*2 and 8*2 by default :D | 14:32 |
| shogun-buildbot | build #1098 of cyg1 - libshogun is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/1098 blamelist: Soeren Sonnenburg <sonne@debian.org> | 14:34 |
| shogun-buildbot | build #415 of nightly_none is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/nightly_none/builds/415 | 14:35 |
| lambday_ | lisitsyn: why would you wanted to avoid writing a wrapper? | 14:36 |
| lisitsyn | lambday_: just to simplify things | 14:36 |
| lisitsyn | but it doesn't simplify things you see | 14:36 |
| lambday_ | lisitsyn: alright... so I am adding a wrapper :) | 14:37 |
| wiking_ | yo :) | 14:45 |
| -!- wiking_ is now known as wiking | 14:45 | |
| -!- wiking [~wiking@info2k1.hu] has quit [Changing host] | 14:46 | |
| -!- wiking [~wiking@huwico/staff/wiking] has joined #shogun | 14:46 | |
| -!- mode/#shogun [+o wiking] by ChanServ | 14:46 | |
| shogun-buildbot | build #1416 of deb3 - modular_interfaces is complete: Failure [failed test python_modular] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/1416 blamelist: Soeren Sonnenburg <sonne@debian.org> | 15:05 |
| gsomix_ | wiking, hey ho | 15:12 |
| -!- gsomix_ is now known as gsomix | 15:12 | |
| @sonney2k | gsomix, what does hey ho mean? | 15:12 |
| @iglesiasg | see you later people | 15:17 |
| @iglesiasg | lunch time! | 15:17 |
| gsomix | sonney2k, hm... I think just inspiring exclamation | 15:17 |
| -!- iglesiasg [~Fernando@s83-179-44-135.cust.tele2.se] has quit [Quit: Leaving] | 15:17 | |
| @sonney2k | shogun-buildbot, force build nightly_none --branch=develop | 15:20 |
| shogun-buildbot | build forced [ETA 23m31s] | 15:20 |
| shogun-buildbot | I'll give a shout when the build finishes | 15:20 |
| gsomix | sonney2k, something wrong wit "hey ho"? :) | 15:24 |
| gsomix | *with | 15:24 |
| @sonney2k | gsomix, I am just wondering if that is a good sign :) | 15:25 |
| @sonney2k | lisitsyn, apparently strdup is not part of the standard and we have a compile error with cyg | 15:29 |
| lisitsyn | sonney2k: strdup is not std? | 15:30 |
| lisitsyn | that's weird | 15:30 |
| lisitsyn | :D | 15:30 |
| @sonney2k | lisitsyn, http://stackoverflow.com/questions/5573775/strdup-error-on-g-with-c0x | 15:31 |
| @sonney2k | it is now happening with our std=c++11 | 15:31 |
| lisitsyn | sonney2k: what to use instead? memcpy? | 15:31 |
| @sonney2k | lisitsyn, I don't understand why it doesn't work it says in the bottom of the manpage | 15:32 |
| @sonney2k | http://linux.die.net/man/3/strdup | 15:32 |
| @sonney2k | strdup() conforms to SVr4, 4.3BSD, POSIX.1-2001 | 15:32 |
| @sonney2k | so wtf? | 15:32 |
| shogun-buildbot | build #416 of nightly_none is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/nightly_none/builds/416 | 15:40 |
| @sonney2k | lisitsyn, I mean OK it is not ansi C but cygwin == posix so including string should give it to us or is this std=c+11 overriding this? | 15:40 |
| lisitsyn | sonney2k: I haven't heard about it so no clue | 15:40 |
| @sonney2k | I guess that is the only explanation | 15:41 |
| @sonney2k | lisitsyn, so what do we do? add some sg_strdup somewhere (where??) | 15:41 |
| gsomix | sonney2k, just replace by strcpy? | 15:47 |
| gsomix | sonney2k, btw now we use SGVector<char> as strings. but there is no null-terminate chars at end. it can cause errors in parse functions like atoi/strtol, isn't it? | 15:57 |
| -!- dekun [7ae07e1e@gateway/web/freenode/ip.122.224.126.30] has quit [Quit: Page closed] | 16:00 | |
| lambday_ | lisitsyn: could you please have a look at the PR | 16:13 |
| lambday_ | lisitsyn: few doxygen things fixed (did it earlier) | 16:14 |
| lambday_ | lisitsyn: and added a unit-test that checks this lapack routine's accuracy with eigen3 (considering the matrix as a dense one) | 16:14 |
| lisitsyn | lambday_: looks cool | 16:25 |
| lambday_ | lisitsyn: thanks to you :) | 16:25 |
| -!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout] | 16:37 | |
| -!- pickle27 [~Kevin@d67-193-243-174.home3.cgocable.net] has joined #shogun | 16:40 | |
| lambday_ | lisitsyn: gotta go | 16:42 |
| lambday_ | ciao guys | 16:42 |
| -!- lambday_ [67157d37@gateway/web/freenode/ip.103.21.125.55] has quit [] | 16:42 | |
| pickle27 | sonney2k: lisitsyn around? | 16:43 |
| -!- iglesiasg [~Fernando@s83-179-44-135.cust.tele2.se] has joined #shogun | 17:10 | |
| -!- mode/#shogun [+o iglesiasg] by ChanServ | 17:10 | |
| pickle27 | sonney2k: I'll be back on later but I wanted to update on my progress with r_modular | 17:21 |
| pickle27 | sonney2k: it now builds but I had some issues with the install script | 17:22 |
| pickle27 | I had to change lin 152 in .r-install.sh to remove the file ext from f before writing it | 17:23 |
| pickle27 | otherwise it would look for shogun.so.so as it isn't expecting the ext | 17:23 |
| pickle27 | I also think the the last arg is missing in the makefile as saverds is passed when calling the scipt for the staic interface but not for the modular one | 17:23 |
| pickle27 | anyways after all these changes i get the following message when running library(shogun) in R | 17:24 |
| pickle27 | Welcome! This is SHOGUN version 2.2.0 | 17:24 |
| pickle27 | Error in namespaceExport(ns, exports) : undefined exports: shogun | 17:24 |
| pickle27 | Error: package/namespace load failed for ‘shogun’ | 17:24 |
| @wiking | let's fix cmake ;) | 18:00 |
| -!- hushell [~hushell@c-24-21-169-136.hsd1.or.comcast.net] has quit [Read error: Connection reset by peer] | 18:54 | |
| -!- hushell [~hushell@c-24-21-169-136.hsd1.or.comcast.net] has joined #shogun | 19:08 | |
| lisitsyn | wiking: ooh so you are back | 19:13 |
| lisitsyn | ? | 19:13 |
| -!- shogun-notifier- [~irker@7nn.de] has joined #shogun | 19:18 | |
| shogun-notifier- | shogun: Fernando Iglesias :develop * ce25859 / / (4 files): https://github.com/shogun-toolbox/shogun/commit/ce258590b70a01eac28553d410a4df26188bb1db | 19:18 |
| shogun-notifier- | shogun: Faster computation of LMNN objective | 19:18 |
| shogun-notifier- | shogun: Update LMNN solution in unit tests | 19:18 |
| shogun-notifier- | shogun: Fernando Iglesias :develop * cb21763 / / (4 files): https://github.com/shogun-toolbox/shogun/commit/cb21763fd15d0ebd992c3821b1fd60819a8a251d | 19:18 |
| shogun-notifier- | shogun: Merge pull request #1322 from iglesias/feature/lmnn | 19:18 |
| shogun-notifier- | shogun: | 19:18 |
| shogun-notifier- | shogun: Faster computation of LMNN objective | 19:18 |
| shogun-buildbot | build #1099 of cyg1 - libshogun is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/1099 blamelist: Fernando Iglesias <fernando.iglesiasg@gmail.com> | 19:31 |
| @wiking | lisitsyn: yeah | 19:31 |
| votjakovr | gsomix: hi! i seems like CSVFile_unittest.cc has memory leaks (when i've run valgrind on unit tests, it reported that to me) | 19:43 |
| gsomix | votjakovr, yeah, really, thanks. | 19:49 |
| votjakovr | gsomix: You are welcome ;) | 19:51 |
| gsomix | not memory leak - just invalid read. I think it because of I don't have zero-terminate char at end of strings :( | 19:51 |
| gsomix | ok, I'll fix it | 19:53 |
| votjakovr | gsomix: good :) | 19:56 |
| shogun-buildbot | build #1417 of deb3 - modular_interfaces is complete: Failure [failed test python_modular] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/1417 blamelist: Fernando Iglesias <fernando.iglesiasg@gmail.com> | 20:02 |
| -!- nube [~rho@49.244.127.129] has quit [Quit: Leaving.] | 20:10 | |
| shogun-buildbot | build #1100 of cyg1 - libshogun is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/1100 blamelist: Fernando Iglesias <fernando.iglesiasg@gmail.com> | 20:13 |
| -!- iglesiasg [~Fernando@s83-179-44-135.cust.tele2.se] has quit [Quit: Leaving] | 20:41 | |
| @sonney2k | gsomix, what I did with strings is add a '\0' to the end of the string | 21:18 |
| gsomix | sonney2k, already fixed | 21:19 |
| gsomix | sonney2k, just added read_cstring method for reading zero-terminated strings | 21:20 |
| shogun-notifier- | shogun: lambday :develop * 7456300 / src/shogun/ (8 files): https://github.com/shogun-toolbox/shogun/commit/74563008f0aab20f98cefc4158da3e0b320415ee | 21:20 |
| shogun-notifier- | shogun: few doxygen warning fixed in log-det | 21:20 |
| shogun-notifier- | shogun: lambday :develop * 914b611 / / (3 files): https://github.com/shogun-toolbox/shogun/commit/914b611bb5773020a0d9c9c7613b6987817400be | 21:20 |
| shogun-notifier- | shogun: tridiagonal eigensolver lapack routine wrapper added | 21:20 |
| shogun-notifier- | shogun: Soeren Sonnenburg :develop * 6076c05 / / (11 files): https://github.com/shogun-toolbox/shogun/commit/6076c05d0e59bce65597cebc1f95fa78d1bdd858 | 21:20 |
| shogun-notifier- | shogun: Merge pull request #1321 from lambday/feature/log_determinant | 21:20 |
| shogun-notifier- | shogun: | 21:20 |
| shogun-notifier- | shogun: lapack wrapper for tridiagonal eigensolver added | 21:20 |
| gsomix | sonney2k, need check unit-tests by valgrind - then send PR for fixing than "invalid read" error. | 21:20 |
| shogun-buildbot | build #1101 of cyg1 - libshogun is complete: Failure [failed configure] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/1101 blamelist: lambday <heavensdevil6909@gmail.com> | 21:24 |
| shogun-buildbot | build #1102 of cyg1 - libshogun is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/1102 blamelist: lambday <heavensdevil6909@gmail.com>, Soeren Sonnenburg <sonne@debian.org> | 21:36 |
| @sonney2k | pickle27, pong! | 21:40 |
| pickle27 | sonney2k: hey! | 21:40 |
| -!- travis-ci [~travis-ci@ec2-54-234-72-29.compute-1.amazonaws.com] has joined #shogun | 21:41 | |
| travis-ci | [travis-ci] it's Fernando Iglesias's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: http://travis-ci.org/shogun-toolbox/shogun/builds/9579815 | 21:41 |
| -!- travis-ci [~travis-ci@ec2-54-234-72-29.compute-1.amazonaws.com] has left #shogun [] | 21:41 | |
| @sonney2k | pickle27, we have 2 things here the r-static interface and the modular one | 21:42 |
| @sonney2k | pickle27, what did you have to change to get any of these working | 21:43 |
| @sonney2k | pickle27, IIRC r-static is working just fine - at least the tests on the buildbot do | 21:43 |
| pickle27 | sonney2k: yes I didn't change anything for r_static | 21:43 |
| pickle27 | I simply looked at how it was because it was working and then tried to replicate for r_modular | 21:44 |
| @sonney2k | pickle27, ok so what are the issues you found for r-modular again? | 21:45 |
| * sonney2k compiles for r-moduar | 21:45 | |
| pickle27 | sonney2k: okay first issue was for r_modular the makefile passes less args to the install script compared to r_static | 21:46 |
| pickle27 | the last arg $SAVERDS is not passed for r_modular | 21:46 |
| @sonney2k | pickle27, ok I fixed that | 21:46 |
| @sonney2k | pickle27, the other? | 21:46 |
| pickle27 | I don't know fully what this affects | 21:46 |
| @sonney2k | pickle27, it is for creating the compiled Rdata file | 21:47 |
| pickle27 | second is that for the library.dynam.load line | 21:47 |
| pickle27 | we need to pass ${f%%.*} to stip the file ext rather than simply $f | 21:47 |
| pickle27 | otherwise it looks for modshogun.so.so and can't find it | 21:47 |
| pickle27 | sonney2k: however after that I had an import error from R so | 21:48 |
| pickle27 | something is still wrong | 21:48 |
| @sonney2k | pickle27, but library(sg) works? | 21:50 |
| pickle27 | sonney2k: yes | 21:50 |
| @sonney2k | pickle27, which R version do you have btw? | 21:52 |
| pickle27 | sonney2k: 2.15 | 21:52 |
| @sonney2k | > library(shogun) | 21:52 |
| @sonney2k | Error in if (!res) stop(gettextf("This is R %s, package %s needs %s %s", : | 21:52 |
| @sonney2k | missing value where TRUE/FALSE needed | 21:52 |
| @sonney2k | this is how it fails here btw | 21:52 |
| pickle27 | sonney2k: hmm I've never had that one on my machine | 21:53 |
| @sonney2k | pickle27, 2.15.1 | 21:54 |
| pickle27 | sonney2k: yeah I just opened mine I'm 2.15.2 | 21:54 |
| -!- travis-ci [~travis-ci@ec2-54-234-72-29.compute-1.amazonaws.com] has joined #shogun | 22:09 | |
| travis-ci | [travis-ci] it's Soeren Sonnenburg's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: http://travis-ci.org/shogun-toolbox/shogun/builds/9582062 | 22:09 |
| -!- travis-ci [~travis-ci@ec2-54-234-72-29.compute-1.amazonaws.com] has left #shogun [] | 22:09 | |
| shogun-buildbot | build #1419 of deb3 - modular_interfaces is complete: Failure [failed test python_modular] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/1419 blamelist: lambday <heavensdevil6909@gmail.com>, Soeren Sonnenburg <sonne@debian.org> | 22:17 |
| pickle27 | sonney2k: first it seems to me that the makefile in each interface folder is the same, is this so? | 22:25 |
| pickle27 | and why is it so? | 22:25 |
| lisitsyn | pickle27: yeah that's true | 22:26 |
| pickle27 | lisitsyn: why isn't it just the makefile for that modular lib | 22:27 |
| lisitsyn | can't explain | 22:27 |
| lisitsyn | :D | 22:27 |
| pickle27 | so if one of them needs to be changed then they all do? | 22:27 |
| lisitsyn | pickle27: they are built from Makefile.template | 22:27 |
| pickle27 | oh so they get built | 22:28 |
| pickle27 | okay thats different then | 22:28 |
| lisitsyn | no I mean Makefiles are distributed to each folder | 22:28 |
| pickle27 | okay built wasn't a good word on my part | 22:28 |
| pickle27 | they get generated is that correct? | 22:28 |
| lisitsyn | on my part as well | 22:28 |
| lisitsyn | :D | 22:28 |
| lisitsyn | pickle27: yes better word | 22:28 |
| pickle27 | okay cool | 22:29 |
| pickle27 | lisitsyn: I'm looking into changing our ruby modular to use nmatrix rather than narray | 22:29 |
| lisitsyn | pickle27: no clue about that | 22:30 |
| lisitsyn | what's pro/cons? | 22:30 |
| pickle27 | lisitsyn: nmatrix is bascially just the new narray | 22:31 |
| pickle27 | lisitsyn: its like a fork but doesn't look like anyone is working on narray anymore | 22:31 |
| lisitsyn | I see | 22:31 |
| pickle27 | and there is the whole sciruby group behind nmatrix | 22:31 |
| gsomix | pickle27, sciruby? good idea I think | 22:40 |
| pickle27 | gsomix: yes | 22:40 |
| pickle27 | gsomix: I'm actually working on it right now - seems not too bad because nmatrix is based on narray so the api is bascially the same | 22:41 |
| gsomix | pickle27, I can help a little if it's needed. | 22:41 |
| -!- iglesiasg [~Fernando@s83-179-44-135.cust.tele2.se] has joined #shogun | 22:41 | |
| -!- mode/#shogun [+o iglesiasg] by ChanServ | 22:41 | |
| pickle27 | gsomix: okay awesome I'll see how far I get here | 22:41 |
| gsomix | sonney2k, iglesiasg hey guys I sent small PR, review is needed. https://github.com/shogun-toolbox/shogun/pull/1323 | 22:47 |
| gsomix | votjakovr, done with invalid read | 22:47 |
| votjakovr | gsomix: thanks :) | 22:48 |
| @iglesiasg | sonney2k: let's see if sonney2k can have a look soon since he is the one revising your stuff | 22:51 |
| @iglesiasg | gsomix: ^ that was for you, sorry :) | 22:51 |
| @iglesiasg | otherwise I will have a look soon | 22:51 |
| gsomix | iglesiasg, ok, thanks | 22:51 |
| @sonney2k | gsomix, only comment I have is maybe use an enum for the order FORTRAN_ORDER / C_ORDER | 23:05 |
| gsomix | sonney2k, ok! | 23:07 |
| gsomix | sonney2k, I'll do it tomorrow, ok? | 23:08 |
| @sonney2k | gsomix, sure | 23:08 |
| gsomix | need to sleep a little | 23:08 |
| gsomix | good night guys | 23:08 |
| @sonney2k | gsomix, so you would have a setter | 23:08 |
| @sonney2k | like set_matrix_order(enum ...) | 23:08 |
| @sonney2k | with fortran as default | 23:08 |
| gsomix | sonney2k, aha, got it | 23:08 |
| @sonney2k | lisitsyn, do you remember why we named the modular interfaces for shogun modshogun? | 23:09 |
| @sonney2k | and not shogun? | 23:10 |
| lisitsyn | sonney2k: some name clash | 23:10 |
| @sonney2k | lisitsyn, then we should do it consistently across r/java/... | 23:11 |
| lisitsyn | sonney2k: what is the name in java? | 23:11 |
| @sonney2k | pickle27, then just add support for that in interfaces/ruby/swig_typemaps.i | 23:12 |
| pickle27 | sonney2k: yeah Im looking around at that right now | 23:12 |
| pickle27 | although I actually can | 23:12 |
| pickle27 | oops | 23:12 |
| pickle27 | can't seem to get nmatrix (the new ruby linalg) to even install at the moment | 23:13 |
| @sonney2k | lisitsyn, shogun.jar ... | 23:13 |
| pickle27 | so might be a bit premature but in a few months I think it will deffs be the right call | 23:13 |
| pickle27 | I'll see what I can do now though | 23:13 |
| pickle27 | sonney2k: also are we going to c++11? saw some talk about it but wasn;t paying attention | 23:16 |
| pickle27 | can I start using c11 stuff in shogun now? | 23:17 |
| @sonney2k | pickle27, only optionally and we would need to add a configure test for each function you use | 23:18 |
| pickle27 | sonney2k: okay i will avoid for now then | 23:18 |
| @iglesiasg | pickle27: I am with you in the go idea :) | 23:21 |
| @iglesiasg | sonney2k: is it crazy to even consider a new interface? | 23:21 |
| @iglesiasg | brb | 23:22 |
| @sonney2k | iglesiasg, which language? | 23:27 |
| pickle27 | sonney2k: we were think of Go | 23:27 |
| @sonney2k | pickle27, one more interfaces doesn't make a big difference | 23:29 |
| @sonney2k | pickle27, if swig is supporting it well all that is needed are typemaps | 23:29 |
| pickle27 | sonney2k: swig does support it | 23:29 |
| @sonney2k | pickle27, 'well'? | 23:29 |
| @sonney2k | or like R? | 23:29 |
| pickle27 | sonney2k: haha unsure.. | 23:29 |
| @sonney2k | if well it is IMHO very easy to add a new language | 23:30 |
| pickle27 | sonney2k: my gut tells me better than R because Go is a "cleaner" language than R | 23:30 |
| @sonney2k | just a few days work if one is not familiar with GO's C interfacing | 23:30 |
| @sonney2k | pickle27, there is no language that is messier than R IMHO | 23:30 |
| pickle27 | sonney2k: yeah I'm not a big fan of what I've seen so far | 23:31 |
| pickle27 | the only neat thing is how easy it is to call c from R | 23:31 |
| pickle27 | otherwise not a fan | 23:31 |
| pickle27 | NumPy is king of high level numerical programming in my mind | 23:32 |
| pickle27 | and I've actually grown quite fond of eigen3 | 23:32 |
| lisitsyn | you want one more interface? | 23:32 |
| lisitsyn | :D | 23:32 |
| pickle27 | bit of full disclosure the company Im working for next year is ruby and Go so I'm trying to learn the langquages a bit and I want shogun at my disposal lol | 23:33 |
| lisitsyn | pickle27: I am curious how do they use Go | 23:34 |
| pickle27 | lisitsyn: don't know much about how they use it really | 23:34 |
| pickle27 | lisitsyn: for web severs etc I think | 23:34 |
| pickle27 | maybe some of their db stuff | 23:34 |
| lisitsyn | pickle27: I guess something with lightweight threads | 23:34 |
| lisitsyn | well there are now | 23:35 |
| lisitsyn | erlang | 23:35 |
| lisitsyn | java with akka | 23:35 |
| lisitsyn | and go | 23:35 |
| lisitsyn | I don't know anything else with mature concurrency stuff | 23:35 |
| pickle27 | I haven't done a ton of threading stuff but I've kind of gathered that the way go does concurency is why a lot of people are moving to it | 23:36 |
| lisitsyn | I do some concurrency at my job | 23:37 |
| lisitsyn | basically a lot of trees with message passing | 23:37 |
| lisitsyn | in our tasks everything is interdependent and it is basically brute force :D | 23:38 |
| lisitsyn | but with message passing so it scales | 23:38 |
| @sonney2k | pickle27, btw when you do libray(shogun) in R - and you get that failure you should still be able to use all of shoguns stuff | 23:39 |
| @sonney2k | pickle27, just try x=GaussianKernel() | 23:39 |
| pickle27 | really - sweet! | 23:39 |
| shogun-buildbot | build #1418 of deb3 - modular_interfaces is complete: Failure [failed test python_modular] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/1418 blamelist: Fernando Iglesias <fernando.iglesiasg@gmail.com> | 23:41 |
| pickle27 | sonney2k: hmm it isn't working for me | 23:41 |
| @sonney2k | pickle27, what are you getting? | 23:42 |
| pickle27 | well I can run x=GaussianKernel() | 23:42 |
| pickle27 | but I can't run my example | 23:42 |
| pickle27 | says Error in RealFeatures(X) : could not find function "f" | 23:43 |
| pickle27 | sonney2k: although just entering RealFeatures gives me something | 23:43 |
| pickle27 | this might be a my example thing | 23:43 |
| @sonney2k | pickle27, try to run some example from the examples folder | 23:44 |
| pickle27 | hmm same thing on classifier_lda_modular example | 23:45 |
| @sonney2k | pickle27, try the simplest possible thing e.g. gaussiankernel | 23:45 |
| pickle27 | sonney2k: same error each time we try and create a RealFeatures | 23:47 |
| @sonney2k | pickle27, some stuff works however: | 23:50 |
| @sonney2k | x=GaussianKernel() | 23:50 |
| @sonney2k | > x$get_width() | 23:50 |
| @sonney2k | [1] 1 | 23:50 |
| pickle27 | sonney2k: yeah some stuff is working, just something is off with the RealFeatures | 23:50 |
| pickle27 | which almost all the examples use | 23:50 |
| @sonney2k | > x=matrix(c(1,2,3,4,5,6),2,3) | 23:51 |
| @sonney2k | > x | 23:51 |
| @sonney2k | [,1] [,2] [,3] | 23:51 |
| @sonney2k | [1,] 1 3 5 | 23:51 |
| @sonney2k | [2,] 2 4 6 | 23:51 |
| @sonney2k | > y=RealFeatures(x) | 23:51 |
| @sonney2k | Error in RealFeatures(x) : could not find function "f" | 23:51 |
| @sonney2k | yeah seems like | 23:51 |
| @sonney2k | pickle27, might be a general typemap thing | 23:52 |
| @sonney2k | z<-BinaryLabels(c(-1,1)) | 23:52 |
| @sonney2k | Error in BinaryLabels(c(-1, 1)) : could not find function "f" | 23:52 |
| @sonney2k | same error | 23:52 |
| pickle27 | yeah | 23:52 |
| @sonney2k | pickle27, we changed sooo damn much since stuff worked the last time for R modular | 23:54 |
| @sonney2k | might as well be that typemaps don't even use SGVector | 23:54 |
| * sonney2k checks | 23:54 | |
| shogun-notifier- | shogun: Soeren Sonnenburg :develop * 5812e0d / src/.r-install.sh,src/Makefile.template: https://github.com/shogun-toolbox/shogun/commit/5812e0d9af7931b3152977aae3226c291066d99e | 23:55 |
| shogun-notifier- | shogun: rename shogun -> modshogun for R and add some fixes | 23:55 |
| pickle27 | yeah | 23:55 |
| pickle27 | main reason I'm working on an R example is because it seems a lot of groups who work on this stuff use R | 23:56 |
| pickle27 | and I want them to be able to find and use us after this | 23:56 |
| pickle27 | because we'll have essentially the best unified collection of ICA techniques based off AJD of anyone | 23:56 |
| @sonney2k | pickle27, what shall I say | 23:57 |
| @sonney2k | pickle27, it works for all languages except R | 23:57 |
| pickle27 | yeah - also | 23:57 |
| pickle27 | I didn't realize how rough R was for wrapping until these past few days | 23:58 |
| @sonney2k | pickle27, typemaps exist but look buggy (will lead to crashes) | 23:59 |
| @sonney2k | pickle27, but biggest issue is to figure out why this happens | 23:59 |
| --- Log closed Mon Jul 29 00:00:12 2013 | ||
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!