--- Log opened Thu Aug 03 00:00:22 2017 | ||
-!- olinguyen [81615ad9@gateway/web/freenode/ip.129.97.90.217] has quit [Quit: Page closed] | 05:36 | |
-!- mikeling [uid89706@gateway/web/irccloud.com/x-mkoruuyhyohpgnhz] has joined #shogun | 08:08 | |
@wiking | mikeling, hey | 09:24 |
---|---|---|
@wiking | here? | 09:24 |
mikeling | wiking: hey | 09:24 |
mikeling | yes | 09:24 |
@wiking | ok so about the biginput | 09:25 |
@wiking | Yes most of the time the idea is that you need to change the source as well to index_t | 09:25 |
@wiking | But this is not like a must | 09:25 |
@wiking | It depends | 09:25 |
@wiking | Now the way we could do this | 09:25 |
@wiking | That you do the changes commit by commit | 09:25 |
@wiking | meaning you change in one place and all the connected places | 09:25 |
@wiking | And send in the commit | 09:25 |
@wiking | And then I can review | 09:25 |
@wiking | as there's no real rule of thumb | 09:25 |
@wiking | And yes | 09:25 |
@wiking | I can rebase the barnch | 09:26 |
@wiking | To the latest | 09:26 |
@wiking | thing | 09:26 |
mikeling | wiking: yeah, that's great. Thank you | 09:27 |
@wiking | Ok there's a lot of conflict | 09:27 |
@wiking | But I'll do it as soon as possible | 09:27 |
mikeling | but since the index_t no longer pointer to int32_t https://github.com/shogun-toolbox/shogun/commit/e8c66f0d849696f890af5645622e2feb2eef29b3#diff-1a988b6d5203d889a25d01f2fb6ffb72R62 | 09:27 |
mikeling | actually, I had try to do it commit by commit | 09:27 |
mikeling | but the true is many places get involved into this, like I said in the email | 09:28 |
mikeling | some places we use index_t | 09:28 |
mikeling | but we actually pass a int32_t to it | 09:28 |
mikeling | it works before since they are equal but it's not after we point index_t to int64_t | 09:29 |
mikeling | like add_vector(), if we try to build the feature/BigInput branch directly, we will get no matching member function fo call to 'add_vector' in many places since we pass a int32_t* to index_t*. | 09:52 |
@wiking | Ok just a sec | 10:25 |
@wiking | Had to do some meeting | 10:25 |
@wiking | mikeling, ok I've pushed the rebased one | 10:34 |
mikeling | wiking: ok, thank you. Let me update it | 10:39 |
-!- travis-ci [~travis-ci@ec2-54-221-76-249.compute-1.amazonaws.com] has joined #shogun | 10:46 | |
travis-ci | it's Viktor Gal's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: https://travis-ci.org/shogun-toolbox/shogun/builds/260513966 | 10:46 |
-!- travis-ci [~travis-ci@ec2-54-221-76-249.compute-1.amazonaws.com] has left #shogun [] | 10:46 | |
Trixis | wiking: so somehow i seem to have managed to load shogun on the cluster using qrsh. Only today tho | 12:18 |
Trixis | yesterday it didnt work because openblas wasnt there, today it mysteriously appeared | 12:18 |
@wiking | qrsh? | 12:19 |
Trixis | wiking: basically instead of submitting the job via the fire and forget command, i open a rsh session on one of the compute nodes | 12:21 |
Trixis | because for some reason that way my path doesnt get brutalised | 12:21 |
@wiking | jesus | 12:22 |
Trixis | idk | 12:22 |
@wiking | this thing is not good | 12:22 |
Trixis | like its a total clsuterfuck | 12:22 |
@wiking | If you need to do things like this :( | 12:22 |
Trixis | ye | 12:22 |
Trixis | oh and all the nodes im using should be identical in specs / config, so idk why there was no openblas yesterday | 12:23 |
Trixis | (the group im part of has its own nodes) | 12:24 |
@wiking | heheh | 12:25 |
@wiking | Ok that seems like a setup problem | 12:25 |
@wiking | i'm a bit really confused | 12:25 |
@wiking | Or like undeceive whether the jnilib should contain libshogun and any other library as a static lib .... | 12:26 |
@wiking | As that way none of these problems would exists | 12:26 |
Trixis | wiking: it seems to contain libshogun | 12:28 |
Trixis | just not openblas | 12:28 |
@wiking | yeye | 12:28 |
@wiking | I mean I know what is the status quo | 12:28 |
@wiking | I'm just wondering what should be the actual optimal solution | 12:28 |
Trixis | ah, right | 12:29 |
@wiking | i mean honestly | 12:30 |
@wiking | What you would like to hat with an uber jar is | 12:30 |
@wiking | Having all these stuff | 12:30 |
@wiking | there | 12:30 |
@wiking | No? | 12:30 |
@wiking | :) | 12:30 |
Trixis | yeah, lol | 12:32 |
Trixis | shogun is actually the only library that has to be supplied locally (but thats because the chemoinformatics library used seems to require being included in an uberjar) | 12:33 |
-!- iglesiasg [~iglesiasg@217.119.234.214] has joined #shogun | 12:50 | |
-!- mode/#shogun [+o iglesiasg] by ChanServ | 12:50 | |
-!- iglesiasg [~iglesiasg@217.119.234.214] has quit [Quit: leaving] | 12:59 | |
-!- iglesiasg [~iglesiasg@217.119.234.214] has joined #shogun | 12:59 | |
-!- mode/#shogun [+o iglesiasg] by ChanServ | 12:59 | |
-!- phyj [d24d1af4@gateway/web/freenode/ip.210.77.26.244] has joined #shogun | 13:07 | |
-!- phyj [d24d1af4@gateway/web/freenode/ip.210.77.26.244] has quit [Quit: Page closed] | 13:13 | |
-!- iglesiasg [~iglesiasg@217.119.234.214] has quit [Quit: leaving] | 15:49 | |
-!- HeikoS [~heiko@untrust-out.swc.ucl.ac.uk] has joined #shogun | 15:50 | |
-!- mode/#shogun [+o HeikoS] by ChanServ | 15:50 | |
@HeikoS | micmn: hi | 16:13 |
micmn | HeikoS: hey | 16:14 |
@HeikoS | just reading your email | 16:14 |
@HeikoS | so I like the idea of making features a) state-less and b) read-only in general | 16:14 |
@HeikoS | then a lot of problems go away | 16:14 |
@HeikoS | and the underlying SGReferenced data can just be shared | 16:14 |
@HeikoS | when operations on features are called that would change them, generate a copy | 16:15 |
@HeikoS | make all iterators const | 16:15 |
@HeikoS | micmn: wiking ^ | 16:15 |
@HeikoS | no need for rw imho | 16:15 |
@wiking | Just a sec | 16:16 |
@wiking | In a meeting | 16:16 |
@HeikoS | micmn: so all algorithms that currently change the data (I dont think those are many, e.g. x-validation blows up), would create copies first | 16:17 |
micmn | so which methods would modify the features? | 16:17 |
@HeikoS | preprocessors | 16:18 |
@HeikoS | BUT | 16:18 |
@HeikoS | some of them can also be implemeted to work on the fly | 16:18 |
@HeikoS | but generally, algorithms shouldt change the features | 16:18 |
@HeikoS | so the answer is: None :D | 16:18 |
@HeikoS | micmn: does that make things simpler? | 16:19 |
micmn | yeah :P | 16:19 |
micmn | but many algorithms with dense features | 16:20 |
@HeikoS | sorry what do you mean? | 16:20 |
micmn | work directly on the underlying matrix | 16:20 |
@HeikoS | oh yes | 16:20 |
@HeikoS | still ok | 16:20 |
@HeikoS | just const | 16:20 |
@HeikoS | (as a first step) | 16:20 |
@HeikoS | then next step is iterators | 16:20 |
@HeikoS | and final step is using your new "Matrix" class | 16:20 |
@HeikoS | but first step would be to make the matrix getter const I guess | 16:21 |
@HeikoS | ah | 16:21 |
@HeikoS | subsets | 16:21 |
micmn | yep | 16:21 |
@HeikoS | well as of now | 16:21 |
@HeikoS | I think this causes a copy anyways | 16:21 |
@HeikoS | right? | 16:21 |
micmn | yeah | 16:21 |
@HeikoS | get_feature_matrix() returns a copy if a subset is active | 16:21 |
@HeikoS | which sucks big time | 16:21 |
@HeikoS | but this doesnt hinder making features const | 16:22 |
@HeikoS | so step 1 can be done | 16:22 |
@HeikoS | next step is iterators, or operations to replace the working with the matrix | 16:22 |
@HeikoS | but first step is OK | 16:22 |
@HeikoS | micmn: thoughts? | 16:22 |
micmn | mmm | 16:23 |
micmn | so you'll keep the current subset mechanism? | 16:23 |
@HeikoS | maybe for now yes | 16:23 |
@HeikoS | as making const and state-less is first step | 16:23 |
@HeikoS | I mean this is a small step | 16:23 |
@HeikoS | but with subsets | 16:24 |
@HeikoS | since feature object will be stateless | 16:24 |
@HeikoS | adding a subset will have to return a new instance | 16:24 |
@HeikoS | (with the same matrix, but with one subset added to the stack= | 16:24 |
@HeikoS | ) | 16:24 |
@HeikoS | see what I mean? | 16:24 |
micmn | yeah more or less like in the gist | 16:24 |
@HeikoS | link? | 16:24 |
micmn | https://gist.github.com/micmn/ea9e149f7c11a7b8d7ddb5f2c6682c63 | 16:25 |
@HeikoS | ah have | 16:25 |
@HeikoS | not quite | 16:25 |
@HeikoS | no modification methods on features | 16:25 |
@HeikoS | they are const | 16:25 |
micmn | yeah I refer to the view() method | 16:25 |
@HeikoS | subsetted_feats = feats.add_subset() | 16:26 |
@HeikoS | or more like | 16:26 |
@HeikoS | subsetted = feats.subset_view(inds) | 16:26 |
@HeikoS | and the no more add_* call | 16:26 |
micmn | HeikoS, ah the point that I still don't get is: iterate on what? depends on the features type i.e. densefeatures -> sgvector | 16:31 |
@HeikoS | iterate on dot product for example | 16:32 |
@HeikoS | let me find a gist | 16:32 |
@HeikoS | https://gist.github.com/lisitsyn/a6d8ff6e8690431f967c5318c3750919#file-gistfile1-txt-L129 | 16:32 |
@HeikoS | https://gist.github.com/lisitsyn/a6d8ff6e8690431f967c5318c3750919#file-gistfile1-txt-L109 | 16:33 |
@HeikoS | micmn: have to go to a talk now | 16:33 |
micmn | ok thx | 16:33 |
@HeikoS | but will still read/write here | 16:33 |
@HeikoS | so lets discuss more | 16:33 |
@HeikoS | see what I mena with the iterators? | 16:33 |
micmn | so is the iterator that performs the operation | 16:34 |
micmn | and we'll have different type of iterators | 16:34 |
-!- HeikoS [~heiko@untrust-out.swc.ucl.ac.uk] has quit [Ping timeout: 276 seconds] | 16:38 | |
-!- olinguyen [81615ad9@gateway/web/freenode/ip.129.97.90.217] has joined #shogun | 17:40 | |
mikeling | wiking: ping | 17:51 |
@wiking | pong | 17:53 |
@wiking | micmn, sorry had a fucking nightmare meeting over here | 17:53 |
micmn | :( | 17:53 |
@wiking | Ok back | 17:54 |
@wiking | I read the log | 17:54 |
@wiking | Btw we never do has_more in c++ | 17:55 |
@wiking | It's java | 17:55 |
@wiking | It's end() | 17:55 |
mikeling | wiking: Hi, what's this w for https://github.com/shogun-toolbox/shogun/commit/952906e79a60e69bfa8fa6f6303f967671c79d57#diff-b684d0a89dbd67566975b83e09135053R224 | 18:00 |
mikeling | is that a SGVector? | 18:00 |
mikeling | because I got error: use of undeclared identifier 'w' w = new_w; when building it | 18:02 |
@wiking | mmm | 18:03 |
@wiking | I think w is a float64_t vector | 18:03 |
@wiking | Wonder where it was originally declared | 18:03 |
mikeling | could we define it as SGVector<float64_t> m_w? | 18:04 |
@wiking | yeah | 18:04 |
@wiking | I just wonder when did it disappear :))) | 18:05 |
-!- HeikoS [~heiko@untrust-out.swc.ucl.ac.uk] has joined #shogun | 18:23 | |
-!- mode/#shogun [+o HeikoS] by ChanServ | 18:23 | |
@HeikoS | micmn: see what I mean with the iterators? | 18:24 |
@HeikoS | olinguyen: hi! | 18:24 |
olinguyen | hey! | 18:24 |
@HeikoS | olinguyen: fine with me with the lagged features | 18:24 |
@HeikoS | but let's finish the RF stuff first | 18:25 |
olinguyen | agreed | 18:25 |
@HeikoS | so then we also have RF in the plots | 18:25 |
micmn | HeikoS: so it iterates over the features and i.e. feats->dot(idx, w) becames iterator->dot(w) | 18:26 |
mikeling | wiking: I got this out-of-line definition of 'CWDSVMOcas' does not match any declaration in 'shogun::CWDSVMOcas' for https://github.com/shogun-toolbox/shogun/commit/952906e79a60e69bfa8fa6f6303f967671c79d57#diff-2a3c04af057ddaaf9cfa245feef22d22R81 | 18:26 |
mikeling | mmm, but I think it's same with its declaration | 18:27 |
@HeikoS | micmn: yes, so no need to touch the vectors | 18:28 |
micmn | ok cool | 18:28 |
@HeikoS | olinguyen: tada | 18:30 |
@HeikoS | first patch merged | 18:30 |
@wiking | mmm | 18:30 |
@wiking | mikeling, w8 a second | 18:30 |
@wiking | I have to check this | 18:30 |
mikeling | ok | 18:30 |
@wiking | As develop actually should work on gpl repo already | 18:30 |
@wiking | but now there's something weir | 18:31 |
@wiking | d | 18:31 |
@wiking | :S | 18:31 |
olinguyen | great :) (and finally lol)! | 18:31 |
@HeikoS | olinguyen: it takes a few iterations usually | 18:31 |
@HeikoS | ask the others ;) | 18:31 |
mikeling | wiking: and I also don't know why the CMath::min() has error https://pastebin.mozilla.org/9028758 | 18:31 |
mikeling | since as I both of the parameter are int32_t which shouldn | 18:32 |
mikeling | * shouldn't have problem | 18:32 |
@wiking | mmm | 18:32 |
@wiking | checking | 18:32 |
-shogun-buildbot:#shogun- Build deb3 - interfaces #77 is complete: Failure [java (failure)] - http://buildbot.shogun-toolbox.org:8080/#builders/37/builds/77 | 18:57 | |
olinguyen | HeikoS: did I cause those errors: MulticlassLabels.java:53: error: constructor MulticlassLabels(DoubleMatrix) is already defined in class MulticlassLabels | 19:00 |
olinguyen | Why is it only complaining for java? | 19:00 |
@HeikoS | olinguyen: ah crap | 19:01 |
@HeikoS | I should have waited for the last travis build ;) | 19:01 |
@HeikoS | olinguyen: lets fix this before doing anything else | 19:01 |
olinguyen | sure | 19:01 |
@HeikoS | my fault | 19:01 |
olinguyen | no worries, i think i saw it earlier but ignored | 19:01 |
@HeikoS | olinguyen: ok the problem is this | 19:03 |
@HeikoS | you know we use SWIG to auto generate the interfaces | 19:03 |
olinguyen | right | 19:03 |
@HeikoS | so for every method/constructor, swig generates a method in the target language | 19:03 |
@HeikoS | like CMulticlassLabels::CMulticlassLabels(const SGMatrix<float64_t> confidences) | 19:03 |
@HeikoS | and it inserts the language-specific type into the SG* types | 19:03 |
@HeikoS | which is DoubleMatrix in java | 19:04 |
@HeikoS | (we use a package called jblas which defines it) | 19:04 |
@HeikoS | now the thing is | 19:04 |
@HeikoS | that jblas treats both vectors and matrices as DoubleMatrix | 19:04 |
@HeikoS | and since there already was a method: CMulticlassLabels::CMulticlassLabels(const SGVector<float64_t> src) | 19:04 |
@HeikoS | swig generates the same method signature twice | 19:04 |
@HeikoS | and therefore kaboom | 19:05 |
olinguyen | i get it | 19:05 |
@HeikoS | one fix could be | 19:05 |
@HeikoS | rather than adding this constructor, you could add a method that sets the confidences | 19:05 |
@HeikoS | olinguyen: understand what I mean? | 19:06 |
@HeikoS | wiking: we need to get rid of jblas, this is stupid that it is not typesafe between vector and matrix | 19:06 |
olinguyen | yea got it | 19:06 |
@HeikoS | olinguyen: can you send a PR for that asap? | 19:06 |
olinguyen | yep, i'll get on it now | 19:06 |
@HeikoS | we now broke the develop build (it is red) | 19:06 |
@HeikoS | so that has priority | 19:06 |
@HeikoS | as we are blocking the other guys work (they cannot check build success, it is always red) | 19:07 |
@HeikoS | I have to run now, but will check back in a few hrs | 19:07 |
olinguyen | should be done by then! | 19:07 |
@HeikoS | ok cool thx | 19:07 |
@HeikoS | olinguyen: as for the "I didnt write these tests", thanks for the reply, and all good then | 19:07 |
-!- HeikoS1 [~heiko@eduroam-int-pat-8-18.ucl.ac.uk] has joined #shogun | 19:10 | |
-!- HeikoS [~heiko@untrust-out.swc.ucl.ac.uk] has quit [Ping timeout: 258 seconds] | 19:13 | |
-!- travis-ci [~travis-ci@ec2-54-145-26-220.compute-1.amazonaws.com] has joined #shogun | 19:19 | |
travis-ci | it's Olivier's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: https://travis-ci.org/shogun-toolbox/shogun/builds/260686060 | 19:19 |
-!- travis-ci [~travis-ci@ec2-54-145-26-220.compute-1.amazonaws.com] has left #shogun [] | 19:19 | |
-!- HeikoS1 [~heiko@eduroam-int-pat-8-18.ucl.ac.uk] has quit [Ping timeout: 240 seconds] | 19:23 | |
Trixis | wiking: any idea if libsvm does any multithreading? | 19:49 |
-!- HeikoS [~heiko@host-92-0-169-11.as43234.net] has joined #shogun | 23:12 | |
-!- mode/#shogun [+o HeikoS] by ChanServ | 23:12 | |
olinguyen | HeikoS: "The job exceeded the maximum time limit for jobs, and has been terminated." but I think all the other tests passed | 23:18 |
--- Log closed Fri Aug 04 00:00:24 2017 |
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!