--- Log opened Thu May 02 00:00:29 2013 | ||
cameron__ | not sure my changes went in | 00:08 |
---|---|---|
cameron__ | do people usually commit via the submodule - data or the master shogun project? | 00:08 |
-!- cameron__ [~quassel@global-2-1.nat.csx.cam.ac.uk] has quit [Remote host closed the connection] | 00:16 | |
gsomix | sonney2k, I sent the proposal. | 00:45 |
gsomix | nite, guys | 00:50 |
@iglesiasg | night | 00:51 |
-!- codinninja [~satya@202.3.77.221] has joined #shogun | 01:20 | |
-!- codinninja [~satya@202.3.77.221] has left #shogun [] | 01:21 | |
-!- syst3mw0rm [~quassel@ec2-54-235-165-148.compute-1.amazonaws.com] has left #shogun ["http://quassel-irc.org - Chat comfortably. Anywhere."] | 01:57 | |
-!- iglesiasg [~nando@s83-179-44-135.cust.tele2.se] has quit [Quit: leaving] | 02:16 | |
shogun-buildbot | build #326 of nightly_none is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/nightly_none/builds/326 | 03:03 |
-!- sids_aquarius [~sidi_@li400-124.members.linode.com] has quit [Quit: Argh! Flaky internet] | 03:31 | |
-!- votjakovr [~votjakovr@host-46-241-3-209.bbcustomer.zsttk.net] has joined #shogun | 04:46 | |
-!- wencan [~wencan@c-71-61-182-121.hsd1.pa.comcast.net] has quit [Quit: wencan] | 06:29 | |
-!- mizobe [~mizobe@189.35.244.197] has joined #shogun | 07:21 | |
-!- abi_ [3d0c137b@gateway/web/freenode/ip.61.12.19.123] has joined #shogun | 07:36 | |
-!- abi_ [3d0c137b@gateway/web/freenode/ip.61.12.19.123] has quit [Ping timeout: 245 seconds] | 07:44 | |
-!- foulwall [~foulwall@li379-21.members.linode.com] has joined #shogun | 07:45 | |
-!- abinayam [3d0c137b@gateway/web/freenode/ip.61.12.19.123] has joined #shogun | 08:17 | |
abinayam | Hi. Do we need to submit different proposals for different topics we are interested in or a single proposal listing all the topics is enough? | 08:18 |
-!- abinayam [3d0c137b@gateway/web/freenode/ip.61.12.19.123] has quit [Client Quit] | 08:21 | |
@sonney2k | gsomix, seen it. You should get your hands dirty in that direction now. Write some function that reads a single line of an ascii file - like GNU's getline | 08:25 |
@sonney2k | and maybe start a .csv reader | 08:25 |
@sonney2k | abinayam, one per topic but no more than 2-3 otherwise we won't take you seriously :) | 08:27 |
@sonney2k | HeikoS, did you merge the last commit? Somebody forgot the git push to data / merge there | 08:29 |
-!- shogun-notifier- [~irker@7nn.de] has joined #shogun | 08:31 | |
shogun-notifier- | shogun: Soeren Sonnenburg :develop * fdedc4c / src/shogun/regression/GaussianProcessRegression.h: https://github.com/shogun-toolbox/shogun/commit/fdedc4ce61f2921af61f9c4d5bfdcf68ecc8b46a | 08:31 |
shogun-notifier- | shogun: fix compile error - GP regression only needs eigen3 now | 08:31 |
shogun-buildbot | build #730 of cyg1 - libshogun is complete: Failure [failed configure] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/730 blamelist: Soeren Sonnenburg <sonne@debian.org> | 08:34 |
gsomix | sonney2k, ok! | 08:39 |
shogun-buildbot | build #895 of bsd1 - libshogun is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/bsd1%20-%20libshogun/builds/895 | 08:40 |
-!- abinayam [3d0c137b@gateway/web/freenode/ip.61.12.19.123] has joined #shogun | 08:43 | |
abinayam | @sonney2k : I am interested in 2 topics only. Thank you :) | 08:44 |
-!- sonne|work [~sonnenbu@sams-office-nat.tomtomgroup.com] has joined #shogun | 08:46 | |
-!- abinayam [3d0c137b@gateway/web/freenode/ip.61.12.19.123] has quit [Ping timeout: 245 seconds] | 08:59 | |
shogun-buildbot | build #327 of nightly_none is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/nightly_none/builds/327 | 09:00 |
-!- foulwall [~foulwall@li379-21.members.linode.com] has quit [Ping timeout: 268 seconds] | 09:10 | |
-!- erlenda_ [~erlenda@fw-oslo.intelcom.no] has joined #shogun | 09:18 | |
-!- erlenda [~erlenda@fw-oslo.intelcom.no] has joined #shogun | 09:18 | |
-!- erlenda_ [~erlenda@fw-oslo.intelcom.no] has left #shogun ["Leaving"] | 09:23 | |
-!- iglesiasg [~nando@s83-179-44-135.cust.tele2.se] has joined #shogun | 09:25 | |
-!- mode/#shogun [+o iglesiasg] by ChanServ | 09:25 | |
-!- vgorbati [d4029f22@gateway/web/freenode/ip.212.2.159.34] has joined #shogun | 09:30 | |
hushell | Hi Soeren, may I ask a few questions about SGVector? | 09:42 |
hushell | If I want to change the size of a sgvector in a function, and I want the change being passed back | 09:43 |
hushell | Can I just use resize_vector inside that function? | 09:44 |
@iglesiasg | hey hushell | 09:44 |
@iglesiasg | hushell: yeah, that should work | 09:45 |
hushell | What I am curious about is when passing a SGvector as a parameter, I don't need to use * or reference | 09:45 |
@iglesiasg | hushell: you should pass the reference | 09:46 |
@iglesiasg | I think that at least that passing the reference makes more explicit what you will do | 09:47 |
sonne|work | hushell: yes resize_vector | 09:47 |
hushell | Thanks! Are you Fernando? | 09:47 |
@iglesiasg | however, I think that even if you don't use reference, what you want to do will happen | 09:47 |
sonne|work | what is important to know here is that sgvectors properties are always copied | 09:47 |
@iglesiasg | I am not entirely sure about it though | 09:47 |
sonne|work | so if you resize_vector | 09:47 |
@iglesiasg | hushell: yeah I am Fernando :) | 09:47 |
sonne|work | it won't change the original size | 09:48 |
sonne|work | if you jsut do | 09:48 |
sonne|work | a=b | 09:48 |
hushell | Nice to meet you! I am Shell | 09:48 |
sonne|work | b.resize_vector(...) | 09:48 |
@iglesiasg | hushell: nice to meet you to | 09:48 |
@iglesiasg | too* | 09:48 |
hushell | So in my case rescale_outputs(const SGVector outputs, SGVector& new_outputs), Soeren you suggest inplace modify the outputs, and the function can be rescale_outputs(SGVector& outputs)? | 09:50 |
hushell | The case is I have a vector, maybe length of 6, inside the function, the length of vector may be changed to 4 | 09:52 |
-!- cameron__ [~quassel@global-2-1.nat.csx.cam.ac.uk] has joined #shogun | 09:53 | |
@iglesiasg | hushell: I think the version rescale_outputs(SGVector& outputs) looks good | 09:55 |
@iglesiasg | hushell: why would you need outputs and new_outputs? | 09:55 |
hushell | Fernando, I tried a bit, if passing SGVector, the content changed inside function will bring out, but if you just copy from another vector, like this a = b, then it won't bring out the change | 09:56 |
@iglesiasg | hushell: aham I see | 09:57 |
hushell | I think have another copy looks safer, I tried SGVector::resize doesn't work, but maybe the resize_vector(&) would work | 09:58 |
@iglesiasg | I agree with sonne|work, use resize_vector looks the good option | 09:58 |
@iglesiasg | btw I did a small test | 09:59 |
@iglesiasg | http://pastebin.com/4GcHbjkD | 09:59 |
@iglesiasg | what I said before was wrong, it *must* be done with SGVector& | 09:59 |
hushell | That's works for me! Thanks! So I can kill one parameter. | 10:03 |
@iglesiasg | hushell: btw, I read in your mail you have been using SO learning in CV, right? | 10:08 |
hushell | Yep, SO becomes a mainstream in CV, especially the DPM, very popular | 10:09 |
hushell | What are you working on? | 10:10 |
@iglesiasg | hushell: nice, so you are using it for something similar to facial landmark detection or so? | 10:10 |
hushell | Yeah, everything can divide into parts can be learned by SO | 10:11 |
-!- cameron__ [~quassel@global-2-1.nat.csx.cam.ac.uk] has quit [Ping timeout: 256 seconds] | 10:12 | |
@iglesiasg | hushell: I am writing my final degree project (undergrad thesis) on SSVMs applied to graphs | 10:13 |
hushell | I used the facial landmark code recent, it's like a variant of the deformable part model, with different loss function and use supervision instead of use latent positives | 10:13 |
hushell | That's awesome! I was doing something silly for my undergrad thesis. Are you going to apply a PhD? | 10:16 |
@iglesiasg | hushell: for sure :) | 10:17 |
hushell | Machine learning? | 10:17 |
@iglesiasg | hushell: I am into machine learning and autonomous robots | 10:17 |
@iglesiasg | I will see what I can find around in those fields and choose what I like the most | 10:18 |
-!- cameron__ [~quassel@global-2-11.nat.csx.cam.ac.uk] has joined #shogun | 10:19 | |
hushell | If you like more math, machine learning will be a better choice in my opinion | 10:19 |
@iglesiasg | aham, I will take it into account | 10:20 |
hushell | Good luck for your application! | 10:20 |
@iglesiasg | hushell: thanks! | 10:20 |
@iglesiasg | I am actually trying to find something a little bit simple yet fancy to show during the project presentation | 10:20 |
@iglesiasg | something from the CV domain | 10:21 |
hushell | How about image segmentation or denoising? | 10:21 |
@iglesiasg | hushell: those were the choices I was thinking of | 10:22 |
@iglesiasg | hushell: I tried fg/bg segmentation but I failed :S | 10:22 |
hushell | I am going to include an example to Shogun, if I got accepted this year | 10:22 |
hushell | try to use this inference lib http://www.di.ens.fr/~mschmidt/Software/UGM.html | 10:23 |
hushell | you can switch the learning by SSVM | 10:23 |
@iglesiasg | hushell: I see, so you have previously done fg/bg segmentation with SSVMs? | 10:23 |
@iglesiasg | let me see | 10:23 |
@iglesiasg | so the idea would be to switch the parameter estimation part for the SSVM | 10:25 |
hushell | I have some dirty code, maybe helpful for you https://code.google.com/p/avatol/source/browse/trunk/nematocyst/spinesproject/findMVC_UGM.m | 10:25 |
hushell | The SSVM I am using is actually calling the libqp | 10:25 |
hushell | Maybe this is not the best way, if you can include the loss into the node potential in the inference, the results will be better | 10:28 |
@iglesiasg | aham | 10:30 |
@iglesiasg | hushell: what sort of features do they use for this? | 10:30 |
@iglesiasg | I have seen some HOG around | 10:30 |
hushell | yep, I divide the image into blocks, each block extracted HOG | 10:31 |
hushell | For edge feature, just counts of y_i == y_j and y_i != y_j, so it's Potts model | 10:32 |
@iglesiasg | hushell: I am going to take a closer look at the code and will ask you again if you don't mind ;) | 10:34 |
hushell | Sure. I am glad if I can help | 10:35 |
hushell | Are you going to apply the GSOC this year? | 10:35 |
@iglesiasg | yeah | 10:36 |
@iglesiasg | hushell: I have applied for SO learning too and for LMNN | 10:36 |
@iglesiasg | but my main objective is LMNN | 10:37 |
-!- thoralf [~thoralf@enki.zib.de] has joined #shogun | 10:37 | |
thoralf | Hey. | 10:37 |
@iglesiasg | hey thoralf | 10:39 |
hushell | Haha, don't worry I will also be happy if you get accepted to SO learning | 10:40 |
hushell | The LMNN is a research topic of my college, you may like to talk to him | 10:40 |
@wiking | morning | 10:55 |
-!- mizobe [~mizobe@189.35.244.197] has quit [Remote host closed the connection] | 10:55 | |
@wiking | HeikoS: ping | 10:56 |
hushell | \quit | 10:57 |
@wiking | hushell: /quit ;) | 10:57 |
hushell | :p | 10:57 |
-!- hushell [43bd6474@gateway/web/freenode/ip.67.189.100.116] has quit [] | 10:57 | |
-!- vgorbati [d4029f22@gateway/web/freenode/ip.212.2.159.34] has quit [Ping timeout: 245 seconds] | 10:59 | |
-!- vgorbati [d4029f22@gateway/web/freenode/ip.212.2.159.34] has joined #shogun | 11:11 | |
@HeikoS | wiking: pong | 11:12 |
@wiking | HeikoS: get_mean_vector | 11:14 |
@HeikoS | ? | 11:14 |
@wiking | ah ok | 11:14 |
@wiking | it's not rdn | 11:14 |
@wiking | rnd | 11:14 |
@wiking | it's based on the model | 11:15 |
@HeikoS | wiking: no idea what you are talking about :D | 11:15 |
@HeikoS | explain | 11:15 |
@wiking | anyways i was looking into RNG | 11:15 |
@HeikoS | I see | 11:15 |
@wiking | and now i'm trying to figure out where the changes are going to be | 11:15 |
@HeikoS | cool what did you find | 11:15 |
@wiking | as i thought to use | 11:15 |
@wiking | or create an RND | 11:15 |
@wiking | RNG | 11:15 |
@HeikoS | what about sergey's c++11 idea? | 11:16 |
@wiking | that can give you back like a SGVector with samples of a standard distrib | 11:16 |
@wiking | like the new c++11 | 11:16 |
@wiking | c++11 is great | 11:16 |
@wiking | but what if the user doesn't have a compiler yet | 11:16 |
@wiking | that supports c++11 | 11:16 |
sonne|work | wiking: changes would just be in CMath::rand* and init_random | 11:16 |
@wiking | HeikoS: std::normal_distribution<double> normal_dist(mean, stddeviation); // | 11:17 |
-!- van51 [~van51@athedsl-401908.home.otenet.gr] has joined #shogun | 11:17 | |
@wiking | HeikoS: it has a good api | 11:17 |
@wiking | only thing that we cannot say that we only support compilers that supports c++11 | 11:17 |
@HeikoS | wiking yes, we need the random normals and the uniform ones, I think we dont have more distributions right? | 11:17 |
@wiking | sonne|work: i've checked a comparison between R's, c++11's and boost's RNG, and c++11 was the fastest | 11:18 |
@HeikoS | what about something as libssl then? | 11:18 |
@wiking | HeikoS: yeah i think that 2 distrib would be sufficient at the moment | 11:18 |
@wiking | HeikoS: well it's an option, but then again sonne|work disagrees | 11:18 |
@HeikoS | ok | 11:18 |
@HeikoS | but boost? | 11:18 |
@HeikoS | thats massive | 11:18 |
@wiking | boost is bloated | 11:18 |
@wiking | this RNG is meant to be really fast: http://en.wikipedia.org/wiki/Ziggurat_algorithm | 11:19 |
@wiking | the code for it is like 100 lines in c | 11:20 |
@wiking | what we could do is to have 2 standard engines for RNG | 11:20 |
@wiking | Ziggurat algorithm and Mersenne Twister | 11:20 |
@wiking | both of them are pretty standard for PRNG | 11:21 |
@wiking | and then one can choose, but would say default to Ziggurat the PRNG as that's faster than mersenne twister | 11:21 |
@wiking | and then we are pretty much done... :P | 11:22 |
@HeikoS | okay | 11:22 |
@HeikoS | question: | 11:22 |
@HeikoS | will we still have problems with the tests? | 11:22 |
@wiking | both of their implementation is available in various forms ... | 11:22 |
@wiking | HeikoS: well if we use our own PRNG then no | 11:22 |
@HeikoS | since the problem is that the streams are not reproducable | 11:22 |
@HeikoS | but why have two then? | 11:22 |
@HeikoS | also, btw for us, speed of rng does not really matter that much | 11:23 |
@HeikoS | so why not just go with one? | 11:23 |
@wiking | well then let's just decide which PRNG we would like to use | 11:23 |
@wiking | and that's it | 11:23 |
@HeikoS | wiking or actually | 11:23 |
@HeikoS | we can add more | 11:23 |
@HeikoS | and then let user decide which one to use in his code | 11:24 |
@HeikoS | but std one is fixed | 11:24 |
@HeikoS | so that the examples all work | 11:24 |
@wiking | HeikoS: well as said | 11:24 |
@wiking | we have a default PRNG engine | 11:24 |
sonne|work | wiking: did you measure speed also for opencv's RNG? | 11:24 |
@HeikoS | this is the way its done for example in matlab, you can choose your stream and seed it | 11:24 |
@wiking | but we provide more... | 11:24 |
@wiking | sonne|work: they use Mersenne | 11:24 |
sonne|work | didn't they have multiple? | 11:24 |
@lisitsyn | I woke up! :D | 11:25 |
@wiking | sonne|work: the code is imo too much bundled into opencv | 11:25 |
@lisitsyn | speed of RNG - does that matter? | 11:25 |
@wiking | sonne|work: so i'd rather not even touch opencv's RNG | 11:25 |
sonne|work | lisitsyn: yes of course | 11:26 |
@HeikoS | sonne|work: why does it matter? | 11:26 |
@HeikoS | for shogun I mean | 11:26 |
sonne|work | do you want to wait 1 hour to get a 1000x1000 rnd matrix? | 11:26 |
-!- vgorbati [d4029f22@gateway/web/freenode/ip.212.2.159.34] has quit [Ping timeout: 245 seconds] | 11:26 | |
@lisitsyn | well that's not possible to write that bad RNG :D | 11:26 |
sonne|work | I used it in qsort for the pivot element | 11:26 |
@HeikoS | I think the speed differences wrt to matrices that you can store in memory (small) is minor, but I might be wrong | 11:27 |
sonne|work | but sure one can always work around this | 11:27 |
-!- iglesiasg [~nando@s83-179-44-135.cust.tele2.se] has quit [Ping timeout: 264 seconds] | 11:27 | |
sonne|work | lisitsyn: just compare /dev/random and /dev/urandom | 11:27 |
@lisitsyn | sonne|work: yeah I know they are different in perf | 11:28 |
@lisitsyn | but I mean it is not that usual thing to compute random values | 11:28 |
@lisitsyn | it usually happens when you either initialize random data (but that's just test) or initialize something in iterative algorithm | 11:28 |
-!- vgorbati [d4029f22@gateway/web/freenode/ip.212.2.159.34] has joined #shogun | 11:29 | |
@wiking | anyhow | 11:30 |
@wiking | the implementations you can find | 11:30 |
@wiking | are like 100 lines | 11:30 |
@wiking | see http://www.bedaux.net/mtrand/mtrand.cpp.html for mersenne twister | 11:31 |
-!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout] | 11:31 | |
@wiking | afaik these are overoptimized already | 11:31 |
@wiking | as the point of these various PRNG is that who can create/define a faster PRNG :P | 11:31 |
sonne|work | lisitsyn: well I don't mind having a slow but very accurate prng and a fast one for the other case | 11:31 |
@wiking | what's very accurate prng? | 11:32 |
@wiking | the things one usually measures of a prng is speed and the entropy of the output.... | 11:33 |
-!- vgorbati [d4029f22@gateway/web/freenode/ip.212.2.159.34] has quit [Ping timeout: 245 seconds] | 11:33 | |
sonne|work | wiking: in limit hist(x) will match the wanted distribution p(x) | 11:33 |
sonne|work | like normal distribution, or equally distributed | 11:33 |
@wiking | sonne|work: well PRNG is simply a random generator | 11:33 |
@wiking | so the rest should be done by us | 11:33 |
@wiking | ;) | 11:33 |
sonne|work | HeikoS: could you please click the 'I want to mentor knob'! | 11:34 |
@wiking | PRNG will just assures us that what we get is actually something like a white noise | 11:34 |
sonne|work | wiking: for uniform I guess? | 11:34 |
@HeikoS | sonne|work: will do! | 11:34 |
@wiking | sonne|work: white noise :) | 11:34 |
@wiking | nothing else | 11:34 |
sonne|work | HeikoS: done? | 11:35 |
@wiking | and if we want to have different distribs | 11:35 |
@wiking | then we have to create our own methods for it | 11:35 |
@wiking | based on PRNG | 11:35 |
@wiking | so yeah indeed will get a uniform distrib with a good PRNG | 11:35 |
@wiking | uniform distrib that actually reproducible | 11:36 |
@wiking | over different os/arch etc | 11:36 |
@wiking | based on the seed | 11:36 |
@HeikoS | donre | 11:36 |
@wiking | so | 11:36 |
@wiking | let's have a CRNG class ;) | 11:36 |
@wiking | or rather CPRNG | 11:37 |
@wiking | shogun/lib/PRNG.h/cpp | 11:37 |
@wiking | all agree? :) | 11:37 |
@wiking | good | 11:37 |
@lisitsyn | guyz guyz | 11:38 |
@lisitsyn | I kan haz a betta soluktion | 11:38 |
@lisitsyn | we haz to criate a madule shogun-rendom | 11:38 |
@wiking | lisitsyn: doz it! | 11:38 |
@lisitsyn | & putz a few gigobytez of rendom veluez | 11:39 |
@wiking | lol | 11:39 |
@wiking | :> | 11:39 |
@wiking | lisitsyn: had too much vodka yesterday when u celebrated the day of work? :) | 11:39 |
sonne|work | wiking: shogun/math/Random.{h,cpp} | 11:39 |
sonne|work | wiking: lisitsyn is always like this | 11:39 |
@lisitsyn | haha | 11:40 |
sonne|work | you know Russian ;) | 11:40 |
@wiking | ok let's gitflow this one as well | 11:40 |
@wiking | :) | 11:40 |
@lisitsyn | peace! vodka! putin! | 11:40 |
@wiking | lisitsyn: hasn't putin gave u the medal for the hero of work yesterday? :D | 11:41 |
@lisitsyn | wiking: no I am a foreign agent you know | 11:41 |
@lisitsyn | received money from the enemy two times | 11:41 |
@lisitsyn | no pasaran! | 11:41 |
@wiking | sonne|work: you've ment shogun/mathematics/Random.{h,cpp} right? | 11:41 |
sonne|work | wiking: yes | 11:41 |
-!- shogun-notifier- [~irker@7nn.de] has joined #shogun | 11:43 | |
shogun-notifier- | shogun: iglesias :develop * 100d655 / src/shogun/ (4 files): https://github.com/shogun-toolbox/shogun/commit/100d655bf89fdbd135dd8119a506f869e562674b | 11:43 |
shogun-notifier- | shogun: Drop static SGVector::resize(). | 11:43 |
shogun-notifier- | shogun: This method can be misleading since it should not be used for SGVectors, | 11:43 |
shogun-notifier- | shogun: use SGVector::resize_vector() instead. | 11:43 |
shogun-notifier- | shogun: Soeren Sonnenburg :develop * 088dc29 / src/shogun/ (4 files): https://github.com/shogun-toolbox/shogun/commit/088dc299c9969da210290319afb28d23e4ec70bd | 11:43 |
shogun-notifier- | shogun: Merge pull request #1040 from iglesias/feature/drop_resize | 11:43 |
shogun-notifier- | shogun: | 11:43 |
shogun-notifier- | shogun: Drop static SGVector::resize(). | 11:43 |
@wiking | doh | 12:00 |
@wiking | why i cannot add parameter to a class that's derived directly from SGObject? :) | 12:00 |
@wiking | http://pastebin.com/ZVS2s7nR | 12:01 |
@lisitsyn | 21 proposals so far! | 12:03 |
shogun-buildbot | build #731 of cyg1 - libshogun is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/731 | 12:05 |
@wiking | lol | 12:15 |
@wiking | i've just realised | 12:15 |
@wiking | http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/ | 12:15 |
@wiking | so i think we should go with this | 12:15 |
@wiking | as this is a standard mersenne twister | 12:15 |
@wiking | but if sse2 or alitvec is available | 12:15 |
@wiking | it can use it in order to boost up the speed | 12:15 |
@wiking | sonne|work: ^ ? | 12:18 |
-!- poojits [75d35d4a@gateway/web/freenode/ip.117.211.93.74] has joined #shogun | 12:42 | |
poojits | I want to contribute to Shogun, so I looked at the entrance tasks and I want to give issue #1025 a shot. I don't know if it's a bad thing, but I feel like I need to understand the entire codebase, so I know exactly what I am doing. How do I start? | 12:44 |
-!- vgorbati [d4029f22@gateway/web/freenode/ip.212.2.159.34] has joined #shogun | 12:44 | |
sonne|work | wiking: ohh a maintained thing very good! | 12:57 |
sonne|work | website from 1995 but updated 2013 - so yes why not. give it a try... | 12:58 |
@wiking | sonne|work: the only question now of course | 13:00 |
@wiking | whether we want SFMT or dSFMT | 13:01 |
@wiking | and that or is not necessarily exclusive or ;) | 13:01 |
@wiking | as sfmt can create us fast int32/64 arrays | 13:02 |
@wiking | as dsfmt can do the same with double | 13:02 |
sonne|work | both then :) | 13:02 |
vgorbati | lisitsyn: here? | 13:02 |
@lisitsyn | vgorbati: yes | 13:02 |
@wiking | hehehe yeah i guessed so | 13:02 |
@wiking | sonne|work: there's only one stupid problem here with this lib | 13:03 |
sonne|work | ? | 13:03 |
@wiking | This function generates and returns 64-bit pseudorandom number. * init_gen_rand or init_by_array must be called before this function. * The function gen_rand64 should not be called after gen_rand32, * unless an initialization is again executed. | 13:03 |
@wiking | so basically i'll have to maintain a state | 13:03 |
@wiking | in the RNG | 13:03 |
@wiking | and reinit the struct if genrand32 or the other has been called | 13:03 |
sonne|work | wiking: you have to add locking | 13:04 |
-!- iglesiasg [~nando@s83-179-44-135.cust.tele2.se] has joined #shogun | 13:04 | |
-!- mode/#shogun [+o iglesiasg] by ChanServ | 13:04 | |
sonne|work | maybe expose 2 functions then | 13:04 |
sonne|work | one thread safe (where one has to input the state) | 13:04 |
sonne|work | and one where the state is maintained internally | 13:05 |
@wiking | ah fuck yeah | 13:05 |
@wiking | i havent' thought about being thread safe | 13:05 |
vgorbati | lisitsyn: about multidimensional scaling: the method description looks quite understandable, while implementation does not:) Theoretically, the only method parameters should be num_neighbors and squishing_rate, am I right? | 13:06 |
@lisitsyn | vgorbati: multidimensional scaling? it doesn't have any parameters at all | 13:06 |
vgorbati | lisitsyn: wait, what?:) At least K - the number of neighbors | 13:07 |
@iglesiasg | poojits: hey, I think that issue is already been taken care of by another person but you are free to do it if you want | 13:07 |
@lisitsyn | no, MDS has no deals with neighbors - that's isomap | 13:07 |
sonne|work | wiking: woahh! | 13:07 |
sonne|work | rand() is also not thread safe | 13:07 |
sonne|work | I guess that could explain some issues we were having | 13:07 |
vgorbati | lisitsyn: oh, my fault - manifold sculpting:D | 13:07 |
@lisitsyn | vgorbati: ahh | 13:07 |
-!- cameron__ [~quassel@global-2-11.nat.csx.cam.ac.uk] has quit [Ping timeout: 245 seconds] | 13:08 | |
vgorbati | lisitsyn: at least that's what the original paper says.. | 13:09 |
@wiking | sonne|work: heheh ok i'll make it thread safe | 13:09 |
@wiking | just first i want to import then both of the libraries | 13:09 |
vgorbati | lisitsyn: but since it is iterational, I am thinking whether I should use a max_iteration parameter as well.. | 13:10 |
@lisitsyn | vgorbati: yes why not | 13:10 |
@lisitsyn | it always makes sense to limit # of iterations | 13:10 |
@wiking | oooh shit | 13:11 |
@wiking | redefinitions :S | 13:11 |
@lisitsyn | vgorbati: I wish there was a matlab implementation | 13:12 |
vgorbati | lisitsyn: ok, one question solved:) Now another one:since it is also gradient-descend-like, it uses learning rate - but in the implementation, Gashler sets it to average distance to neighbors and then during each iterations multiplies it by magic numbers:) | 13:13 |
@lisitsyn | vgorbati: well he knows better - he is the author :D | 13:13 |
vgorbati | lisitsyn: So, leave it as it is?) | 13:14 |
@lisitsyn | yeah for now | 13:14 |
vgorbati | lisitsyn: the algorithm is actually full of these numbers:) about matlab - that would be awesome) | 13:16 |
vgorbati | lisitsyn: but, well, I have what I have) | 13:16 |
@lisitsyn | vgorbati: I googled it a little but haven't found anything | 13:17 |
-!- mikhailBelous [~quassel@37.98.242.99] has joined #shogun | 13:19 | |
vgorbati | lisitsyn: now 3rd question: as I see it now, in embedManifoldSculpting method I should get the neighbors using find_neighbors method, then find 2 SparseWeightMatrix - one for distances and one for angles, and then actually call the method passing these matrices and parameters into. Does it make sense? | 13:19 |
@lisitsyn | vgorbati: let me check teh paper | 13:20 |
vgorbati | http://www.cc.gatech.edu/~isbell/reading/papers/ManifoldSculpting.pdf | 13:20 |
mikhailBelous | I sent my aplication yesterday somebody please watch it | 13:21 |
@lisitsyn | mikhailBelous: yeah we have seen | 13:22 |
mikhailBelous | Did you like it? | 13:23 |
mikhailBelous | Any comments,question suggestions? | 13:23 |
@lisitsyn | mikhailBelous: alright, first - it should be one proposal per idea so if you are applying to two ideas (with two different mentors) - please send two proposal | 13:26 |
@lisitsyn | s | 13:26 |
@lisitsyn | next, please read it carefully | 13:27 |
mikhailBelous | Ideas? | 13:27 |
-!- hoijui [~hoijui@dslb-088-074-121-064.pools.arcor-ip.net] has joined #shogun | 13:28 | |
@wiking | sonne|work: ok question: the CMath::random* function are static... while now i'm creating a CRandom class... hence we need to statically allocate that CRandom object somewhere... like in init_shogun() ? | 13:28 |
@lisitsyn | mikhailBelous: if you are applying to LMNN or dimension reduction - send two proposals - one for LMNN and one for DR | 13:28 |
sonne|work | wiking: ok | 13:29 |
@wiking | sonne|work: ah i see init_shogun creates a CMath class... then we can actually make CRandom part of CMath, or? | 13:29 |
mikhailBelous | Year I got it. | 13:29 |
mikhailBelous | What I have to read carefully? | 13:29 |
@wiking | sonne|work: i mean to be a private variable of CMath | 13:29 |
@wiking | although even then the reference on CRandom will be needed, i.e. like a global or something | 13:30 |
sonne|work | wiking: maybe even make it a separate class | 13:31 |
@lisitsyn | mikhailBelous: your proposal, please check it for spelling and grammar | 13:31 |
@wiking | sonne|work: it'll be a separate class... | 13:31 |
@wiking | CRandome | 13:31 |
@wiking | *CRandom | 13:32 |
@lisitsyn | wiking: french class | 13:32 |
@lisitsyn | 'CRandome' | 13:32 |
@lisitsyn | :D | 13:32 |
mikhailBelous | Okay.Sorry I'm enlgish is not my native. | 13:32 |
@lisitsyn | that's ok it is not native for anyone here just read it carefully | 13:33 |
mikhailBelous | May I copypaste my proposal? | 13:36 |
@lisitsyn | well except to some parts they can be similar | 13:36 |
-!- sids_aquarius [~sidi_@li400-124.members.linode.com] has joined #shogun | 13:39 | |
@lisitsyn | 23 | 13:43 |
@lisitsyn | sonne|work: I've told you soo! | 13:43 |
@lisitsyn | 24 | 13:45 |
mikhailBelous | And how about me am I good for this project | 13:45 |
mikhailBelous | ? | 13:45 |
votjakovr | Hi everyone! I have just submitted my proposal:) | 13:45 |
@lisitsyn | votjakovr: yeah I have seen | 13:45 |
@lisitsyn | mikhailBelous: we are unable to say whether any student is going to be accepted or not - that's going to happen on 27 May | 13:46 |
@wiking | sonne|work: any idea why i cannot do SG_ADD (see: http://pastebin.com/ZVS2s7nR | 13:48 |
mikhailBelous | Oki-doki. I'm just intrested did you like it or not | 13:49 |
@lisitsyn | mikhailBelous: you have got no contributions so far - that should be the top priority now | 13:50 |
-!- cameron__ [~quassel@global-2-11.nat.csx.cam.ac.uk] has joined #shogun | 13:53 | |
-!- poojits [75d35d4a@gateway/web/freenode/ip.117.211.93.74] has quit [Ping timeout: 245 seconds] | 14:14 | |
-!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout] | 14:43 | |
-!- cameron__ [~quassel@global-2-11.nat.csx.cam.ac.uk] has quit [Ping timeout: 248 seconds] | 14:57 | |
-!- votjakovr [~votjakovr@host-46-241-3-209.bbcustomer.zsttk.net] has quit [Quit: Leaving] | 15:03 | |
-!- erlenda [~erlenda@fw-oslo.intelcom.no] has quit [Remote host closed the connection] | 15:03 | |
-!- sids_aquarius [~sidi_@li400-124.members.linode.com] has quit [Ping timeout: 260 seconds] | 15:06 | |
-!- wencan [~wencan@c-71-61-182-121.hsd1.pa.comcast.net] has joined #shogun | 15:27 | |
-!- thoralf [~thoralf@enki.zib.de] has quit [Quit: Konversation terminated!] | 15:28 | |
-!- vgorbati [d4029f22@gateway/web/freenode/ip.212.2.159.34] has quit [Ping timeout: 245 seconds] | 15:28 | |
-!- erlenda [~erlenda@fw-oslo.intelcom.no] has joined #shogun | 15:30 | |
-!- thoralf [~thoralf@enki.zib.de] has joined #shogun | 15:40 | |
thoralf | Hey. | 15:40 |
@HeikoS | thoralf: hi! | 15:40 |
@HeikoS | just about going into the bug | 15:40 |
@HeikoS | sorry for the delay, gsoc eats a lot of time | 15:40 |
@wiking | sonne|work: ping ping ping | 15:41 |
thoralf | Heiko: Tell me it's a bug, so I know that the solution is more than not beeing stupid. ;) | 15:42 |
sonne|work | wiking: you have to include lib/parameter.h IIRC | 15:43 |
@HeikoS | thoralf: have to go into it :) | 15:43 |
@wiking | sonne|work: we need a macro HAVE_SSE2 | 15:43 |
@wiking | in case there's sse2 | 15:43 |
@wiking | i've already made some changes | 15:43 |
sonne|work | wiking: lets try first w/o sse | 15:43 |
sonne|work | we can speed things up later | 15:43 |
@wiking | kk i'm just doing the configure now | 15:44 |
sonne|work | HeikoS: ping ping ping - please assign yourself as mentor to students you intend to mentor | 15:45 |
@HeikoS | sonne|work done | 15:46 |
@HeikoS | is this possible mentoring or definite vote? | 15:46 |
sonne|work | we can change until may 22 IIRC | 15:47 |
sonne|work | or 24 even | 15:47 |
@wiking | sonne|work: ok it's ready | 15:48 |
@wiking | sonne|work: i'll push the feature branch to the repo | 15:48 |
@wiking | and comment it | 15:48 |
@HeikoS | sonne|work: question is: do I have to say yes to multiple people? | 15:48 |
@wiking | it's purely the import of SFMT and adding a new CRandom class | 15:49 |
sonne|work | you can say want to mentor to multiple people yes | 15:49 |
-!- cameron__ [~quassel@global-2-11.nat.csx.cam.ac.uk] has joined #shogun | 15:49 | |
sonne|work | I will assign you only 1 per task for sure :) | 15:49 |
-!- iglesiasg [~nando@s83-179-44-135.cust.tele2.se] has quit [Quit: leaving] | 15:49 | |
@wiking | the static allocation of the object in init_shogun is not done yet | 15:49 |
@HeikoS | sonne|work: I am fine with that :D | 15:49 |
@wiking | nor that CMath::random is using the new PRNG | 15:50 |
@HeikoS | sonne|work: if people send PRs against shogun-data, they can only do it to "master", but thats fine right? The data version of the develop/master repository selects the correct one | 15:51 |
sonne|work | 11. What happens if two students are accepted to work on the same project, e.g. from an organization's Ideas list? | 15:52 |
sonne|work | That's fine, a little duplication is par for the course in open source. | 15:52 |
sonne|work | ohh look at this | 15:52 |
sonne|work | one could even have two students working on the same task | 15:52 |
sonne|work | I didn't know | 15:52 |
sonne|work | HeikoS: yes that's ok | 15:52 |
@HeikoS | lisitsyn: ^ | 15:52 |
@HeikoS | ok | 15:52 |
sonne|work | wiking: then do the static analysis | 15:53 |
@wiking | ssh: connect to host github.com port 22: Connection refused | 15:53 |
@wiking | LOL | 15:53 |
@wiking | wtf is this | 15:53 |
@wiking | ok now it went ok | 15:53 |
-!- shogun-notifier- [~irker@7nn.de] has joined #shogun | 15:53 | |
shogun-notifier- | shogun: Viktor Gal :feature/PRNG * 35b7254 / src/shogun/lib/external/SFMT/ (16 files): https://github.com/shogun-toolbox/shogun/commit/35b7254d4e861b78a24ae35323450a9071b55d99 | 15:53 |
shogun-notifier- | shogun: Import SFMT PRNG | 15:53 |
shogun-notifier- | shogun: Viktor Gal :feature/PRNG * 31da88a / src/shogun/mathematics/Random.cpp,src/shogun/mathematics/Random.h: https://github.com/shogun-toolbox/shogun/commit/31da88aac065398f6aaf0ad0a0ff897fbb72c151 | 15:53 |
shogun-notifier- | shogun: Create class for PRNG | 15:53 |
shogun-notifier- | shogun: wrapper class for SFMT | 15:53 |
shogun-notifier- | shogun: Viktor Gal :feature/PRNG * 81599e1 / src/configure: https://github.com/shogun-toolbox/shogun/commit/81599e1c93ab83d54c1599697990dfd9c713d5fb | 15:53 |
shogun-notifier- | shogun: Add --mexp and HAVE_SSE2 defines in ./configure | 15:53 |
@wiking | there you go comment it | 15:53 |
thoralf | sonne|work: AFAIK it must be clear, which contribution is attributed to which student. Beside of this, | 15:54 |
thoralf | sonne|work: i.e. no "team work" | 15:54 |
sonne|work | wiking: what is +SFMT_MEXP=19937 | 15:54 |
sonne|work | thoralf: yes | 15:54 |
@wiking | sonne|work: mersenne exponent | 15:55 |
sonne|work | but ML is soo wide spread basically any idea we have on the list can be diveded into multple | 15:55 |
@wiking | sonne|work: it's required by SFMT | 15:55 |
sonne|work | wiking: so why is this in configure then? | 15:55 |
sonne|work | or which one should one use | 15:55 |
@wiking | sonne|work: because one can use other exponents | 15:56 |
@wiking | see ./configure --help | 15:56 |
sonne|work | how does it affect randomness | 15:56 |
sonne|work | yeah seen it | 15:56 |
@wiking | SFMT_MEXP This macro is required. This macro means Mersenne exponent and the period of generated code will be 2SFMT_MEXP-1. SFMT_MEXP must be one of 607, 1279, 2281, 4253, 11213, 19937, 44497, 86243, 132049, 216091. | 15:56 |
@wiking | 2^SFMT_MEXP-1 | 15:57 |
@wiking | to be correct with the above copy paste | 15:57 |
@wiking | it's a prime i know that but how that effects randomness | 15:57 |
@wiking | no clue | 15:57 |
@wiking | one should read their paper | 15:57 |
sonne|work | the period of way over 1e5000 is certainly good enough for my life time | 15:58 |
sonne|work | yeah it is kind of weird. I guess it will affect speed or sth | 15:58 |
@wiking | let's stick to the default | 15:58 |
@wiking | but since it's a parameter | 15:59 |
@wiking | i reckon one should have access to change it | 15:59 |
sonne|work | We have no clue what it does. | 15:59 |
sonne|work | Changing it is dangerous aka might kill properties of the RN and I would rather not | 15:59 |
@wiking | sonne|work: ok then you'll fork it | 16:00 |
sonne|work | but hey you did the work so whatever keep it | 16:00 |
@wiking | i strongly disagree with you hence it's up to you what you cherry-pick from the commmits | 16:00 |
sonne|work | wiking: ? | 16:00 |
@wiking | sonne|work: ok then we agree ;) | 16:00 |
@wiking | that we disagree | 16:00 |
@wiking | :> | 16:00 |
@wiking | mmm | 16:01 |
sonne|work | parse error | 16:01 |
@wiking | where? | 16:01 |
sonne|work | I don't understand what you are saying | 16:01 |
@wiking | btw how do you SG_ADD a pthread? | 16:01 |
sonne|work | where do we agree / disagree | 16:01 |
@wiking | pthread_mutex | 16:01 |
sonne|work | don't | 16:02 |
@wiking | ah ok | 16:02 |
@wiking | any enum ? | 16:02 |
@wiking | and (void *) ? | 16:02 |
sonne|work | void* -> impossible | 16:03 |
sonne|work | enum IIRC machine_int_t | 16:03 |
@wiking | sfmt_t* m_sfmt; | 16:03 |
@wiking | as i have this | 16:03 |
@wiking | in the class | 16:03 |
sonne|work | SG_ADD((machine_int_t*) &my_enum,...) | 16:04 |
sonne|work | sfmt* is what? | 16:04 |
sonne|work | wiking: please drop the sfmt_altivec file | 16:05 |
@wiking | sonne|work: well that's an internal struct of the SFMT | 16:05 |
sonne|work | lets just keep the generic and the sse variant | 16:05 |
@wiking | sonne|work: eheh that will take some fair amount of digging :P | 16:05 |
@wiking | sonne|work: to get out altivec from that code | 16:05 |
@wiking | it's quite bundled | 16:05 |
@wiking | but if we never set the HAVE_ALTIVEC macro | 16:05 |
@wiking | as we do right now | 16:05 |
@wiking | then we are on the safe side | 16:06 |
sonne|work | wiking: no - it is just included once | 16:06 |
sonne|work | so just remove the file | 16:06 |
sonne|work | +#if defined(HAVE_ALTIVEC) | 16:06 |
sonne|work | + #include "SFMT-alti.h" | 16:06 |
sonne|work | +#elif defined(HAVE_SSE2) | 16:06 |
sonne|work | + #include "SFMT-sse2.h" | 16:06 |
sonne|work | +#endif | 16:06 |
sonne|work | and remove it from there too | 16:06 |
@wiking | sonne|work: you can commit to this branch as well ;) | 16:06 |
sonne|work | no time | 16:06 |
@wiking | ok so how should i sg_add that sfmt* | 16:06 |
@wiking | ? | 16:06 |
sonne|work | no that cannot work if not derived from SGObject | 16:07 |
@wiking | mmm | 16:07 |
@wiking | but that'll cause troubles with python_modular | 16:07 |
@wiking | or? | 16:07 |
@wiking | or since this is not going to be directly used from modular interfaces | 16:07 |
@wiking | we are good? | 16:08 |
@HeikoS | thoralf: so yes you found a bug | 16:08 |
sonne|work | well in principle we don't need any serialization for the RNG at all | 16:08 |
@HeikoS | I was aware that something in the streaming framework is wrong but this clearly points it out | 16:08 |
sonne|work | since we set the seed anyway | 16:08 |
@HeikoS | in fact, there already occur problems without loading any files | 16:08 |
sonne|work | ohh it would even hurt | 16:08 |
sonne|work | we would then need to set the seed after de-serializing | 16:09 |
sonne|work | wiking: I am rather in favor of not making the object serializable | 16:09 |
thoralf | HeikoS: Okay, thanks. | 16:09 |
@HeikoS | thoralf: I will have a look now and put up an issue on git | 16:10 |
@HeikoS | something I wanted to have fixed for a while, but did not find the time yet | 16:10 |
sonne|work | HeikoS: what is the bug | 16:10 |
@wiking | sonne|work: ok any special thing i should do to disable serialization? | 16:10 |
sonne|work | just remove SG_ADD's | 16:10 |
@wiking | sonne|work: all of them? :) okey | 16:10 |
@HeikoS | sonne|work: streaming features have memory problems: double free an other things | 16:10 |
@HeikoS | currently trying to find out more | 16:11 |
sonne|work | HeikoS: yes I know - but is this the SGVector thing? | 16:11 |
sonne|work | wiking: then please do the initialization in init_shogun | 16:11 |
sonne|work | and then run generator.py again | 16:11 |
sonne|work | and check if you manage to get the same results on *bsd and linux... | 16:12 |
@wiking | ok | 16:12 |
@HeikoS | thoralf: does it currently prevent you from working? | 16:12 |
@HeikoS | sonne|work: not sure what you mean | 16:12 |
shogun-notifier- | shogun: Viktor Gal :feature/PRNG * 4736671 / src/shogun/mathematics/Random.cpp,src/shogun/mathematics/Random.h: https://github.com/shogun-toolbox/shogun/commit/473667152bc96e8bbbe2f1438b997ac918d7897f | 16:12 |
shogun-notifier- | shogun: Add parameters of Random and add HAVE_PTHREAD macro check | 16:12 |
shogun-notifier- | shogun: Viktor Gal :feature/PRNG * 7dd6b47 / src/shogun/mathematics/Random.cpp,src/shogun/mathematics/Random.h: https://github.com/shogun-toolbox/shogun/commit/7dd6b47b92a73cf282135a6a936a060f622e0b12 | 16:12 |
shogun-notifier- | shogun: Make Random unserializable | 16:12 |
thoralf | HeikoS: No, as I've got plenty of work. Yes, as it blocks my shogun experiments. :) | 16:13 |
@HeikoS | thoralf: I mean, a quick hack for now is just to remove the SG_UNREF | 16:14 |
thoralf | HeikoS: Yes, but then it does not free the memory - and my data files are quite big. | 16:15 |
@HeikoS | thoralf: I see | 16:16 |
@HeikoS | thoralf: I will explore and discuss with others, we are definitely interested in having this resolved soon | 16:16 |
@HeikoS | thoralf: just wondering what do you want to do? | 16:16 |
sonne|work | HeikoS: recall that we switched to using SGVector at some point? | 16:16 |
@HeikoS | sonne|work: yes | 16:16 |
sonne|work | HeikoS: the streaming features were written when that stuff did not exist | 16:17 |
sonne|work | so now we have the issue that SGVector auto-frees memory | 16:17 |
@HeikoS | sonne|work: so this still has to be migrated, right, but I think last time I went into this, there were some more problems | 16:17 |
sonne|work | (or ot) | 16:17 |
@HeikoS | sonne|work: should be easy to fix then | 16:17 |
thoralf | HeikoS: Ive got some external svmlight file and try to experiment with different hash kernels (MKL) on this data. | 16:17 |
sonne|work | no it is not an easy fix :/ | 16:17 |
thoralf | HeikoS: And MKL lead me to shogun. | 16:17 |
thoralf | sonne|work: Sounds bad. If you need some assistance, let me know. | 16:18 |
thoralf | sonne|work: I think the bug is easy to track down, since it already happens with a small one-vector-data set. So it would be possible to track the reference counts "by foot". :) | 16:20 |
@HeikoS | thoralf: would you be interested in working on this? :) | 16:22 |
-!- erlenda [~erlenda@fw-oslo.intelcom.no] has quit [Quit: Leaving] | 16:23 | |
shogun-notifier- | shogun: Viktor Gal :feature/PRNG * c204e89 / src/shogun/base/init.cpp,src/shogun/base/init.h: https://github.com/shogun-toolbox/shogun/commit/c204e89ad4828227c7c648bd0d3d5fc4903ebc1e | 16:23 |
shogun-notifier- | shogun: Create a global Random object in init | 16:23 |
thoralf | HeikoS: Damn. I was begging for this, right? ;) | 16:24 |
@wiking | sonne|work: ^ should be like this right? | 16:24 |
thoralf | HeikoS: I'll have a look. | 16:24 |
sonne|work | wiking: yes | 16:24 |
@wiking | ok now it's really only about starting to use this PRNG in shogun ;P | 16:25 |
@HeikoS | thoralf: hehe :) | 16:25 |
sonne|work | wiking: yes just run generator.py | 16:25 |
@HeikoS | thoralf: would be nice if you have time, we are postponing this one for a while now :) let me know if you need any help/questions/answers | 16:26 |
sonne|work | and then rsync this stuff to some *bsd machine and try if it gives the same result | 16:26 |
sonne|work | wiking: and tester.py of course too :) | 16:26 |
@wiking | sonne|work: mmm how to i get reference on that sg_rand ? :) | 16:27 |
sonne|work | wiking: did you add an #extern ? | 16:28 |
sonne|work | extern actually | 16:28 |
@wiking | where? | 16:28 |
sonne|work | wiking: whereever you need it | 16:32 |
sonne|work | I don't know why you need it actually | 16:32 |
sonne|work | you could just use the getter | 16:33 |
@wiking | yep | 16:34 |
@wiking | but i wonder why i cannot SG_UNREF(CRandom*) | 16:34 |
@wiking | /Users/wiking/shogun/src/shogun/mathematics/Math.h:476,4 - Error - member access into incomplete type 'shogun::CRandom' | 16:34 |
sonne|work | I don't have time to look into this right now :/ | 16:35 |
@wiking | ok done | 16:35 |
@wiking | will work now | 16:36 |
@wiking | now it's 'only' rewriting all the functions in CMath | 16:36 |
-!- travis-ci [~travis-ci@ec2-50-16-143-238.compute-1.amazonaws.com] has joined #shogun | 16:43 | |
travis-ci | [travis-ci] it's Viktor Gal'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/6820176 | 16:43 |
-!- travis-ci [~travis-ci@ec2-50-16-143-238.compute-1.amazonaws.com] has left #shogun [] | 16:43 | |
-!- vgorbati [d4029f22@gateway/web/freenode/ip.212.2.159.34] has joined #shogun | 16:46 | |
-!- gsomix_ [~gsomix@95.67.166.72] has joined #shogun | 16:47 | |
-!- van51 [~van51@athedsl-401908.home.otenet.gr] has left #shogun ["QUIT :Leaving."] | 16:49 | |
-!- gsomix [~gsomix@95.67.181.139] has quit [Ping timeout: 264 seconds] | 16:50 | |
-!- KMcQuisten [d8338942@gateway/web/freenode/ip.216.51.137.66] has joined #shogun | 16:58 | |
KMcQuisten | Morning, all | 16:58 |
@HeikoS | KMcQuisten: hi! | 16:58 |
KMcQuisten | Hope all is well | 16:58 |
@wiking | uff why :) | 16:58 |
@HeikoS | Hope for you too! | 16:58 |
KMcQuisten | Why not? | 16:58 |
@HeikoS | about your mail | 16:59 |
@wiking | mmm i was commenting to travis-ci | 16:59 |
KMcQuisten | Oh, ok | 16:59 |
@HeikoS | so this is an issue that the model selection framework has | 16:59 |
@HeikoS | if you wanted to do a search over multiple combined kernels | 16:59 |
-!- Asix3 [~Asix3@d47-69-144-148.nap.wideopenwest.com] has joined #shogun | 16:59 | |
@HeikoS | you would have to create all of them by hand | 16:59 |
@HeikoS | but thats kind of not what you want | 16:59 |
KMcQuisten | Exactly | 16:59 |
@HeikoS | so one thing I dont get is: | 16:59 |
@HeikoS | you do MKL right? so the program selects the subkernel weights for you | 17:00 |
@HeikoS | why do you want to optimise them seperately? | 17:00 |
@HeikoS | I would just throw in all kernels that might be relevant and look at the weights | 17:00 |
@HeikoS | modelselection only necessary for the SVM parameters | 17:00 |
@HeikoS | or am I wrong? | 17:00 |
KMcQuisten | I don't want to optimize the subkernel weights separately. I want to set up specific subkernels and optimize the parameters for those kernels, while still letting the MKL optimize the subkernel weights | 17:01 |
@HeikoS | I see | 17:01 |
@HeikoS | so one thing you could do: | 17:01 |
@HeikoS | say you want to select a Gaussian width | 17:01 |
@HeikoS | just add subkernels with all those widths to the combined kernel | 17:01 |
KMcQuisten | That won't work | 17:01 |
KMcQuisten | Let me explain: | 17:02 |
KMcQuisten | I have two kernels, one for features related to one aspect of my data, and another for different features on the same data | 17:03 |
KMcQuisten | If I just threw all the possible parameterizations for both types of kernels into an MKL, there is no way for me to force it to choose one from each aspect | 17:03 |
-!- _Asix3 [~Asix3@d47-69-144-148.nap.wideopenwest.com] has joined #shogun | 17:03 | |
-!- Asix3 [~Asix3@d47-69-144-148.nap.wideopenwest.com] has quit [Ping timeout: 256 seconds] | 17:03 | |
@HeikoS | KMcQuisten: I see | 17:04 |
KMcQuisten | I want to be able to do a grid search of subkernel parameters | 17:04 |
@HeikoS | KMcQuisten: ok understoof | 17:04 |
@HeikoS | d | 17:04 |
KMcQuisten | while letting the MKL optimize the subkernel weights | 17:04 |
@HeikoS | unfortunately, thats currently not possible | 17:04 |
-!- _Asix3 [~Asix3@d47-69-144-148.nap.wideopenwest.com] has quit [Client Quit] | 17:04 | |
@HeikoS | since model selection does not handle subkernel stuff straight forwardly | 17:04 |
@HeikoS | its not a very big deal to extend it though | 17:05 |
@HeikoS | one more question: | 17:05 |
KMcQuisten | Indeed. I was thinking that there would need to be a CombinedKernel parameter for "subkernel parameters" | 17:05 |
KMcQuisten | Ok | 17:05 |
KMcQuisten | Shoot | 17:05 |
@HeikoS | I mean you can add SG_Objects llike the subkernels as parameters | 17:05 |
@HeikoS | so the other thing is | 17:05 |
@HeikoS | you choose only kernels on feature part A | 17:06 |
@HeikoS | put in all the subkernels | 17:06 |
@HeikoS | use MKL to select parameters | 17:06 |
@HeikoS | or something else | 17:06 |
@HeikoS | then do the same thing for feature part B | 17:06 |
@HeikoS | then use the best one for MKL | 17:06 |
@HeikoS | in fact you can use the existing modsel framework then | 17:06 |
KMcQuisten | Doing that tends to overfit the model and is poor at generalizing. I've tried that. | 17:06 |
@HeikoS | ok | 17:07 |
@HeikoS | well then, we have another item in our issues list :) | 17:07 |
@HeikoS | Interested in working on that btw? | 17:09 |
KMcQuisten | I was thinking about how it could work, and if the CombinedKernel had a parameter that's just called "subkernel", then nodes for each subkernel could be built and added as children to the CombinedKernel node, and it would be rather intuitive. I've not gotten into the guts of the modsel framework to know if that kind of thing would be simple to implement | 17:10 |
@HeikoS | thats exactly how we would do it | 17:10 |
KMcQuisten | I model genetic regulatory pathways, so I use string and numerical kernels together quite a bit. | 17:10 |
@HeikoS | ah I see so even different features | 17:11 |
KMcQuisten | Exactly | 17:11 |
@HeikoS | thats the difficulty with this combined stuff | 17:11 |
@HeikoS | and also the sukernels are stored in a list | 17:11 |
KMcQuisten | I'm interested in looking at tree-based features as well, as there are some natural ways they could apply to some of my work. | 17:12 |
@HeikoS | which is not really registered for modelselection currently | 17:12 |
@HeikoS | I would love to have tree/graph based features in shogun | 17:12 |
@HeikoS | someone would have to code it up :) | 17:13 |
@HeikoS | the modelselection framework currently works like this: | 17:13 |
KMcQuisten | Taht's a project i'd be interested in helping with once my dissertation's done | 17:13 |
@HeikoS | classes register their parameter available | 17:14 |
@HeikoS | then a user builds these trees | 17:14 |
@HeikoS | and shogun computes the tree "products" with all combinations of parameters (that make sense) | 17:14 |
@HeikoS | so we would just have to fit the combined kernel into this framework | 17:14 |
@HeikoS | KMcQuisten: feel free to get back to use thenm | 17:14 |
@HeikoS | I will add an issue on github and think on how to implement this stuff | 17:15 |
KMcQuisten | Indeed. I've used it for single kernel parameter optimization and it's worked great. | 17:15 |
@HeikoS | feel free to add your comments to it, Ill send the link | 17:15 |
@HeikoS | KMcQuisten: yes, thats a thing it can do quite nicely | 17:15 |
KMcQuisten | It's areally well-designed framework | 17:15 |
@HeikoS | thanks! | 17:16 |
KMcQuisten | Thanks so much for looking into this for me. | 17:16 |
@HeikoS | we are currently looking into ways of making the syntax easier | 17:16 |
@HeikoS | in particular from python | 17:16 |
@HeikoS | KMcQuisten: welcome, its always nice to get feedback on things | 17:16 |
@HeikoS | KMcQuisten: btw have you used the nu-svr stuff that I added with that huge delay? | 17:20 |
-!- hoijui [~hoijui@dslb-088-074-121-064.pools.arcor-ip.net] has quit [Quit: Leaving] | 17:21 | |
KMcQuisten | I have. It's been a nice way to look at SVR, and for some reason it's been a bit more intuitive when I've explained how it works to my biologist collegues | 17:21 |
KMcQuisten | I always thought the epsilon tube was perfectly understandable, but they like proportions, it seems. | 17:22 |
KMcQuisten | Thank you | 17:22 |
@HeikoS | I also like it more | 17:24 |
@HeikoS | its a bit slower to optimise though | 17:25 |
shogun-notifier- | shogun: cameron :develop * 8f6de9c / examples/undocumented/python_modular/regression_gaussian_process_modular.py: https://github.com/shogun-toolbox/shogun/commit/8f6de9c14fb4ef232b31d75b1c7e53ab87407812 | 17:26 |
shogun-notifier- | shogun: Changed typo in GP regression from RETURN_TYPE_MEAN to RETURN_TYPE_COV | 17:26 |
shogun-notifier- | shogun: cameron :develop * c381460 / / (135 files): https://github.com/shogun-toolbox/shogun/commit/c3814609396742a2c3fdf19d567d4f89fa3b20cb | 17:26 |
shogun-notifier- | shogun: Merge remote-tracking branch 'shogun/develop' | 17:26 |
shogun-notifier- | shogun: cameron :develop * 7790dd1 / data: https://github.com/shogun-toolbox/shogun/commit/7790dd146bf5e315faba55ff926d9f7e080b5408 | 17:26 |
shogun-notifier- | shogun: Modified submodule for gp regression test results | 17:26 |
shogun-notifier- | shogun: cameron :develop * a33603b / data: https://github.com/shogun-toolbox/shogun/commit/a33603beb5fb35596f8d1309d797c7ee4804431c | 17:26 |
shogun-notifier- | shogun: Updated submodule shogun-data for gp regression tests | 17:26 |
shogun-notifier- | shogun: cameron :develop * 945a7ff / data: https://github.com/shogun-toolbox/shogun/commit/945a7ff7112becba39a32d5a12ad7345fb7734c3 | 17:26 |
shogun-notifier- | shogun: Revert "Updated submodule shogun-data for gp regression tests" | 17:26 |
shogun-notifier- | shogun: | 17:26 |
shogun-notifier- | shogun: This reverts commit a33603beb5fb35596f8d1309d797c7ee4804431c. | 17:26 |
shogun-notifier- | shogun: cameron :develop * e5c8dae / data: https://github.com/shogun-toolbox/shogun/commit/e5c8daed3d5b320929d7d1cff73404a1003bbece | 17:26 |
shogun-notifier- | shogun: Revert "Modified submodule for gp regression test results" | 17:26 |
shogun-notifier- | shogun: | 17:26 |
shogun-notifier- | shogun: This reverts commit 7790dd146bf5e315faba55ff926d9f7e080b5408. | 17:26 |
shogun-notifier- | shogun: cameron :develop * b4e23c6 / data: https://github.com/shogun-toolbox/shogun/commit/b4e23c6f30a1680974688cbd85e89cb53284a473 | 17:26 |
shogun-notifier- | shogun: Update submodule data for gp regression | 17:26 |
shogun-buildbot | build #1083 of deb1 - libshogun is complete: Failure [failed git] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb1%20-%20libshogun/builds/1083 blamelist: cameron <cameronjml2@gmail.com> | 17:28 |
shogun-buildbot | build #1084 of deb1 - libshogun is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb1%20-%20libshogun/builds/1084 | 17:29 |
shogun-buildbot | build #733 of cyg1 - libshogun is complete: Failure [failed configure] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/733 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, cameron <cameronjml2@gmail.com> | 17:30 |
@HeikoS | argh | 17:32 |
@HeikoS | I dont get this | 17:32 |
-!- travis-ci [~travis-ci@ec2-50-16-143-238.compute-1.amazonaws.com] has joined #shogun | 17:33 | |
travis-ci | [travis-ci] it's Viktor Gal'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/6820691 | 17:33 |
-!- travis-ci [~travis-ci@ec2-50-16-143-238.compute-1.amazonaws.com] has left #shogun [] | 17:33 | |
@HeikoS | cameron__: but the version is correct | 17:34 |
@HeikoS | 17627e76436866ae52f35875c8cf41df31571bc2 | 17:34 |
@HeikoS | both in data and shogun/data | 17:34 |
pickle27 | hey guys | 17:34 |
@HeikoS | lisitsyn, sonne|work could you help here? | 17:34 |
@HeikoS | pickle27: hi | 17:34 |
pickle27 | quick question about my GSoC application | 17:34 |
@HeikoS | yes? | 17:34 |
cameron__ | HeikoS: I am quite sure everything was right | 17:35 |
cameron__ | HeikoS: not sure what went wrong this time | 17:35 |
sonne|work | HeikoS: did you git add data? | 17:35 |
sonne|work | in the src | 17:35 |
cameron__ | sonne|work: i did git submodule update | 17:35 |
pickle27 | when I am actually submitting it on the GSoC site should I put the description from the shogun ideas list in the project description? | 17:35 |
shogun-buildbot | build #899 of bsd1 - libshogun is complete: Failure [failed configure] Build details are at http://www.shogun-toolbox.org/buildbot/builders/bsd1%20-%20libshogun/builds/899 blamelist: cameron <cameronjml2@gmail.com> | 17:36 |
cameron__ | sonne|work: then git commit -a -m "comment" | 17:36 |
@HeikoS | sonne|work: the data in src/ is set to the same hash as the head of shogun-data | 17:36 |
shogun-buildbot | build #734 of cyg1 - libshogun is complete: Failure [failed configure] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/734 blamelist: cameron <cameronjml2@gmail.com> | 17:36 |
pickle27 | nvm sort of answered my own question by comparing the character limit | 17:37 |
@HeikoS | pickle27: no dont copy it | 17:38 |
@HeikoS | just your application which mentions which project you want to do | 17:38 |
sonne|work | HeikoS: and you did push data? | 17:40 |
@HeikoS | https://github.com/shogun-toolbox/shogun/commit/abab8b64883c5479ddd3d9a533e38f4f50fc6f16 | 17:41 |
@HeikoS | https://github.com/shogun-toolbox/shogun-data/commit/17627e76436866ae52f35875c8cf41df31571bc2 | 17:41 |
cameron__ | sonne|work: Yes, data was pushed | 17:41 |
sonne|work | HeikoS: maybe you pushed data *after* pushing src | 17:41 |
sonne|work | http://shogun-toolbox.org/buildbot/builders/deb1%20-%20libshogun | 17:41 |
@HeikoS | no | 17:41 |
sonne|work | it looks like it is happy | 17:41 |
@HeikoS | ah | 17:42 |
@HeikoS | cameron__: you had many intermediate commits right? | 17:42 |
cameron__ | HeikoS: yes I reverted the wrong commits I made beore | 17:42 |
sonne|work | cameron__: ahh revert is a new commit | 17:43 |
sonne|work | next time use git reset | 17:43 |
sonne|work | or git commit --amend | 17:43 |
-!- KMcQuisten [d8338942@gateway/web/freenode/ip.216.51.137.66] has quit [Quit: Page closed] | 17:43 | |
cameron__ | sonne|work: okok, sorry for all the mess | 17:44 |
-!- votjakovr [~votjakovr@host-46-241-3-209.bbcustomer.zsttk.net] has joined #shogun | 17:46 | |
@HeikoS | cameron__: no worries, works now, thanks for the patch! | 17:47 |
@HeikoS | now that you know how this works, you can help people wanting to do this :) | 17:48 |
cameron__ | HeikoS: Thanks for all the help! I can now do the unfinished gp regression interactive | 17:48 |
@HeikoS | nice! | 17:48 |
@HeikoS | thank roman for fixing the bug :) | 17:48 |
@HeikoS | votjakovr | 17:48 |
cameron__ | thanks votjakovr | 17:49 |
@HeikoS | sonne|work: any thoughts on modelselection for subkernels? | 17:49 |
votjakovr | It's my pleasure :) | 17:49 |
@HeikoS | sonne|work: maybe this can be added to the model-selection syntax project | 17:54 |
@HeikoS | since people have asked about this a few times | 17:54 |
@wiking | sonne|work: make[1]: *** No rule to make target `../../shogun/SFMT-params.h', needed by `modshogun_wrap.cxx'. Stop. | 17:57 |
@wiking | wtf? | 17:57 |
@wiking | :) | 17:57 |
@wiking | ah shit | 17:57 |
@wiking | lisitsyn: ping | 17:59 |
-!- ErlendA [~ErlendA@cm-84.215.138.251.getinternet.no] has joined #shogun | 18:03 | |
ErlendA | @HeikoS: Did Dan talk to you about exactly how to precondition the methods? | 18:03 |
@HeikoS | ErlendA: hi | 18:04 |
@HeikoS | a little bit | 18:04 |
ErlendA | Good | 18:04 |
@HeikoS | log_det=det_Krylov_preconditioned(Q, P, precomputed, tol, maxiter); | 18:04 |
@HeikoS | log_det=log_det+2*sum(log(diag(P))); | 18:04 |
@HeikoS | to speak in matlab | 18:04 |
@HeikoS | use P to create a better conditioned problem and then correct in the logdet result | 18:05 |
ErlendA | Yes. Exactly, or similarly with a spectral approach | 18:05 |
@HeikoS | ErlendA: so I tried this on a large problem | 18:05 |
@HeikoS | and then discarded it | 18:05 |
@HeikoS | since its slower | 18:05 |
ErlendA | What did you try? | 18:05 |
@HeikoS | applying P all the time causes so much overhead that the gain in the condition number is lost | 18:05 |
@HeikoS | preconditioned vs not preconditioned | 18:06 |
ErlendA | Ahh. But this depends on how the preconditioner is constructed. | 18:06 |
ErlendA | Incomplete cholesky? | 18:06 |
sonne|work | wiking: you need the include path to be relative to /src/ | 18:06 |
@HeikoS | ErlendA: true, so I (we) tried incomplete cholesky | 18:06 |
@HeikoS | did not really do well | 18:06 |
sonne|work | <shogun/foo/bar> | 18:06 |
@HeikoS | jacobi | 18:06 |
thoralf | HeikoS: Please have a look at shogun/lib/SGSparseVector.cpp, method ::copy_data, line "features = ((SGSparseVector*)(&orig))->features;" | 18:06 |
@HeikoS | and block wise jacobi | 18:06 |
thoralf | HeikoS: The reference gets copied to the new vector, so it gets double-freed? | 18:07 |
@wiking | sonne|work: where...? i mean i have no idea where is this coming from | 18:07 |
@HeikoS | ErlendA: but thats on a very specific problem | 18:07 |
@wiking | sonne|work: ok i might have an idea... | 18:07 |
@wiking | :( | 18:07 |
ErlendA | @HeikoS: Yes. But it is important to have the posibility of using it. | 18:08 |
@HeikoS | ErlendA: aggreed! | 18:08 |
@HeikoS | thoralf: which line is this? | 18:08 |
@HeikoS | number? | 18:08 |
sonne|work | wiking: from the includes in the sfmt | 18:08 |
sonne|work | you have to make them all like | 18:08 |
ErlendA | @HeikoS: I tried incomplete cholesky with wavelet sparsification. Then it works quite well for SPDE problems | 18:08 |
shogun-buildbot | build #1032 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/1032 blamelist: cameron <cameronjml2@gmail.com> | 18:08 |
sonne|work | #inlcude <shogun/foo/bar.h> | 18:08 |
@HeikoS | ErlendA: we should talka bout everything soon, we got a very promising guy here | 18:08 |
@HeikoS | ErlendA: nice, so then we should add it | 18:08 |
thoralf | HeikoS: line 114 | 18:09 |
@wiking | sonne|work: yep i got that in the meanwhile :P | 18:09 |
ErlendA | @HeikoS: It's difficult to program it in a way that is general and useful. The gist should be (IMO) that you can use your customized preconditioner, if you happen to have a good one | 18:09 |
@HeikoS | ErlendA: ok, sounds good | 18:10 |
@HeikoS | yes, then we can make it optimal to code the actual preconditioner | 18:10 |
@HeikoS | thoralf: I dont think this is a problem | 18:10 |
ErlendA | @HeikoS: Yes. I think that in the end, that's more useful | 18:11 |
@HeikoS | thoralf: I suspect if you run the code with SGVector instead of sparse vectors, then it will also crash | 18:11 |
@HeikoS | I think it has to do with the way the streaming framework handles vector data | 18:11 |
@HeikoS | ErlendA: looking forward, will be a cool project | 18:11 |
sonne|work | HeikoS: I didn't follow what the issue with subkernels & MS is... | 18:11 |
@HeikoS | sonne|work: imageine you have two kernels that you combine in a combined one | 18:12 |
@HeikoS | now you want to select the parameters of the subkernels | 18:12 |
sonne|work | ok | 18:12 |
thoralf | HeikoS: But since the old vector (including the "features" array) is already freed, this is my suspect #1. | 18:12 |
sonne|work | HeikoS: and? | 18:13 |
@HeikoS | thoralf: ok, maybe then try changing this and see where it brings you? | 18:13 |
@HeikoS | sonne|work: so this is currently not possible with shogun | 18:13 |
@HeikoS | and the modsel framework | 18:13 |
-!- iglesiasg [~nando@s83-179-44-135.cust.tele2.se] has joined #shogun | 18:13 | |
-!- mode/#shogun [+o iglesiasg] by ChanServ | 18:13 | |
sonne|work | HeikoS: because you need to combine each parameter setting of one kernel with the settings of the other right? | 18:14 |
shogun-buildbot | build #1033 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/1033 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, cameron <cameronjml2@gmail.com> | 18:14 |
@HeikoS | sonne|work yes | 18:14 |
@HeikoS | also, the subkernels are not really seperately registered | 18:15 |
@HeikoS | so some work to do there | 18:15 |
@HeikoS | might that fit within the modsel syntax task? | 18:15 |
sonne|work | HeikoS: so best you could do is do various combined kernels ? | 18:15 |
@HeikoS | sonne|work: yes if one creates all combined kernels by hand, one can let shogun do the rest | 18:15 |
@HeikoS | but thats the point, we want to create those combinations automatically | 18:15 |
sonne|work | HeikoS: if we had just 2 fixed kernels it would work right? | 18:16 |
sonne|work | I mean the machine had 2 kernels | 18:17 |
sonne|work | but not a combined one | 18:17 |
@HeikoS | how do you mean that? | 18:17 |
@HeikoS | ah I see | 18:17 |
@HeikoS | yes | 18:17 |
@HeikoS | two combined kernels | 18:17 |
sonne|work | say CKernel a; CKernel b | 18:17 |
@HeikoS | yes or whatever kernel | 18:17 |
sonne|work | yeah | 18:17 |
@HeikoS | this we can do | 18:17 |
sonne|work | I don't see how we could do this in general | 18:18 |
@HeikoS | well | 18:18 |
sonne|work | we only ever thought about Machines for that | 18:18 |
@HeikoS | the combined kernel gets subparameters | 18:18 |
@HeikoS | which are then applied to the subkernels one by one | 18:19 |
sonne|work | ah so each kernel would be a sub-parameter | 18:19 |
@HeikoS | yes something like this | 18:19 |
@HeikoS | problem is its just a list | 18:19 |
@HeikoS | so every element of the list would need a name | 18:19 |
sonne|work | kind of !?!? considering that we can have a dynamic number of sub kernels | 18:19 |
@HeikoS | and then we can give them parameters | 18:19 |
@HeikoS | gets even more complicated when you have different types with different types of subparameters | 18:20 |
sonne|work | HeikoS: yeah but we assumed the parameters to be fixed | 18:20 |
@HeikoS | yes | 18:20 |
sonne|work | this here will add parameters dynamically | 18:20 |
sonne|work | and you might want sometimes 2 kernels sometimes 4 | 18:20 |
@HeikoS | I mean, this would be a kind of hack for combined kernels | 18:20 |
sonne|work | or so | 18:20 |
sonne|work | horrible | 18:20 |
@HeikoS | mmh | 18:21 |
@HeikoS | maybe then instead, we should offer a method that creates a bunch of combined kernels for a user | 18:21 |
sonne|work | I guess we are better of supplying some function to create the cross-product for kernels | 18:21 |
@HeikoS | and then these are passed to the machine one after another | 18:21 |
@HeikoS | exactly | 18:21 |
sonne|work | haha | 18:21 |
@HeikoS | same thought :) | 18:21 |
sonne|work | then it must be the better solution | 18:21 |
sonne|work | also not so difficult | 18:22 |
@HeikoS | so given a list of kernel lists, this one create combined kernels with all the combinations | 18:22 |
sonne|work | yes | 18:22 |
@HeikoS | that sounds reasonable | 18:22 |
@HeikoS | kernel type has to be fixed though since the features must not change | 18:22 |
sonne|work | maybe you could even tell him how to do it | 18:22 |
@HeikoS | but thats fine | 18:22 |
sonne|work | yeah well | 18:22 |
sonne|work | there will always be too complex ways to automate things | 18:23 |
@HeikoS | indeed | 18:23 |
@HeikoS | this one would be good to have though, there was another guy that asked about it a while ago | 18:23 |
sonne|work | so create an issue about it and mention the solution | 18:23 |
@HeikoS | will do | 18:23 |
sonne|work | maybe someone has time... | 18:24 |
-!- vgorbati [d4029f22@gateway/web/freenode/ip.212.2.159.34] has quit [Ping timeout: 245 seconds] | 18:28 | |
-!- abinayam [3d0c137b@gateway/web/freenode/ip.61.12.19.123] has joined #shogun | 18:29 | |
-!- abinayam [3d0c137b@gateway/web/freenode/ip.61.12.19.123] has quit [Client Quit] | 18:32 | |
shogun-notifier- | shogun: Roman Votyakov :develop * 74ac381 / src/NEWS: https://github.com/shogun-toolbox/shogun/commit/74ac38185707411786f53a7f2fdd159a044532ed | 18:32 |
shogun-notifier- | shogun: Updated news | 18:32 |
shogun-notifier- | shogun: Heiko Strathmann :develop * 22eb0a5 / src/NEWS: https://github.com/shogun-toolbox/shogun/commit/22eb0a5e85caae50f861c0cdd12bceef697a6af7 | 18:32 |
shogun-notifier- | shogun: Merge pull request #1041 from votjakovr/develop | 18:33 |
shogun-notifier- | shogun: | 18:33 |
shogun-notifier- | shogun: Updated news | 18:33 |
@HeikoS | sonne|work: whats this proa in the news? :) | 18:35 |
votjakovr | I'd like to ask same question :) | 18:36 |
@wiking | HeikoS: i'm getting [ERROR] assertion CMath::abs(mean1-mean2)<10E-8 failed in file statistics_hsic.cpp line 159 with the new PRNG :) | 18:40 |
@HeikoS | wiking: no surprise :( | 18:40 |
@HeikoS | relax the bound a bit | 18:40 |
@wiking | E-6? | 18:41 |
@HeikoS | I have to change this at some point | 18:41 |
@HeikoS | just try, seed should be fixed | 18:41 |
thoralf | HeikoS: The second reference to the sparse features comes from StreamingSparseFeatures.cpp, line 426. The reference is just copied. So later on, the same "features" pointer can be found in the vector returned by get_vector() as well as the (distinct) current_sgvector. | 18:41 |
@wiking | HeikoS: well seed is fixed ;) | 18:41 |
thoralf | HeikoS: Can you verify this? | 18:41 |
@HeikoS | yes | 18:42 |
@HeikoS | ! | 18:42 |
@HeikoS | ok I see | 18:43 |
@HeikoS | so the current vector is freed | 18:43 |
thoralf | HeikoS: I just SG_MALLOC'ed the array and returned this, so the double-free disappeared. But where to hook for proper deallocation? | 18:43 |
@HeikoS | which effectively deletes the data | 18:43 |
shogun-buildbot | build #900 of bsd1 - libshogun is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/bsd1%20-%20libshogun/builds/900 | 18:44 |
thoralf | HeikoS: Maybe the semantic of get_vector() is just broken by design: What about returning a pointer to the vector? Should fix the problem without need to copy everything all over again. | 18:44 |
@HeikoS | get_vector should just add a reference count to the vector | 18:44 |
thoralf | HeikoS: SG_REF? | 18:45 |
@HeikoS | we have automatic reference counts for copy by value on vectors | 18:45 |
@HeikoS | so as long as you only do copy by value (=), vectors are fine | 18:45 |
@HeikoS | when the counter reaches zero, memory is freed | 18:45 |
@HeikoS | this should be used here | 18:45 |
@HeikoS | then the framework internally deals with the vectors | 18:45 |
@HeikoS | the user also might | 18:45 |
@HeikoS | and once everyone is done it gets deleted | 18:46 |
@HeikoS | counter is decremented once a vector structure is removed from stack | 18:46 |
thoralf | HeikoS: SG_ADD(current_sgvector.features)? | 18:46 |
thoralf | HeikoS: SG_REF(current_sgvector.features)? | 18:46 |
@HeikoS | nono | 18:47 |
@HeikoS | see if you have | 18:47 |
@HeikoS | SGVector a | 18:47 |
@HeikoS | and you do SGVector b=a | 18:47 |
@HeikoS | then it is incremented | 18:47 |
@HeikoS | a and b share the same data | 18:47 |
thoralf | Yes. | 18:47 |
@HeikoS | you if you return a vector | 18:47 |
@HeikoS | counter is incremented | 18:47 |
thoralf | HeikoS: But which do I (we) have to take care about? | 18:49 |
thoralf | HeikoS: Actually there is no explicit reference counting on .features | 18:50 |
@iglesiasg | HeikoS: too many PRs lately | 18:51 |
@iglesiasg | HeikoS: one forgets what's merged and what not :) | 18:51 |
@HeikoS | iglesiasg: indeed :D | 18:51 |
@HeikoS | thoralf: so thats what sonne|work meant when he said the issues are related to the SGVector stuff | 18:51 |
@HeikoS | the framework is from the days before we had the automatic stuff | 18:51 |
@HeikoS | so it takes care of the SGVectors | 18:51 |
@HeikoS | however, it should not | 18:51 |
shogun-notifier- | shogun: Viktor Gal :feature/PRNG * 972c7ea / src/shogun/lib/external/SFMT/ (4 files): https://github.com/shogun-toolbox/shogun/commit/972c7eaaf01491cbb768b9be246caa58a8927b72 | 18:51 |
shogun-notifier- | shogun: SFMT: add corrent shogun path for includes | 18:52 |
shogun-notifier- | shogun: Viktor Gal :feature/PRNG * 9b9866d / src/shogun/mathematics/Random.cpp,src/shogun/mathematics/Random.h: https://github.com/shogun-toolbox/shogun/commit/9b9866d33d17fd74e88473084356231f8793b02c | 18:52 |
shogun-notifier- | shogun: Several changes in Random PRNG API | 18:52 |
shogun-notifier- | shogun: move state check in the lock part to avoid invalid state checks | 18:52 |
shogun-notifier- | shogun: inline reinit() for faster running time | 18:52 |
@HeikoS | no free'ing should happen, since its all done automatically | 18:52 |
shogun-notifier- | shogun: add set/get function for seed | 18:52 |
shogun-notifier- | shogun: add max macros for RAND_32 and RAND_64 | 18:52 |
shogun-notifier- | shogun: Viktor Gal :feature/PRNG * aa75124 / src/shogun/mathematics/Math.h: https://github.com/shogun-toolbox/shogun/commit/aa7512414bce51ba40ef026b832ec893114e5fba | 18:52 |
shogun-notifier- | shogun: Change CMath's PRNG generator | 18:52 |
thoralf | HeikoS: Okay, and which part belongs to "the old stuff"? I guess sg_ref and sg_unref are new? | 18:52 |
shogun-buildbot | build #735 of cyg1 - libshogun is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/735 | 18:53 |
@HeikoS | no SG_REF is for SGObject, so class instances | 18:53 |
@HeikoS | thoralf: the old stuff is | 18:53 |
@HeikoS | having a c-array float64_t* array | 18:53 |
@HeikoS | and a length variable int32_t array_len | 18:53 |
@HeikoS | and then allocate/deallocate array by hand | 18:53 |
@HeikoS | all those pairs can however be replaced by SGVector which does everything | 18:53 |
shogun-buildbot | build #1034 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/1034 blamelist: cameron <cameronjml2@gmail.com> | 18:54 |
@HeikoS | let me find an example .. | 18:54 |
@HeikoS | virtual float32_t dense_dot(const float32_t* vec2, int32_t vec2_len)=0; | 18:56 |
@HeikoS | in StreamingDotFeatures | 18:56 |
@HeikoS | this is how we handled vectors before | 18:56 |
@HeikoS | thoralf: it might be a bit of an overkill for you to solve this | 18:58 |
@HeikoS | its a lot of stuff | 18:58 |
thoralf | HeikoS: But I think we are close. We saw, that we store two references to the same .features *and* we know, that the first instance is created by the CStreamingSparseFeatures constructor and the second by get_vector(). | 19:02 |
thoralf | HeikoS: If I just create a copy of .features just before returning current_sgvector. Will this leak or cleaned up automatically? | 19:03 |
@HeikoS | thoralf: have you valgrinded the program? | 19:03 |
@HeikoS | then you get the line where the double free happens inside the framework | 19:04 |
-!- iglesiasg [~nando@s83-179-44-135.cust.tele2.se] has quit [Quit: leaving] | 19:04 | |
-!- vgorbati [d4029f22@gateway/web/freenode/ip.212.2.159.34] has joined #shogun | 19:04 | |
@lisitsyn | HeikoS: hey | 19:05 |
@lisitsyn | you asked for some help, is it still relevant? | 19:05 |
@HeikoS | lisitsyn: hi! | 19:07 |
@HeikoS | ehm, on what? | 19:07 |
@lisitsyn | I am lazy to read all these things :D | 19:07 |
@HeikoS | thoralf: I would rather change the whole handling of vectors | 19:07 |
@HeikoS | lisitsyn: so streaming features memory errors | 19:07 |
@lisitsyn | but you asked a few hours ago or so | 19:07 |
@HeikoS | is the most recent | 19:07 |
@HeikoS | lisitsyn: ah that was the build, cannot remember | 19:08 |
@HeikoS | SGSparseVector<T> current_sgvector; | 19:08 |
@HeikoS | /// The current example's feature vector as an SGSparseVectorEntry<T>*. | 19:08 |
@HeikoS | SGSparseVectorEntry<T>* current_vector; | 19:08 |
@lisitsyn | alright | 19:08 |
@HeikoS | thoralf: these guys are in SparseStreaming | 19:08 |
shogun-buildbot | build #1035 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/1035 blamelist: Roman Votyakov <votjakovr@gmail.com> | 19:08 |
@HeikoS | and they get freed automatically on destructor call | 19:08 |
thoralf | HeikoS: But thats alright - as long get_vector() is not called. ;) | 19:08 |
@HeikoS | cameron__: btw the python test fails ... | 19:09 |
@HeikoS | thoralf: exactly | 19:09 |
@HeikoS | so get_vector should has to either incremed counter or create a copy | 19:09 |
@HeikoS | maybe we can try to copy? | 19:10 |
@HeikoS | mmmh | 19:10 |
@HeikoS | damn, all the examples/tests are not working, so no way of checking whether this makes things lead | 19:10 |
@HeikoS | leak | 19:10 |
@HeikoS | thoralf: can you check what happens with dense vectors? | 19:11 |
@HeikoS | same issue there? | 19:11 |
@HeikoS | I use this for some kernel hypothesis testing stuff and fixed some things in there | 19:11 |
@HeikoS | might be the same problem | 19:11 |
cameron__ | HeikoS: but they do not fail on my machine | 19:12 |
@HeikoS | cameron__: weird, lets wait a bit, maybe they will start working at some point | 19:13 |
thoralf | HeikoS: CStreamingDenseFeatures seems to work. | 19:13 |
@HeikoS | thoralf: actually now that I think of it, the issues with the dense ones were pretty similar | 19:13 |
@HeikoS | and I somehow managed to solve parts of it (its already a while ago) - so maybe thats a good point to look at | 19:14 |
cameron__ | HeikoS: I got to go , I'll hav a look later. | 19:14 |
@HeikoS | cameron__: ok see you | 19:14 |
thoralf | HeikoS: Found a comment in dense features: /* needed to prevent double free memory errors */ | 19:16 |
@HeikoS | thoralf: ha! these are mine, what did I do there? which line | 19:17 |
thoralf | HeikoS: Related to the get_vector() and current_vector handling :) | 19:17 |
thoralf | StreamingDenseFeatures.cpp, 59 | 19:17 |
thoralf | You just NULL'ed the vector, so it's not getting freed. | 19:17 |
thoralf | Pragmatic solution ;) | 19:18 |
@HeikoS | thoralf: ehm, yes ..... hacks :) | 19:18 |
@HeikoS | not really the way to do it | 19:19 |
@HeikoS | but maybe for now, add a comment that makes sure our thoughts can be reconstructed | 19:20 |
vgorbati | lisitsyn: here? | 19:20 |
@sonney2k | HeikoS, the isssue with this is that it needs a big overhaul - and so quite some time | 19:23 |
@sonney2k | that is why we keep postponing it | 19:23 |
@HeikoS | sonney2k: yes, maybe go with the hack for now and then fix at some point | 19:24 |
@HeikoS | currently is not the time for this | 19:24 |
@HeikoS | too many things already happening for gsoc | 19:24 |
@sonney2k | wiking, how does it look? | 19:24 |
@sonney2k | do tests fail completely now? | 19:24 |
@sonney2k | HeikoS, yeah overload mode | 19:25 |
@HeikoS | yes ... | 19:25 |
-!- gsomix_ is now known as gsomix | 19:26 | |
@sonney2k | lisitsyn, hmmhh how many slots do we minimally need | 19:26 |
@sonney2k | it seems like 9 now... | 19:26 |
@sonney2k | which might be more than we can get | 19:27 |
@sonney2k | lisitsyn, https://help.github.com/articles/duplicating-a-repository | 19:27 |
@sonney2k | is this what we should do for the clone? | 19:27 |
@sonney2k | lisitsyn, any thoughts? should I call this say once per day? | 19:28 |
@sonney2k | cameron__, things fail on the buildbot because it is testing each commit | 19:30 |
@sonney2k | if you last commit is fine it will be happy then | 19:31 |
shogun-notifier- | shogun: Heiko Strathmann :develop * 8bf9583 / src/NEWS: https://github.com/shogun-toolbox/shogun/commit/8bf9583a964ad1c4a8834b8c9a59bf8499c06e73 | 19:33 |
shogun-notifier- | shogun: news update | 19:33 |
shogun-notifier- | shogun: Heiko Strathmann :develop * cec2f66 / src/NEWS: https://github.com/shogun-toolbox/shogun/commit/cec2f66beb322eba6ad5977a6aeb28199bc57951 | 19:33 |
shogun-notifier- | shogun: Merge pull request #1043 from karlnapf/develop | 19:33 |
shogun-notifier- | shogun: | 19:33 |
shogun-notifier- | shogun: news update | 19:33 |
@wiking | sonney2k: ok this is crazy.... when i run generator.py on linux it modifies like 10 files in data | 19:33 |
@wiking | sonney2k: the same on bsd it modifies 20+ files | 19:33 |
@sonney2k | wiking, only? cool! | 19:33 |
@sonney2k | hmhh | 19:34 |
@sonney2k | and there is no more call to rand etc in Math? | 19:34 |
@wiking | mmm ok question | 19:36 |
@wiking | in static inline uint64_t random(uint64_t min_value, uint64_t max_value) | 19:36 |
@wiking | random | 19:36 |
@wiking | call | 19:36 |
-!- vikalp [~chatzilla@115.245.61.191] has joined #shogun | 19:36 | |
@wiking | but i think that actually calls system's random() | 19:36 |
@wiking | not CMath::random | 19:36 |
thoralf | HeikoS: My ideas won't work out. Setting current_sgvector.features to NULL seems to be the best way. | 19:36 |
@HeikoS | thoralf: go ahead then :) | 19:36 |
@HeikoS | can you add a comment in the streaming features issues on github? | 19:37 |
@sonney2k | wiking, haha there you have it! | 19:37 |
thoralf | HeikoS: I can't easily fix the two references to to same data without introducing big leaks. | 19:37 |
@HeikoS | ok | 19:37 |
@HeikoS | its ok for now | 19:37 |
@HeikoS | sonney2k, lisitsyn I will be in Germany over the weekend, so I won't be around in IRC much, let me know if I should do anything via email, Ill try to check at least once a day | 19:38 |
-!- ErlendA [~ErlendA@cm-84.215.138.251.getinternet.no] has quit [Quit: Leaving] | 19:38 | |
shogun-buildbot | build #737 of cyg1 - libshogun is complete: Failure [failed configure] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/737 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com> | 19:39 |
@sonney2k | HeikoS, most important currently is to keep in touch with students somehow and to come up with some close to final candidate list | 19:39 |
@sonney2k | that's it | 19:39 |
@HeikoS | ././configure-1095-2324.o: Permission denied | 19:39 |
@sonney2k | HeikoS, yeah cygwin | 19:39 |
@HeikoS | sonney2k: already doing that | 19:39 |
@sonney2k | I have no clue what's going wrong there | 19:39 |
@HeikoS | ok cool, will do tomorrow | 19:40 |
shogun-buildbot | build #738 of cyg1 - libshogun is complete: Failure [failed configure] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/738 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com> | 19:40 |
@HeikoS | ok then, going home now, see you later! | 19:40 |
@sonney2k | I am not sure I can handle all students applying for the ideas I had | 19:40 |
@HeikoS | sonney2k: yeah seems a lot of work | 19:40 |
@lisitsyn | sonney2k: well you are going to have two right? | 19:40 |
@HeikoS | bye guys! | 19:41 |
@lisitsyn | HeikoS: bye | 19:41 |
thoralf | Bye HeikoS, thanks. | 19:41 |
@sonney2k | lisitsyn, currently it is 3 on the list | 19:41 |
@lisitsyn | sonney2k: I'll take one | 19:41 |
@sonney2k | thoralf, thanks for `fixing' this! | 19:41 |
vikalp | heya.. | 19:41 |
@sonney2k | lisitsyn, ah ok | 19:41 |
@sonney2k | vikalp, hey | 19:42 |
@lisitsyn | sonney2k: just to low your load I mean | 19:42 |
vikalp | hii sonney2k | 19:42 |
-!- HeikoS [~heiko@nat-171-79.internal.eduroam.ucl.ac.uk] has left #shogun [] | 19:42 | |
@sonney2k | lisitsyn, maybe we can get cheng involved too | 19:42 |
@lisitsyn | sonney2k: I hope so | 19:42 |
vikalp | @sonney2k.. i have completed the task of writing general csv writer in C++ | 19:42 |
vikalp | i am about to write my proposal regarding Fast Reading and Writing Project.. | 19:43 |
@sonney2k | vikalp, ahh nice! | 19:43 |
vikalp | i mean..completing it.. | 19:43 |
vikalp | :) | 19:44 |
-!- 45PAAIYF0 [~travis-ci@ec2-50-16-143-238.compute-1.amazonaws.com] has joined #shogun | 19:44 | |
45PAAIYF0 | [travis-ci] it's Viktor Gal'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/6825754 | 19:44 |
-!- 45PAAIYF0 [~travis-ci@ec2-50-16-143-238.compute-1.amazonaws.com] has left #shogun [] | 19:44 | |
@lisitsyn | haha nice nickname | 19:44 |
@lisitsyn | 45PAAIYF0 | 19:44 |
@sonney2k | I thought we were being attacked | 19:44 |
@lisitsyn | hahah | 19:44 |
@sonney2k | lisitsyn, recall the bot last year? | 19:44 |
@lisitsyn | sonney2k: yes I regret you kicked it | 19:45 |
-!- monalisag [6eeaec2c@gateway/web/freenode/ip.110.234.236.44] has joined #shogun | 19:45 | |
@sonney2k | c'mon it was getting nasty ;) | 19:45 |
shogun-buildbot | build #1036 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/1036 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com> | 19:45 |
@lisitsyn | it was quite intelligent! | 19:45 |
shogun-notifier- | shogun: Viktor Gal :feature/PRNG * 28311b0 / src/shogun/mathematics/Math.h: https://github.com/shogun-toolbox/shogun/commit/28311b0ba43d93f9721de4e68efb37e608bd512b | 19:45 |
shogun-notifier- | shogun: Use CMath::random() in all other CMath::random functions | 19:45 |
shogun-notifier- | shogun: Viktor Gal :feature/PRNG * 7f737fa / src/configure: https://github.com/shogun-toolbox/shogun/commit/7f737fa6f3a84c6733e48b81a6d797aaa2543de3 | 19:45 |
shogun-notifier- | shogun: Add -I. into test_mexp() function in configure | 19:45 |
@sonney2k | lisitsyn, what do you think about mirroring? | 19:45 |
@lisitsyn | sonney2k: what? which mirroring? | 19:45 |
@sonney2k | lisitsyn, git! | 19:45 |
@sonney2k | github -> google code | 19:46 |
@lisitsyn | ahh | 19:46 |
@sonney2k | & shogun toolbox | 19:46 |
@lisitsyn | why do we need it? | 19:46 |
@lisitsyn | I never knew | 19:46 |
@lisitsyn | I mean well if github was unreliable | 19:46 |
@sonney2k | lisitsyn, don't rely on one source | 19:46 |
@lisitsyn | but actually git is distributed so even if chinese attack github | 19:46 |
vikalp | @sonney2k.. As I have gone through the task list of project..what all are the necessaries that I need to complete under the timeline? | 19:46 |
@sonney2k | services come and go | 19:46 |
@lisitsyn | we have the same thing on your machine | 19:46 |
@lisitsyn | and on my machine | 19:46 |
@sonney2k | vikalp, well depends on you :) | 19:47 |
@sonney2k | the project can be stretched quite a bit | 19:47 |
@lisitsyn | sonney2k: I'd put a cron on the website server that git pulls and git pushs | 19:47 |
@sonney2k | from lazy programming till super cow powers ;) | 19:47 |
@sonney2k | lisitsyn, yes that is what I was suggesting - I would do it once / day | 19:48 |
@lisitsyn | this is definitely not the manual thing | 19:48 |
vikalp | thats not a problem.. I would love to work on machine learning | 19:48 |
@lisitsyn | well I have an alias | 19:48 |
@lisitsyn | gposg :D | 19:48 |
@lisitsyn | git push origin && git push shogun && git push google | 19:48 |
@wiking | sonney2k: do you know what library_fisher2x3_modular0.txt does | 19:48 |
@wiking | or shoudl contain? | 19:48 |
@wiking | sonney2k: because i dont really think that it depends on any random generator :) | 19:49 |
@sonney2k | wiking, ohh it is some fisher test for some snp stuff | 19:50 |
-!- votjakovr [~votjakovr@host-46-241-3-209.bbcustomer.zsttk.net] has quit [Quit: Leaving] | 19:50 | |
vikalp | So regarding timeline what all should I include in there?.. Can you please elaborate on this..:) | 19:50 |
@wiking | sonney2k: because the diff between the generated file and the one in the data repo is really just this but still of course it fails... | 19:51 |
@wiking | -(F0.09927493384017462 | 19:51 |
@wiking | +(F0.09927493384018027 | 19:51 |
@wiking | -S"\x11\xf7'\x02\x15j\xb9?\x06\xdd\xe3\x95{\xd2\xe7?:?\xbc%Qb\xe2>" | 19:51 |
@wiking | +S"\xa8\xf8'\x02\x15j\xb9?\x06\xdd\xe3\x95{\xd2\xe7?:?\xbc%Qb\xe2>" | 19:51 |
@sonney2k | wiking, so I guess exp() and whatever are different | 19:52 |
* sonney2k is scared | 19:52 | |
@wiking | i dont know | 19:52 |
@wiking | but this has of course nothing to do with | 19:52 |
@wiking | rng :( | 19:52 |
@sonney2k | true | 19:52 |
@wiking | and i'm afraid same goes for kernel_log_modular0.txt | 19:53 |
@wiking | and the others | 19:53 |
@sonney2k | wiking, ohh do you have long double? | 19:53 |
@sonney2k | I mean long double is 128bit on some archs | 19:54 |
@sonney2k | and on some 96 | 19:54 |
@wiking | where should i check what | 19:54 |
@sonney2k | sizeof(long double) | 19:54 |
@sonney2k | anyway it seems we have to rething the comparison strategy | 19:55 |
@sonney2k | rethink | 19:55 |
@wiking | sonney2k: 16 | 19:55 |
vikalp | sonney2k, So regarding timeline what all should I include in there?.. Can you please elaborate on this..:) | 19:56 |
@sonney2k | vikalp, what you think you can do | 19:56 |
@sonney2k | *reasonably* | 19:56 |
@sonney2k | there is always room for doing a little less /m ore | 19:56 |
@sonney2k | or maybe even continue in the future | 19:56 |
vikalp | sonney2k, well m planning to continue it | 19:57 |
-!- vgorbati [d4029f22@gateway/web/freenode/ip.212.2.159.34] has quit [Ping timeout: 245 seconds] | 19:57 | |
-!- monalisag [6eeaec2c@gateway/web/freenode/ip.110.234.236.44] has quit [Ping timeout: 245 seconds] | 19:58 | |
vikalp | sonney2k, so I will be sending you my proposal for your reviews in couple of hours.. | 19:58 |
mikhailBelous | I fixed my proposal. | 19:59 |
-!- vikalp [~chatzilla@115.245.61.191] has quit [Quit: ChatZilla 0.9.90 [Firefox 11.0/20120312181643]] | 20:00 | |
-!- monalisag [6eeaec2c@gateway/web/freenode/ip.110.234.236.44] has joined #shogun | 20:01 | |
thoralf | Bye guys. Happy hacking. | 20:03 |
-!- thoralf [~thoralf@enki.zib.de] has left #shogun ["Konversation terminated!"] | 20:03 | |
-!- mikhailBelous [~quassel@37.98.242.99] has quit [Remote host closed the connection] | 20:08 | |
shogun-buildbot | build #1037 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/1037 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com> | 20:08 |
@wiking | sonney2k: this is not helping at all.... | 20:10 |
@wiking | i mean the new PRNG | 20:11 |
@sonney2k | wiking, wait - it did get a bit better right? | 20:14 |
@sonney2k | I mean now the random stuff gives the same result or? | 20:14 |
@wiking | sonney2k: well i'll check | 20:15 |
@wiking | i'll now regenerate on linux | 20:15 |
@wiking | and copy it to osx | 20:15 |
@wiking | and check whether some at least got better or not | 20:15 |
@sonney2k | wiking, some should have gotten better | 20:15 |
@sonney2k | lisitsyn, git mirror to shogun toolbox works | 20:17 |
@sonney2k | but not to code.google | 20:17 |
@sonney2k | no idea why not | 20:17 |
@lisitsyn | ehmm | 20:17 |
@sonney2k | error: unable to push to unqualified destination: HEAD | 20:18 |
@sonney2k | The destination refspec neither matches an existing ref on the remote nor | 20:18 |
@sonney2k | begins with refs/, and we are unable to guess a prefix based on the source ref. | 20:18 |
@sonney2k | fatal: The remote end hung up unexpectedly | 20:18 |
@sonney2k | wtf?? | 20:18 |
@wiking | yep | 20:18 |
@lisitsyn | never seen that madness | 20:18 |
@wiking | is it by github? | 20:18 |
-!- pickle27 [~kevin@rcv3-lab-pc.ee.queensu.ca] has quit [Quit: Leaving] | 20:19 | |
@sonney2k | wiking, no code.google.com | 20:19 |
@sonney2k | crazy! | 20:24 |
@sonney2k | it works from my notebook | 20:25 |
@sonney2k | but not from our server | 20:25 |
@wiking | sonney2k: | 20:25 |
@wiking | sonney2k: 2 of all failed examples are not failing anymore :D | 20:25 |
@sonney2k | wiking, hurray! | 20:25 |
@sonney2k | wiking, so how many are left? | 20:26 |
@wiking | about 30 | 20:26 |
@wiking | but of course the new PRNG introduced fails in tests | 20:26 |
@wiking | :D | 20:26 |
@wiking | soooo fuck this shit | 20:26 |
@sonney2k | wiking, no no it is the way to go(tm) | 20:28 |
@sonney2k | hey yeah works now | 20:28 |
@sonney2k | with newer version of git | 20:28 |
gsomix | sonney2k, wiking: hey, can we add bot for building python_modular with python3 bindings? | 20:29 |
@sonney2k | gsomix, I don't have a python3 aware system | 20:30 |
@sonney2k | wiking, do you? | 20:30 |
@sonney2k | lisitsyn, so we have a mirror now! | 20:30 |
@sonney2k | gtg | 20:31 |
@sonney2k | cu | 20:31 |
-!- monalisag [6eeaec2c@gateway/web/freenode/ip.110.234.236.44] has quit [Ping timeout: 245 seconds] | 20:32 | |
shogun-buildbot | build #1038 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/1038 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com> | 20:36 |
-!- travis-ci [~travis-ci@ec2-50-16-143-238.compute-1.amazonaws.com] has joined #shogun | 20:39 | |
travis-ci | [travis-ci] it's Viktor Gal'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/6827204 | 20:39 |
-!- travis-ci [~travis-ci@ec2-50-16-143-238.compute-1.amazonaws.com] has left #shogun [] | 20:39 | |
-!- vgorbati [d4029f22@gateway/web/freenode/ip.212.2.159.34] has joined #shogun | 20:40 | |
vgorbati | lisitsyn: here? | 20:48 |
@lisitsyn | vgorbati: yes | 20:48 |
vgorbati | lisitsyn: I am thinking of implementation of manifold sculpting. Should I create a SparseMatrix of local distances to neighbors from distance object, or should just pass the distance object inside the actual implementation of the method? | 20:50 |
@lisitsyn | vgorbati: it depends how many times it is going to be used | 20:51 |
vgorbati | lisitsyn: you mean whether it will compute the same distances over and over again? | 20:51 |
@lisitsyn | I mean if it is used on each iteration it is worth to compute and store | 20:51 |
@lisitsyn | yes | 20:51 |
vgorbati | lisitsyn: I thought that the distance object performs some caching | 20:52 |
-!- iglesiasg [~nando@s83-179-44-135.cust.tele2.se] has joined #shogun | 20:53 | |
-!- mode/#shogun [+o iglesiasg] by ChanServ | 20:53 | |
@lisitsyn | vgorbati: it might but I would not rely on that in general case | 20:53 |
-!- makokal [~bokal@212.201.44.247] has joined #shogun | 20:53 | |
vgorbati | lisitsyn: agree | 20:53 |
vgorbati | lisitsyn: ok, then I will use the SparseMatrix. Should I put the method that gets SparseMatrix of distances to neighbors from distance object into the locally_linear.hpp? | 20:55 |
@lisitsyn | vgorbati: no it is not related to LLE I think | 20:55 |
@lisitsyn | just put it to routines/manifold_sculpting.hpp for now | 20:55 |
@lisitsyn | it is not used anywhere more | 20:56 |
vgorbati | lisitsyn: ok. Then I can (to make an 'embedManifoldSculpting' method more clear) pass in the distance object, and get the SparseMatrix from it inside the actual implementation function, what do you think? | 20:57 |
@lisitsyn | yes sure | 20:57 |
vgorbati | lisitsyn: ok, thanks | 20:58 |
gsomix | "so, we need a crane to lift another crane from a trench! wait... oh shi~" http://ic.pics.livejournal.com/human_oid/15606149/504066/504066_original.jpg | 20:58 |
gsomix | happy day of workers | 20:58 |
-!- van51 [~van51@athedsl-401908.home.otenet.gr] has joined #shogun | 21:04 | |
van51 | hey all | 21:06 |
van51 | quick question, do I have to include a cv in the GSoC proposal? | 21:07 |
@iglesiasg | van51: no need I think, but feel free if you'd like to | 21:07 |
@lisitsyn | van51: you don't have to | 21:07 |
van51 | ok, thanks! | 21:08 |
@sonney2k | lisitsyn, I am pretty pleased with the 28 we have now... | 21:21 |
@lisitsyn | sonney2k: 28 already? | 21:21 |
@lisitsyn | ohh | 21:21 |
@sonney2k | considering that we had almost 20 on the last day last year | 21:21 |
@sonney2k | so maybe we get a handful more | 21:22 |
@sonney2k | but it is not such a drastic decrease then... already ~60% of what we had last year | 21:22 |
@lisitsyn | we will get a few more I think | 21:27 |
@sonney2k | I should write some blog post about this ride again | 21:28 |
-!- vgorbati [d4029f22@gateway/web/freenode/ip.212.2.159.34] has quit [Ping timeout: 245 seconds] | 21:42 | |
van51 | I just submitted my proposal. Please let me know if you think I should change/clarify something :) | 22:10 |
@lisitsyn | van51: looks pretty ok | 22:21 |
van51 | lisitsyn: cool, thanks for taking the time to read it | 22:22 |
@lisitsyn | van51: you are the 29th submitted :) | 22:22 |
van51 | hehe should have waited a bit more, to have it rounded | 22:23 |
@lisitsyn | may be I should apply by myself as I am eligible to be a gsoc student haha | 22:23 |
van51 | naah it won't be a challenge for you | 22:25 |
van51 | and i'm not saying that because i want a spot :P | 22:25 |
@lisitsyn | haha | 22:25 |
@lisitsyn | mentor: me | 22:25 |
van51 | like some actors who write,direct and star in their movies | 22:28 |
van51 | you will propose,mentor and implement your proposal | 22:28 |
@lisitsyn | sounds like 'google, just give me money' | 22:29 |
@lisitsyn | :D | 22:29 |
van51 | yea | 22:29 |
van51 | in a more polite way | 22:29 |
van51 | I'm off for today | 22:38 |
van51 | cya | 22:38 |
@lisitsyn | see you | 22:38 |
-!- van51 [~van51@athedsl-401908.home.otenet.gr] has quit [Quit: Leaving.] | 22:38 | |
-!- wencan [~wencan@c-71-61-182-121.hsd1.pa.comcast.net] has quit [Remote host closed the connection] | 22:40 | |
-!- iglesiasg [~nando@s83-179-44-135.cust.tele2.se] has quit [Quit: leaving] | 22:40 | |
-!- iglesiasg [~nando@s83-179-44-135.cust.tele2.se] has joined #shogun | 22:42 | |
-!- mode/#shogun [+o iglesiasg] by ChanServ | 22:42 | |
-!- makokal [~bokal@212.201.44.247] has quit [Read error: Connection reset by peer] | 22:42 | |
-!- makokal [~bokal@212.201.44.247] has joined #shogun | 22:43 | |
-!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout] | 22:45 | |
-!- makokal [~bokal@212.201.44.247] has quit [Quit: makokal] | 22:49 | |
@sonney2k | wiking, poing? | 22:51 |
@sonney2k | still there? | 22:51 |
-!- makokal [~bokal@pD9EF09DC.dip0.t-ipconnect.de] has joined #shogun | 23:22 | |
-!- cameron__ [~quassel@global-2-11.nat.csx.cam.ac.uk] has quit [Ping timeout: 252 seconds] | 23:33 | |
-!- cameron__ [~quassel@global-2-11.nat.csx.cam.ac.uk] has joined #shogun | 23:40 | |
cameron__ | cameronjml2 | 23:44 |
-!- cameron__ [~quassel@global-2-11.nat.csx.cam.ac.uk] has quit [Remote host closed the connection] | 23:44 | |
@wiking | sonney2k: pong | 23:53 |
--- Log closed Fri May 03 00:00:30 2013 |
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!