| --- Log opened Mon Jul 08 00:00:22 2013 | ||
| @sonney2k | van51, so all the code is kind of in there and just needs some tweaks to work with shogun | 00:00 |
|---|---|---|
| van51 | sonney2k: ok, nice | 00:01 |
| van51 | sonney2k: I'll start it this week | 00:01 |
| van51 | sonney2k: sent first PR | 00:06 |
| shogun-notifier- | shogun: van51 :develop * cb3d559 / / (3 files): https://github.com/shogun-toolbox/shogun/commit/cb3d5597de313f1d6c33afe8594de68157707b45 | 00:15 |
| shogun-notifier- | shogun: Added support for normalization in HashedDocDotfetures | 00:15 |
| shogun-notifier- | shogun: Soeren Sonnenburg :develop * 34c2f9c / / (3 files): https://github.com/shogun-toolbox/shogun/commit/34c2f9c09e6a1e73d0b5a010be2283c7008760e2 | 00:15 |
| shogun-notifier- | shogun: Merge pull request #1215 from van51/feature/hashing | 00:15 |
| shogun-notifier- | shogun: | 00:15 |
| shogun-notifier- | shogun: Added support for normalization in HashedDocDotfetures | 00:15 |
| shogun-buildbot | build #1209 of bsd1 - libshogun is complete: Failure [failed test] Build details are at http://www.shogun-toolbox.org/buildbot/builders/bsd1%20-%20libshogun/builds/1209 blamelist: Soeren Sonnenburg <sonne@debian.org> | 00:31 |
| @sonney2k | van51, ok that one is merged | 00:37 |
| @sonney2k | van51, btw I realized that your DelimiterTokenizer skipping over multiple e.g. spaces might be a good thing when reading e.g space delimited files | 00:39 |
| @sonney2k | van51, if it is not too hard it would be nice to bring this back as an option | 00:39 |
| van51 | sonney2k: that was what I had in mind | 00:40 |
| van51 | sonney2k: yeah it shouldn't be hard | 00:40 |
| van51 | sonney2k: I'm solving some compiler complaints now and I'll push later on | 00:40 |
| @sonney2k | van51, so for text based stuff I think n-grams are the best there is anyway, some people like to use n-words or so too. So that might be the only other tokenizer I can currently think of (except for some very sophisticated ones using stemming etc we shouldn't do without some use case) | 00:41 |
| @sonney2k | anyway later I better sleep now | 00:43 |
| @sonney2k | cu | 00:43 |
| shogun-buildbot | build #1210 of bsd1 - libshogun is complete: Failure [failed test] Build details are at http://www.shogun-toolbox.org/buildbot/builders/bsd1%20-%20libshogun/builds/1210 blamelist: van51 <vangelis_51@hotmail.com> | 00:43 |
| -!- van51 [~van51@athedsl-408350.home.otenet.gr] has quit [Ping timeout: 246 seconds] | 00:45 | |
| -!- van51 [~van51@athedsl-399972.home.otenet.gr] has joined #shogun | 00:54 | |
| -!- nube [~rho@49.244.40.228] has joined #shogun | 00:54 | |
| van51 | sonney2k: my connection decided to take a break | 00:56 |
| van51 | sonney2k: yea n-words sounds reasonable to have as well and it shouldn't be too hard | 00:56 |
| van51 | sonney2k: just an extension of DelimiterTokenizer | 00:56 |
| van51 | I'll see it from tomorrow | 00:56 |
| shogun-buildbot | build #1331 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/1331 blamelist: Soeren Sonnenburg <sonne@debian.org> | 01:12 |
| shogun-buildbot | build #1332 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/1332 blamelist: van51 <vangelis_51@hotmail.com> | 01:36 |
| -!- foulwall [~user@2001:da8:215:6100:851a:56a4:fbd1:1de6] has joined #shogun | 02:57 | |
| @iglesiasg | hushell, hi there! | 03:03 |
| @iglesiasg | hushell, everything going good with the factor graph? | 03:04 |
| -!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout] | 03:15 | |
| -!- van51 [~van51@athedsl-399972.home.otenet.gr] has quit [Quit: Leaving.] | 03:27 | |
| -!- nube [~rho@49.244.40.228] has quit [Quit: Leaving.] | 03:55 | |
| shogun-buildbot | build #451 of nightly_default is complete: Failure [failed test] Build details are at http://www.shogun-toolbox.org/buildbot/builders/nightly_default/builds/451 | 04:12 |
| hushell | iglesiasg: hi iglesiasg | 04:32 |
| @iglesiasg | hello hello :) | 04:33 |
| hushell | There are more work than my imagination :( | 04:33 |
| hushell | I am still working on it | 04:33 |
| hushell | finishing it in few hours | 04:33 |
| @iglesiasg | that sounds pretty good then! | 04:33 |
| hushell | okay, talk you later | 04:34 |
| @iglesiasg | see you | 04:34 |
| -!- iglesiasg [~nando@s83-179-44-135.cust.tele2.se] has quit [Quit: Ex-Chat] | 04:52 | |
| -!- foulwall [~user@2001:da8:215:6100:851a:56a4:fbd1:1de6] has quit [Ping timeout: 245 seconds] | 05:38 | |
| -!- FSCV [~FSCV@189.139.208.117] has quit [Quit: Leaving] | 06:57 | |
| -!- hushell [~hushell@c-24-21-141-32.hsd1.or.comcast.net] has quit [Ping timeout: 268 seconds] | 07:20 | |
| -!- votjakovr [~votjakovr@host-46-241-3-209.bbcustomer.zsttk.net] has joined #shogun | 07:22 | |
| -!- nube [~rho@116.90.239.13] has joined #shogun | 07:45 | |
| gsomix | sonney2k, hello. I have started work on csv reader and write some stuff for van51. cu at evening, I'll send PR. | 07:50 |
| gsomix | need to go now | 07:50 |
| -!- foulwall [~user@2001:da8:215:c252:9dcb:c7a6:35c0:77ac] has joined #shogun | 08:25 | |
| foulwall | ping sonney2k | 08:26 |
| @sonney2k | foulwall, hey there! | 08:27 |
| @sonney2k | gsomix, go go! | 08:27 |
| foulwall | Hi sonney2k , could I use CNormOne to normalize the features? and I don't exactly know the mechanism in that. | 08:32 |
| foulwall | Ah, I got preprocessor_norm_one_modular.py from /examples, I'll have a try. | 08:39 |
| @sonney2k | foulwall, sorry for what? | 08:40 |
| foulwall | sonney2k: the domain of features are not fixed to [0, 1] since the data importer, so I need to normalize it | 08:42 |
| @sonney2k | I still don't understand | 08:42 |
| @sonney2k | if the domain is not 0..1 why not keep it? | 08:42 |
| foulwall | since some features in australian.libsvm.h5 are out of domain. | 08:43 |
| @sonney2k | foulwall, coudn't you then just display the real feature range? | 08:44 |
| @sonney2k | I would prefer to keep the data as is | 08:44 |
| @sonney2k | foulwall, oki gtg brb | 08:45 |
| foulwall | sonney2k: cu | 08:46 |
| -!- sonne|work [~sonnenbu@91-64-72-127-dynip.superkabel.de] has joined #shogun | 08:57 | |
| sonne|work | foulwall: back | 08:57 |
| -!- foulwall [~user@2001:da8:215:c252:9dcb:c7a6:35c0:77ac] has quit [Ping timeout: 245 seconds] | 08:58 | |
| -!- foulwall [~user@2001:da8:215:6100:2d48:68e4:4af2:4837] has joined #shogun | 09:10 | |
| sonne|work | foulwall: ok? | 09:11 |
| foulwall | Hi sonne|work , I think we can do regress/classification/etc in [0,1] and display in its original domain? or just as you said do them in original domain and display | 09:13 |
| sonne|work | foulwall: yeah display in its original domain and for now don't care about normalization. We can add a tab later allowing people to select how to normalize the data | 09:15 |
| -!- hushell [~hushell@c-24-21-141-32.hsd1.or.comcast.net] has joined #shogun | 09:15 | |
| foulwall | ok, gotcha! | 09:16 |
| hushell | sonney2k: CDynamicArray cannot store CInheritedClass* type, which is subclass of CSGObject? | 10:01 |
| hushell | sonney2k: I got an error like this: /DynamicArray.h:625:4: error: invalid conversion from 'shogun::CFactorDataSource***' to 'shogun::CSGObject***' | 10:03 |
| hushell | sonney2k: Now I add (CSGObject***) to DynamicArray.h:625, i.e. m_parameters->add_vector((CSGObject***)&m_array.array . Is this the right way? | 10:13 |
| sonne|work | hushell: did you use DynamicObjectArray? | 10:33 |
| sonne|work | hushell: I need more context... | 10:34 |
| -!- iglesiasg [~Fernando@s83-179-44-135.cust.tele2.se] has joined #shogun | 10:38 | |
| -!- mode/#shogun [+o iglesiasg] by ChanServ | 10:39 | |
| -!- iglesiasg [~Fernando@s83-179-44-135.cust.tele2.se] has quit [Client Quit] | 10:39 | |
| -!- iglesiasg [~Fernando@s83-179-44-135.cust.tele2.se] has joined #shogun | 10:40 | |
| -!- mode/#shogun [+o iglesiasg] by ChanServ | 10:40 | |
| hushell | sonne|work: no, I am using DynamicArray<CFactor*> to store a set of factors, which has to be dynamically increasing, and CFactor is an inherited class from CSGObject | 10:48 |
| sonne|work | hushell: then please use CDynamicObjectArray for that | 10:49 |
| hushell | sonne|work: DynamicObjectArray is not a template class | 10:49 |
| hushell | I need to explicitly specify | 10:49 |
| sonne|work | hushell: why? | 10:49 |
| sonne|work | CDynamicArray won't work with serialization | 10:50 |
| hushell | I have 2 such kind array, I mean in this way the definitions are clearer | 10:50 |
| hushell | now I am doing like this: CDynamicArray<CFactor*> m_factors; | 10:51 |
| hushell | // Data source objects if data is shared among multiple factors | 10:51 |
| hushell | CDynamicArray<CFactorDataSource*> m_datasources; | 10:51 |
| sonne|work | hushell: CDynamicArray is not intended for SGObjects's - I know you have to use casts with DynamicObjectArray but you should rather use that | 10:52 |
| hushell | sonne|work: CDynamicObjectArray is the only way? how about DynArray? | 10:55 |
| sonne|work | no | 10:55 |
| sonne|work | the only way if you want serialization | 10:55 |
| hushell | sonne|work: okay, then in deconstructor, do I need to call SG_UNREF for each element in DynamicObjectArray? | 10:57 |
| hushell | if each element is a pointer | 10:57 |
| sonne|work | no | 10:57 |
| sonne|work | it is made for SGObjects | 10:57 |
| sonne|work | so it will do REF/UNREF automatically | 10:57 |
| hushell | okay, got it | 10:57 |
| hushell | I am curious where the REF is set | 10:58 |
| hushell | SG_UNREF only let pointer to NULL, where the free operation being taken? | 11:00 |
| hushell | the question may be quite silly :) | 11:00 |
| sonne|work | hushell: in SGObject's unref() call | 11:03 |
| -!- HeikoS [~heiko@nat-166-97.internal.eduroam.ucl.ac.uk] has joined #shogun | 11:07 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 11:07 | |
| hushell | sonne|work: Thanks! not be used to without delete | 11:08 |
| sonne|work | hushell: sorry what? it is calling delete in SGObject once the refcount reaches 0 | 11:08 |
| hushell | sonne|work: I mean when coding, I don't need to delete for myself :) | 11:11 |
| sonne|work | hushell: only call SG_UNREF for SGObject derived object's yes | 11:13 |
| @HeikoS | votjakovr: hi! | 11:14 |
| @iglesiasg | hushell: I used this DynamicObjectArray in the PrimalMosekSOSVM, take a look if you want to see how to use its API | 11:14 |
| @iglesiasg | hushell: IIRC I spent a bit of time debugging until I got it working fine without leaks and so | 11:15 |
| votjakovr | HeikoS: hi! | 11:17 |
| hushell | iglesiasg: yours is the best reference :) | 11:19 |
| hushell | but shall I use CDynamicObjectArray or CDynamicObjectArray& for a return type? | 11:19 |
| @HeikoS | votjakovr: still no PR, how are things with that? | 11:21 |
| @HeikoS | votjakovr: we have to be careful not to fall behind in schedule | 11:21 |
| @iglesiasg | hushell: let me check a moment | 11:21 |
| hushell | Is not allow to use std::vector, right? | 11:22 |
| @HeikoS | hushell: try to avoid this for class members | 11:22 |
| @iglesiasg | hushell: internally it is fine | 11:23 |
| hushell | but my case is members, okay let me make CDynamicObjectArray works | 11:24 |
| @HeikoS | hushell: what objects do you want to put inside? | 11:24 |
| @iglesiasg | hushell: I don't returning a CDynamicObjectArray would entail much overhead (it would copy a few numbers and a pointer, but not the whole array) | 11:24 |
| @iglesiasg | I don't think* | 11:24 |
| @HeikoS | iglesiasg: yeah thats pretty fine | 11:24 |
| @HeikoS | hushell: CDynamicObjectArray is only for shogun class instances | 11:25 |
| votjakovr | HeikoS: ah, sorry, now i'm fixing docs, implementing p(y*|y)... it's the base of future work, then things will be much quicker | 11:25 |
| @HeikoS | otherwise DynamicArray or DynArray | 11:25 |
| hushell | I remember last time I got similar question for SGVector, but both case work well | 11:25 |
| @HeikoS | votjakovr: so what about the numerical integration for p(y*|y) ? | 11:25 |
| hushell | HeikoS: i.e. CDynamicObjectArray also works for derived classes ? | 11:26 |
| @HeikoS | hushell: yes | 11:28 |
| @HeikoS | hushell: also it can do reference counting | 11:28 |
| @HeikoS | hushell: you have to be a bit careful about that, there is a boolean flag that you can set | 11:28 |
| @HeikoS | its useful if you put objects into the array and then they ger all unrefed when the array is deleted | 11:29 |
| @HeikoS | so no need to delete the elements by hand | 11:29 |
| votjakovr | HeikoS: in process... i created class-wrapper for functions of one variable, is it ok? | 11:29 |
| @HeikoS | but also if you dont want that to happen, you can turn it off | 11:29 |
| @HeikoS | votjakovr: a new class? or in CStatistics (where I think it would be fine) | 11:29 |
| votjakovr | HeikoS: with overloaded operator () | 11:29 |
| @HeikoS | votjakovr: ehm, explain that :) | 11:29 |
| -!- vgorbati [c3ee5cb1@gateway/web/freenode/ip.195.238.92.177] has joined #shogun | 11:31 | |
| votjakovr | HeikoS: we need to integrate function of one variable, i created class IntegrableFunction with virtual float64_t operator() (float64_t x)=0;, which return f(x) | 11:32 |
| @HeikoS | votjakovr: I like that! does it work already? | 11:33 |
| hushell | HeikoS: Thanks! It make sense :) | 11:33 |
| votjakovr | HeikoS: not yet, but in progress... | 11:33 |
| @HeikoS | votjakovr: ok, so what is missing for the PR? | 11:34 |
| votjakovr | HeikoS: should it be in Statistics? | 11:34 |
| @HeikoS | votjakovr: I would have put the implementation into CStatistics as a function rather than having a new class, so only the Gauss-blabla method, but yours should be in mathematics folder then | 11:35 |
| -!- zxtx_ is now known as zxtx | 11:36 | |
| hushell | How do I register a CDynamicObjectArray member? use SG_ADD((CSGObject**)...) or add_vector()/ | 11:37 |
| @HeikoS | hushell: the first, with a cast | 11:38 |
| -!- vgorbati [c3ee5cb1@gateway/web/freenode/ip.195.238.92.177] has quit [Quit: Page closed] | 11:38 | |
| hushell | HeikoS: but it indeed a vector | 11:38 |
| votjakovr | HeikoS: ok, for the probit: fix docs + implement evaluate_log_probability for all likelihoods + implement get_probabilities() in GPC class + test - this will be very quickly | 11:38 |
| @HeikoS | hushell: well no, it is a dynamically growing complex structure | 11:38 |
| hushell | HeikoS: okay, Thanks! | 11:39 |
| @HeikoS | votjakovr: ok, sounds good, keep on then! | 11:39 |
| @iglesiasg | sonne|work, HeikoS, lisitsyn: did you have a look to the performance comparison in http://jmlr.org/papers/volume14/curtin13a/curtin13a.pdf? | 11:40 |
| @HeikoS | iglesiasg: yes, we had a little discussion about that | 11:41 |
| @iglesiasg | I wonder, if I believe that our kNN is much faster (using the cover tree) than what they state there, is it ok to run experiments on our own and contact them? | 11:41 |
| @iglesiasg | I find it sort of lying, but no idea if this is a common case in research :) | 11:41 |
| @HeikoS | iglesiasg: While I agree, I am not sure whether this is worth it | 11:42 |
| sonne|work | iglesiasg: that was IIRC an old implementation of KNN before you did the covertree | 11:43 |
| -!- lambday [67157d37@gateway/web/freenode/ip.103.21.125.55] has joined #shogun | 11:43 | |
| sonne|work | iglesiasg: naywhayare is the author of mlpack (here in the channel btw) | 11:43 |
| lambday | HeikoS: hi | 11:43 |
| sonne|work | lambday: hey there ! | 11:43 |
| lambday | sonne|work: hi | 11:43 |
| @HeikoS | maybe tell them | 11:43 |
| sonne|work | lambday: moin moin | 11:43 |
| @iglesiasg | sonney2k: but the paper is from 2013 | 11:43 |
| @HeikoS | lambday: hey! | 11:43 |
| lambday | moin moin :) | 11:43 |
| sonne|work | iglesiasg, HeikoS naywhayare knows | 11:43 |
| @iglesiasg | naywhayare: morning! | 11:44 |
| sonne|work | lambday: exactly :) | 11:44 |
| lambday | HeikoS: number of allocations for SG was way too higher, but for the sparse matrix I initially had, total number of bytes allocated was smaller for SG | 11:44 |
| sonne|work | HeikoS: can you provide a more reasonable sparse amtrix? | 11:44 |
| sonne|work | HeikoS, lambday: why do you care at all? | 11:44 |
| @HeikoS | sonne|work, lambday yes I can, just thinking of how to get it into shogun :) | 11:45 |
| @HeikoS | sonne|work: what do you mean? | 11:45 |
| lambday | the matrix is really huge | 11:45 |
| sonne|work | HeikoS: you could write a libsvm file | 11:45 |
| sonne|work | HeikoS: about the number of allocs | 11:46 |
| @HeikoS | sonne|work: just curious | 11:46 |
| sonne|work | lambday: are you talking about #allocs for the sparse matrix? | 11:46 |
| sonne|work | then shogun will do one alloc per sparse vector of the matrix | 11:46 |
| lambday | sonne|work: yes.. | 11:46 |
| sonne|work | good thing is that you can easily change one vector | 11:46 |
| lambday | sonne|work: but how about the entries? | 11:46 |
| sonne|work | and grow the matrix | 11:47 |
| lambday | okay | 11:47 |
| sonne|work | lambday: that was already for the entries | 11:47 |
| @HeikoS | lambday: so about these conversions from shogun to eigen3 | 11:47 |
| @HeikoS | how badly do they hurt us? | 11:47 |
| sonne|work | HeikoS: depends on the sparsity of the matrix | 11:47 |
| lambday | HeikoS: pretty bad... if I don't get to keep eigen3's sparse as a member then I gotta change it every time I call apply | 11:47 |
| lambday | and that would be A LOT | 11:48 |
| lambday | for cg | 11:48 |
| -!- vgorbati [c3ee5cb1@gateway/web/freenode/ip.195.238.92.177] has joined #shogun | 11:48 | |
| lambday | if I do get to keep eigen3's sparse, its just once | 11:48 |
| @HeikoS | lambday: ok sure, we cannot do this, but say if we have an eigen3 member what is not registered | 11:48 |
| @HeikoS | but just remporary | 11:48 |
| sonne|work | HeikoS: computation wise already the test is 2 times slower | 11:48 |
| sonne|work | with eigen3 | 11:48 |
| lambday | HeikoS: temporary? | 11:48 |
| sonne|work | so at this stage it doesn't look like using eigen3 is a good idea for sparse | 11:48 |
| @HeikoS | sonne|work: yes, but we need eigen3's solvers at some point | 11:48 |
| lambday | sonne|work: well, that depends on the sparsity pattern, doesn't it :( | 11:49 |
| sonne|work | HeikoS: for sparse matrices? | 11:49 |
| @HeikoS | sonne|work: yes, there is a case where we need to use plain vanille cg on sparse linear systems | 11:49 |
| @HeikoS | lambday: but for cocg_m you will implement that anyway by hand | 11:49 |
| lambday | HeikoS: could you please elaborate on the temporary thing? I was thinking it of keeping it as a member, so it will stay as long asn that object last | 11:49 |
| @HeikoS | lambday: ah no, the triangular sparse solver is also there | 11:50 |
| @HeikoS | lambday: sorry, temporary in the sense that it is not a class member (and is not serialised then) | 11:50 |
| @HeikoS | lambday: you you have an object that can be accessed by the instance, but is lost after the instance is deleted | 11:50 |
| @HeikoS | lambday: so no sending around in networks etc | 11:50 |
| @HeikoS | lambday: what about the triangular solver in cocg_m ? for the shifts, how would you do that? | 11:51 |
| @HeikoS | sonne|work, lambday man I really did not expect that many framework challenges in this project ;) | 11:51 |
| lambday | lol neither did I :D first complex, now this :D | 11:52 |
| lambday | HeikoS: cocg_m just applies the operator to the vector :-/ the one that krylstat has | 11:52 |
| lambday | for shifted stuff they do it in two stages | 11:52 |
| @HeikoS | cocg_m but we need a loop over the shifts and a backsolve in each iteration | 11:53 |
| lambday | HeikoS: https://github.com/lambday/KRYLSTAT/blob/master/cocg_m/eigen/eigen_cocg_m.h#L239 | 11:54 |
| lambday | they do it here | 11:54 |
| @HeikoS | I see | 11:55 |
| lambday | HeikoS: and, also, I think I can get cocg_m under the same base | 11:56 |
| @HeikoS | lambday: ok then | 11:56 |
| lambday | cause we have to send shifts anyway, why not weight? | 11:56 |
| @HeikoS | lambday: ok | 11:56 |
| lambday | but that should be optional | 11:56 |
| lambday | I mean, having two solve methods for cocg | 11:56 |
| lambday | one that returns the matrix and another the vector | 11:57 |
| @HeikoS | lambday: thats a good idea I think | 11:57 |
| lambday | yeah. | 11:57 |
| @HeikoS | lambday: how big were the test matrices you used? | 11:57 |
| lambday | but about sparse - | 11:57 |
| lambday | a mil x a mil | 11:57 |
| @HeikoS | I have a 200000 matrix which I used in experiments, will that allow to see differences? | 11:58 |
| @HeikoS | at least it has a realistic sparsity structure :) | 11:58 |
| lambday | yes | 11:58 |
| lambday | so things to check are (a) time (cpu/wall clock) (b) number of allocs (c) total bytes allocated | 11:59 |
| lambday | right? | 11:59 |
| @HeikoS | time is most important, memory is just interesting | 12:00 |
| lambday | okay | 12:00 |
| sonne|work | HeikoS: memory is clear just #of sparse vectors | 12:01 |
| lambday | and log-det framework will work even if eigen3 is not there.. if we provide it an operator, an eigen solver and a linear solver that works without eigen3, it should work | 12:01 |
| @HeikoS | lambday: thats pretty cool then | 12:01 |
| lambday | it all depends on the implementation | 12:01 |
| @HeikoS | lambday: question is what is best for the default case | 12:02 |
| @HeikoS | because letting users choose can create confusion if not documented properly | 12:02 |
| sonne|work | HeikoS: what is a 200000 matrix ? | 12:02 |
| @HeikoS | sonne|work: square and psd | 12:02 |
| sonne|work | 200k x 200k in size? | 12:02 |
| @HeikoS | sonne|work: and badly conditioned | 12:02 |
| @HeikoS | yes | 12:02 |
| sonne|work | nnz? | 12:03 |
| @HeikoS | let me check | 12:03 |
| lambday | HeikoS: is that for the ozone example? | 12:03 |
| @HeikoS | lambday: yes thats the one | 12:03 |
| lambday | cool!!! :D | 12:03 |
| @HeikoS | lambday: but it will be way easier to generate it from python | 12:03 |
| lambday | err... | 12:04 |
| @HeikoS | sonne|work: nnz(Q) = 3723942 | 12:05 |
| sonne|work | quite a lot | 12:05 |
| lambday | HeikoS: could you please send me the script? I gotta read it from a file manually in cpp I guess.. | 12:06 |
| sonne|work | so shogun's code would be twice as fast I would expect | 12:06 |
| lambday | HeikoS: sonne|work: if that is the case (default) then we can just use shogun's for all our stuffs... just gotta add serialization and we're good to go | 12:07 |
| @HeikoS | sonne|work: ok good! | 12:07 |
| @HeikoS | lambday: that would be good | 12:07 |
| @HeikoS | lambday: I was a bit worried about the solvers (e.g. individual ones) | 12:07 |
| lambday | HeikoS: yes I was just thinking that | 12:08 |
| @HeikoS | lambday: also we will need preconditioned CG at some point | 12:08 |
| sonne|work | lambday: well we should test this | 12:08 |
| lambday | ummm... | 12:08 |
| @HeikoS | but for that we can just do a conversation to eigen3 once and then work from there | 12:08 |
| sonne|work | lambday, HeikoS I expect eigen3 to be faster for extremely sparse matrices | 12:08 |
| lambday | preconditioning is just once per solve | 12:08 |
| lambday | sonne|work: yes.. seems so | 12:08 |
| sonne|work | oki | 12:09 |
| * sonne|work food | 12:09 | |
| @HeikoS | sonne|work: haha, enjoy! :) | 12:09 |
| lambday | :D | 12:09 |
| @HeikoS | lambday: should I just send you this matrix as a matlab file? | 12:10 |
| lambday | HeikoS: yes.. or the python script that generates it | 12:10 |
| @HeikoS | lambday: I read things from a file for that, but I can try to write something similar | 12:10 |
| @HeikoS | lambday: yes, I will first send matlab file and then a bit later a script to generate some large matrices randomly | 12:11 |
| lambday | HeikoS: alright | 12:12 |
| lambday | how big is that matrix? | 12:12 |
| lambday | oh wait! | 12:12 |
| @HeikoS | the file? | 12:12 |
| lambday | is that in the ozone code zip? | 12:12 |
| lambday | then I might actually have that | 12:12 |
| @HeikoS | oh yes in fact it is | 12:12 |
| lambday | wait I am checking | 12:12 |
| @HeikoS | there is also the code how to generate the matrix Q as a function of kappa | 12:12 |
| @HeikoS | and for that, some files are loaded | 12:12 |
| lambday | ozone_data.mat | 12:13 |
| lambday | right? | 12:13 |
| @HeikoS | lambday: this contains the building blocks | 12:13 |
| @HeikoS | check mcmc_ozone.m | 12:13 |
| @HeikoS | load 'ozone_data.mat' | 12:13 |
| @HeikoS | create_Q_matrix=@(kappa) GiCG+2*kappa^2*G+(kappa^4)*C0 + speye(size(A,2))*1E-10; | 12:13 |
| @HeikoS | and then you can to Q=create_Q_matrix(2^-10) or so | 12:13 |
| lambday | well, I can do that from octave? :-/ I don't have matlab | 12:14 |
| @HeikoS | should work | 12:14 |
| lambday | alright | 12:14 |
| lambday | checking | 12:14 |
| @HeikoS | if not, let me know | 12:14 |
| lambday | okay | 12:15 |
| @iglesiasg | HeikoS: let me ask you; say I want to have a private method that returns some std::vector, I guess that is not good since vector should be included in the header. However, as I just want to use it internally -- it is private -- it feels like it should be ok being able to do it | 12:15 |
| @iglesiasg | have you faced that before? | 12:15 |
| -!- nube [~rho@116.90.239.13] has quit [Quit: Leaving.] | 12:16 | |
| -!- van51 [~van51@athedsl-399972.home.otenet.gr] has joined #shogun | 12:16 | |
| @HeikoS | iglesiasg: I think that should be fine, however, it is not nice :) | 12:20 |
| @HeikoS | iglesiasg: why do you want the std::vector? | 12:20 |
| @iglesiasg | HeikoS: I would like to use std::vector because I want to have a vector of SGVectors | 12:21 |
| @HeikoS | iglesiasg: does it have to be dynamically growing? | 12:22 |
| @iglesiasg | however I think I could manage using another thing in Shogun for that, it was a bad example | 12:22 |
| @HeikoS | if not, why not use a matrix? | 12:22 |
| @iglesiasg | no, it does not need to be | 12:22 |
| @iglesiasg | I want to index something like this | 12:22 |
| @HeikoS | then you should definitely go for a matrix | 12:22 |
| @iglesiasg | C(i,j) where each of these elements is a vector | 12:22 |
| @HeikoS | ah | 12:22 |
| @HeikoS | so it is a 3d array? | 12:23 |
| @iglesiasg | sort of, but I would rather index it like that, with two indices | 12:23 |
| @HeikoS | iglesiasg: I see, and how do you represent that currently? | 12:24 |
| lambday | HeikoS: alright, matrix loaded | 12:24 |
| @HeikoS | lambday: cool that it worked! | 12:24 |
| lambday | (although I didn't understand a bit of what's going on with the code!) | 12:24 |
| lambday | but then I write this to an ascii file and read it from shogun? | 12:24 |
| @iglesiasg | HeikoS: it is not represented yet, I want to first see if I can use something like std::vector< std::vector<SGVector>> | 12:24 |
| @HeikoS | lambday: yes, although I never loaded sparse matrices, sonne|work pointed out the svmfile might be a possibility | 12:25 |
| van51 | iglesiasg: vector inception :O | 12:25 |
| @iglesiasg | HeikoS: apart from that, I am in a similar situation where I would like to use a std::set, and that a private method returns it | 12:25 |
| @HeikoS | iglesiasg: I see, let me think | 12:25 |
| @iglesiasg | van51: maybe it looks weird yeah :S | 12:25 |
| @HeikoS | iglesiasg: I mean you could have a DynamicArray of DynamicObjectArrays | 12:26 |
| @iglesiasg | but SGVector are not SGObject | 12:26 |
| @HeikoS | iglesiasg: the thing is: if you do the private method with std::vector you can never use it from another language than c++ | 12:26 |
| @HeikoS | iglesiasg: you can use DynArray<float> | 12:26 |
| @HeikoS | there is one array for CSGObject and one for generic stuff | 12:27 |
| @HeikoS | iglesiasg: I had these issues before and did not really come up with a nice solution | 12:27 |
| @HeikoS | iglesiasg: what about a large matrix? | 12:27 |
| @HeikoS | then you just have to do index conversions? | 12:28 |
| @iglesiasg | yeah, but the indexing won't be nice | 12:28 |
| @HeikoS | iglesiasg: a block matrix | 12:28 |
| -!- foulwall [~user@2001:da8:215:6100:2d48:68e4:4af2:4837] has quit [Quit: super] | 12:28 | |
| @HeikoS | iglesiasg: you could have a private method for that | 12:28 |
| @HeikoS | then it would be more generic | 12:28 |
| @iglesiasg | aham, that sounds more feasible | 12:28 |
| @iglesiasg | I guess I won't be able to use operators like () and [] though | 12:28 |
| @HeikoS | you could add a method that takes a matrix and your three indices and then returns the coresponding thing for you | 12:29 |
| @HeikoS | iglesiasg: ah we really should implement the NDArray soon | 12:30 |
| @HeikoS | since this would solve everything | 12:30 |
| @iglesiasg | now that I think of the the SGMatrixList may help me for this too | 12:30 |
| @iglesiasg | I am actually more concerned now about the set thing | 12:30 |
| @HeikoS | iglesiasg: yes, it might, I have not used that yet though | 12:31 |
| @HeikoS | isnt there CSet? is that for CSGObject only? | 12:31 |
| @iglesiasg | HeikoS: I have seen the lib/Set but it does not seem to implement an intersection | 12:31 |
| @HeikoS | iglesiasg: ah yes, thats not a proper set | 12:32 |
| @HeikoS | mmh | 12:32 |
| @HeikoS | iglesiasg: so these methods are private? | 12:32 |
| @HeikoS | maybe you should just use std:: then | 12:32 |
| @iglesiasg | HeikoS: yes, they are private | 12:32 |
| @HeikoS | too much hassle otherwise | 12:32 |
| @HeikoS | iglesiasg: I mean you can still unit-test them | 12:32 |
| @HeikoS | since thats also in c++ | 12:32 |
| @iglesiasg | but about what you said that it won't be possible to call from other languages | 12:33 |
| @iglesiasg | say I have a public train method | 12:33 |
| @HeikoS | but people will not be able to call them, say if they want to unterstand things better | 12:33 |
| @iglesiasg | well, but if I make them private | 12:33 |
| @HeikoS | iglesiasg: they cannot be called anyway | 12:33 |
| @iglesiasg | the idea is that people can't call them | 12:33 |
| @HeikoS | you are right | 12:33 |
| @iglesiasg | exactly | 12:33 |
| @HeikoS | iglesiasg: haha :) sorry | 12:33 |
| @iglesiasg | :) but one is going to be still able to call the public methods from target languages right? | 12:34 |
| @HeikoS | well, it will definitely work, so why not do it | 12:34 |
| @iglesiasg | ok | 12:34 |
| @iglesiasg | I am going to try to use the SGMatrixList then but the set will be included in the header I think | 12:34 |
| @iglesiasg | HeikoS: thanks! | 12:34 |
| @HeikoS | iglesiasg: to be honest I would not use the matrix list, our lists are quite messy in terms of memory management | 12:35 |
| @iglesiasg | haha ok | 12:37 |
| votjakovr | HeikoS: if you have a time please look at evaluate_means and evaluate_variances method of LikelihoodModel class, should i add labels as a parameter for that methods or we are only interested in y==1? | 12:39 |
| @HeikoS | votjakovr: we should have both | 12:40 |
| @HeikoS | votjakovr: so if labels==NULL (default) y==1 will be used | 12:40 |
| @HeikoS | votjakovr: and for multiclass, things are a bit different | 12:40 |
| votjakovr | HeikoS: ok, i'll add | 12:40 |
| van51 | sonne|work: I've added that option to DelimiterTokenizer | 12:42 |
| van51 | sonne|work: I've sent a PR | 12:42 |
| @HeikoS | votjakovr: please document that properly to avoid confusion :) | 12:46 |
| -!- nube [~rho@36.252.244.207] has joined #shogun | 12:47 | |
| votjakovr | HeikoS: yeah :) | 12:49 |
| -!- nube [~rho@36.252.244.207] has quit [Ping timeout: 268 seconds] | 12:52 | |
| -!- foulwall [~foulwall@117.136.0.135] has joined #shogun | 12:52 | |
| -!- votjakovr [~votjakovr@host-46-241-3-209.bbcustomer.zsttk.net] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] | 13:05 | |
| -!- iglesiasg [~Fernando@s83-179-44-135.cust.tele2.se] has quit [Ping timeout: 260 seconds] | 13:06 | |
| sonne|work | van51: which one now? | 13:27 |
| van51 | sonne|work: the delimiter PR is ready | 13:29 |
| -!- shogun-notifier- [~irker@7nn.de] has joined #shogun | 13:29 | |
| shogun-notifier- | shogun: van51 :develop * c7a27ca / / (3 files): https://github.com/shogun-toolbox/shogun/commit/c7a27caf7e4b838682019210cdf70e3a4c5496c2 | 13:29 |
| shogun-notifier- | shogun: Option to skip delimiters in CDelimiterTokenizer | 13:29 |
| shogun-notifier- | shogun: Soeren Sonnenburg :develop * 583fc6c / / (3 files): https://github.com/shogun-toolbox/shogun/commit/583fc6cab8c367d20dcd163cd72f59714cd65c9e | 13:29 |
| shogun-notifier- | shogun: Merge pull request #1217 from van51/feature/tokenizer | 13:29 |
| shogun-notifier- | shogun: | 13:29 |
| shogun-notifier- | shogun: Option to skip delimiters in CDelimiterTokenizer | 13:29 |
| sonne|work | van51: yeah I thought you already did some skip 'n' delimiters | 13:29 |
| sonne|work | van51: but thansk anway | 13:29 |
| sonne|work | should be pretty useful for gsomix | 13:29 |
| van51 | sonne|work: np | 13:30 |
| van51 | sonne|work: I also liked that functionality | 13:30 |
| sonne|work | van51: I am tempted to think that instead of skipping delimiters you could add an option to skip 'n' delimiters | 13:31 |
| sonne|work | so one would get multiple words | 13:31 |
| sonne|work | van51: I mean I think the code might be actually pretty similar | 13:31 |
| van51 | sonne|work: like the n-words you mentioned yesterday? | 13:31 |
| sonne|work | yes | 13:31 |
| sonne|work | if you had some counter that counts down to 0 I mean | 13:32 |
| sonne|work | which would usually be 1 | 13:32 |
| sonne|work | just thinking | 13:32 |
| van51 | sonne|work: hm I get what you're saying | 13:33 |
| shogun-buildbot | build #1007 of cyg1 - libshogun is complete: Failure [failed configure] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/1007 blamelist: van51 <vangelis_51@hotmail.com> | 13:34 |
| van51 | sonne|work: but the idea behind this PR was to avoid situations like consecutive white space | 13:34 |
| lambday | HeikoS: libsvm format is row#: col#:val, right? val only nz elements? | 13:35 |
| van51 | sonne|work: it may be a bit trickier to maintain both functionalities simultaneously | 13:35 |
| lambday | HeikoS: sonne|work how do I read from libsvm files in shogun? | 13:35 |
| sonne|work | lambday: we have function in CSparseFeatures | 13:36 |
| van51 | sonne|work: I don't mind implementing that, but maybe it would be better in a seperate tokenizer like you proposed yesterday | 13:36 |
| lambday | sonne|work: okay.. | 13:36 |
| sonne|work | van51: yeah maybe it is more explicit which is good | 13:37 |
| sonne|work | lambday: CRegressionLabels* load_svmlight_file(char* fname, bool do_sort_features=true); | 13:37 |
| lambday | sonne|work: yes.. | 13:37 |
| sonne|work | lambday: that is what you need | 13:37 |
| lambday | sonne|work: okay.. | 13:38 |
| lambday | its being huge | 13:38 |
| -!- nube [~rho@36.252.234.248] has joined #shogun | 13:39 | |
| sonne|work | lambday: size? | 13:40 |
| sonne|work | I thought it was just 4 million nnz's? | 13:40 |
| lambday | still writing | 13:40 |
| lambday | yes | 13:40 |
| sonne|work | ahh yes the file itself is big yes | 13:40 |
| lambday | I am writing from octave | 13:40 |
| sonne|work | but loaded it would just be 50MB or so | 13:40 |
| shogun-buildbot | build #1211 of bsd1 - libshogun is complete: Failure [failed test] Build details are at http://www.shogun-toolbox.org/buildbot/builders/bsd1%20-%20libshogun/builds/1211 blamelist: van51 <vangelis_51@hotmail.com> | 13:41 |
| shogun-buildbot | build #1008 of cyg1 - libshogun is complete: Failure [failed configure] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/1008 blamelist: Soeren Sonnenburg <sonne@debian.org> | 13:45 |
| sonne|work | van51: btw I had a look at the Streaming* code and I don't see any better way than storing the converted output | 13:53 |
| sonne|work | van51: I mean a sparse vector | 13:53 |
| shogun-buildbot | build #1212 of bsd1 - libshogun is complete: Failure [failed test] Build details are at http://www.shogun-toolbox.org/buildbot/builders/bsd1%20-%20libshogun/builds/1212 blamelist: Soeren Sonnenburg <sonne@debian.org> | 13:54 |
| van51 | sonne|work: so it's going ok | 13:54 |
| -!- foulwall` [~user@2001:da8:215:6100:259b:cbe5:416f:ba90] has joined #shogun | 13:59 | |
| -!- foulwall [~foulwall@117.136.0.135] has quit [Quit: AndroIRC - Android IRC Client ( http://www.androirc.com )] | 13:59 | |
| -!- iglesiasg [~Fernando@s83-179-44-135.cust.tele2.se] has joined #shogun | 14:01 | |
| -!- mode/#shogun [+o iglesiasg] by ChanServ | 14:01 | |
| sonne|work | van51: yes just add a test. IIRC there was some code to turn streaming* features into normal SparseFeatures (or densefeatures?) - maybe it would be good to compare data | 14:09 |
| sonne|work | iglesiasg: what do you want to do? you need nd-arrays? | 14:10 |
| shogun-buildbot | build #1333 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/1333 blamelist: van51 <vangelis_51@hotmail.com> | 14:11 |
| @iglesiasg | sonne|work: I want to index matrices like this C(i,j) | 14:17 |
| @iglesiasg | this C(i,j) would be a matrix | 14:17 |
| naywhayare | iglesiasg: hello there | 14:20 |
| naywhayare | I believe the benchmarks were done before the cover tree support was added to shogun, if I remember right | 14:21 |
| sonne|work | iglesiasg: and SGMatrix C; is not enough? | 14:21 |
| -!- nube [~rho@36.252.234.248] has quit [Read error: Connection reset by peer] | 14:21 | |
| naywhayare | here is the script: http://pastebin.com/CyHYNGMD | 14:22 |
| naywhayare | like every other library, I used the documentation to figure out what the simplest way to run kNN was | 14:22 |
| naywhayare | (that is, the way a new user would be most likely to approach it) | 14:23 |
| @iglesiasg | naywhayare: aham ok, so the default option in mlpack is using cover tree / kd tree? | 14:25 |
| @iglesiasg | sonne|work: Wouldn't I need to do a SGMatrix<SGMatrix> then? AFAIK, that's not possible | 14:25 |
| sonne|work | iglesiasg: ahh matrix! | 14:25 |
| naywhayare | iglesiasg: the default option in mlpack is the kd-tree | 14:26 |
| @iglesiasg | naywhayare: got it, all right | 14:26 |
| -!- nube [~rho@49.244.112.133] has joined #shogun | 14:26 | |
| sonne|work | iglesiasg: is this matrix of constant size? | 14:27 |
| sonne|work | iglesiasg: I mean could we just use ndarrays? | 14:27 |
| @iglesiasg | sonne|work: yeah, however then I do not see how to use just two indices | 14:27 |
| @iglesiasg | using a intermediate function as Heiko said | 14:27 |
| @iglesiasg | but I wouldn't be able to use operators [] or () I think | 14:28 |
| sonne|work | iglesiasg: ahh ok and your matrixlist class is not an option? | 14:28 |
| @iglesiasg | sonne|work: yeah, I think it could | 14:28 |
| @iglesiasg | I can live doing | 14:28 |
| @iglesiasg | C(n*j + i) | 14:28 |
| @iglesiasg | or something like that | 14:29 |
| sonne|work | iglesiasg: you could add an operator in you matrixlist class too | 14:29 |
| sonne|work | so it would be exactly like this then | 14:29 |
| @iglesiasg | sonney2k: mmm it may be an option | 14:29 |
| @iglesiasg | sonne|work: wrong name :) | 14:30 |
| @iglesiasg | however, I would like to still include set in the header | 14:30 |
| @iglesiasg | I don't say no way around that | 14:30 |
| @iglesiasg | I am just using it internally though, just need it in the header for the return value of a private method | 14:30 |
| sonne|work | sorry what? set in the header? | 14:36 |
| sonne|work | iglesiasg: ^ | 14:37 |
| @iglesiasg | include set in the header | 14:37 |
| @iglesiasg | like #include <set>, std::set | 14:38 |
| @iglesiasg | sonne|work: ^ | 14:41 |
| sonne|work | ahh ok then just add this function to modshogun_ignores.i | 14:42 |
| sonne|work | to exclude it from swig | 14:42 |
| @iglesiasg | it makes sense | 14:42 |
| @iglesiasg | do I need to use some SWIG_IGNORE too? | 14:42 |
| shogun-buildbot | build #1334 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/1334 blamelist: Soeren Sonnenburg <sonne@debian.org> | 14:46 |
| sonne|work | iglesiasg: no | 14:57 |
| -!- van51 [~van51@athedsl-399972.home.otenet.gr] has quit [Quit: Leaving.] | 15:04 | |
| lisitsyn | heavy irc usage today! | 15:04 |
| lisitsyn | it is monday btw | 15:04 |
| lisitsyn | so | 15:04 |
| lisitsyn | gsomix: hushell: foulwall: iglesiasg: lambday: you know what to do | 15:04 |
| @iglesiasg | lisitsyn: sure :) | 15:08 |
| @iglesiasg | thanks for the reminder | 15:08 |
| lambday | lisitsyn: yes :) | 15:11 |
| foulwall` | thanks for the reminder | 15:12 |
| @HeikoS | lambday: i am back | 15:26 |
| lambday | HeikoS: wb :) | 15:26 |
| @HeikoS | lambday: whats up? :) | 15:27 |
| lambday | HeikoS: the matrix is so f**king big :( :( | 15:27 |
| lambday | HeikoS: its still writing :( | 15:27 |
| lambday | HeikoS: in the meantime I tested to read from a svmlight file to a sparse matrix | 15:27 |
| lambday | works fine | 15:27 |
| @HeikoS | lambday: ascii is a bad format | 15:27 |
| lambday | :( | 15:28 |
| lambday | but the good thing is, once I write it, I'll use it for all experiments later on :D | 15:28 |
| @HeikoS | lambday, sonne|work it would be good to have some std formats that we can read | 15:28 |
| lambday | even for the demo :D | 15:28 |
| @HeikoS | like hdf5 | 15:28 |
| @HeikoS | or *.mat | 15:28 |
| @HeikoS | lambday: yes, thats good, its gonna be huge though | 15:28 |
| lambday | HeikoS: *.mat will be really helpful I think | 15:29 |
| lambday | HeikoS: I am guessing 100+ MB | 15:29 |
| lambday | sonne|work: said loaded size will not be more than 50 MB | 15:29 |
| sonne|work | HeikoS: we can read hdf5 and the ascii format matlab does | 15:29 |
| @HeikoS | lambday: loaded is fine, its just a pain to read/write asci | 15:29 |
| lambday | yes :( | 15:30 |
| @HeikoS | sonne|work: how easy is it to read hdf5? | 15:30 |
| @HeikoS | because matlab can export that | 15:30 |
| sonne|work | 2 lines | 15:30 |
| @HeikoS | lambday: maybe this is better then? | 15:30 |
| sonne|work | HeikoS: actually new matlab is hdf5 | 15:30 |
| lambday | so.. use SGSparseMatrix::load instead of that | 15:30 |
| sonne|work | e.g. | 15:30 |
| lambday | but I gotta check how to write hdf5 from octave | 15:31 |
| @HeikoS | lambday: thats easy | 15:31 |
| sonne|work | f=HDF5File("fm_train_real.h5","r", "/data/doubles") | 15:31 |
| sonne|work | feats2.load(f) | 15:31 |
| @HeikoS | I did that before | 15:31 |
| sonne|work | f=AsciiFile("label_train_twoclass.ascii") | 15:31 |
| sonne|work | lab2.load(f) | 15:31 |
| lambday | sonne|work: ah thanks | 15:31 |
| @HeikoS | cool! thx :) | 15:31 |
| sonne|work | features_io_modular.py | 15:31 |
| sonne|work | is the example | 15:31 |
| sonne|work | but it can be directly used on SG* datatypes | 15:32 |
| lambday | HeikoS: so in octave, I just do something like hdf5write('myfile2.h5', 'blah-blah', Q); ?? Q=sparse matrix? | 15:36 |
| -!- foulwall` [~user@2001:da8:215:6100:259b:cbe5:416f:ba90] has quit [Ping timeout: 264 seconds] | 15:37 | |
| @HeikoS | lambday: yes its that simple, | 15:37 |
| lambday | and then just use shogun's load? | 15:37 |
| @HeikoS | maybe some details, | 15:37 |
| @HeikoS | just try with a small matrix | 15:37 |
| lambday | alright | 15:37 |
| lambday | ah crap! octave says "warning: the `hdf5write' function is not yet implemented in Octave" | 15:39 |
| lambday | HeikoS: :'( | 15:39 |
| @HeikoS | lambday: nice ;) | 15:39 |
| @HeikoS | I can write you one | 15:39 |
| @HeikoS | from matlab | 15:39 |
| @HeikoS | Ill test a small sparse matrix | 15:39 |
| @HeikoS | just a sec | 15:39 |
| lambday | HeikoS: alright | 15:39 |
| @HeikoS | lambday: ah computer overloaded ;) | 15:45 |
| @HeikoS | too many things at once | 15:45 |
| lambday | HeikoS: hehe :D | 15:45 |
| @HeikoS | lambday: I need more memory | 15:46 |
| lambday | HeikoS: how much do you have? | 15:46 |
| @HeikoS | 8 are not enough | 15:46 |
| @HeikoS | compiling a big thing currently, thats the problem, anyways, will now store the matrix | 15:46 |
| sonne|work | HeikoS: why are you not using libsvm format? | 15:46 |
| @HeikoS | sonne|work: lambday said it takes ages to write the file | 15:47 |
| lambday | sonne|work: yes I am doing that | 15:47 |
| @HeikoS | lambday: is it yet finished btw? | 15:47 |
| lambday | meanwhile, we're trying with hdf5 | 15:47 |
| lambday | HeikoS: nope! | 15:47 |
| sonne|work | lambday: it was just 4 million entries? why does it take so long then? | 15:48 |
| sonne|work | lambday: do you have the sparse matrix as scipy.sparse perhaps? | 15:48 |
| sonne|work | or in which format? | 15:48 |
| lambday | sonne|work: no.. octave's sparse | 15:48 |
| sonne|work | lambday: but then you could pass this matrix to shogun | 15:49 |
| lambday | octave interface? | 15:50 |
| sonne|work | lambday: modular octave interface | 15:50 |
| @HeikoS | sonne|work: how does that work? | 15:50 |
| sonne|work | I don't understand the question | 15:52 |
| sonne|work | the same way you do python with sparse | 15:52 |
| sonne|work | features_sparse_modular.m | 15:52 |
| sonne|work | examples/undocumented/octave_modular/ features_sparse_modular.m | 15:52 |
| @HeikoS | Matlab: Error using hdf5writec | 15:52 |
| @HeikoS | Sparse data is not supported. | 15:52 |
| @HeikoS | sonne|work: we need the matrix from c++ | 15:52 |
| sonne|work | HeikoS: well then save it from shogun | 15:53 |
| @HeikoS | sonne|work: ha! clever | 15:53 |
| sonne|work | though I don't see why you need it from c++ | 15:53 |
| @HeikoS | testing | 15:54 |
| sonne|work | you could use the callbacks | 15:54 |
| @HeikoS | not following | 15:54 |
| @HeikoS | callbacks? | 15:54 |
| sonne|work | HeikoS: I mean the octave interface for the tests in the same way | 15:55 |
| @HeikoS | sonne|work: sorry I totally dont get what you are talking about. all we want to have is this matrix in available in c++ for testing(not example) how we do this: doesnt matter. | 15:56 |
| @HeikoS | but I think a good way is to load it from a modular interface and save it in some shogun format | 15:56 |
| sonne|work | jsut save it as ascii file | 15:56 |
| sonne|work | I was under the impression you just need it now for the benchmark so you could have put the benchmark function into e.g. CSparseFeatures for the test and done | 15:57 |
| @HeikoS | sonne|work: ascii file takes long to save, lambday? | 15:57 |
| @HeikoS | gotta go, talk | 15:58 |
| @HeikoS | sry | 15:58 |
| sonne|work | cannot imagine that this is slow for just 4 million elements | 16:01 |
| -!- foulwall` [~user@2001:da8:215:6100:9594:7f4:ea8a:ecb5] has joined #shogun | 16:04 | |
| -!- foulwall` [~user@2001:da8:215:6100:9594:7f4:ea8a:ecb5] has quit [Remote host closed the connection] | 16:06 | |
| -!- foulwall` [~user@2001:da8:215:6100:9594:7f4:ea8a:ecb5] has joined #shogun | 16:06 | |
| @iglesiasg | wiking: hey, I think there might be a problem with the configure script recognizing gmock | 16:13 |
| @iglesiasg | wiking: it said that it was in my machine under /usr/src even though it was not | 16:14 |
| -!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout] | 16:29 | |
| -!- gsomix_ [~gsomix@109.188.125.190] has joined #shogun | 16:32 | |
| wiking | iglesiasg: doh | 16:32 |
| wiking | iglesiasg: can u send me the configure.log? | 16:32 |
| -!- gsomix [~gsomix@109.188.124.215] has quit [Ping timeout: 256 seconds] | 16:33 | |
| @iglesiasg | wiking: http://pastebin.com/94UFB32N | 16:35 |
| -!- foulwall` [~user@2001:da8:215:6100:9594:7f4:ea8a:ecb5] has quit [Ping timeout: 264 seconds] | 16:36 | |
| wiking | iglesiasg: doh, this wasn't helpful :( | 16:49 |
| @HeikoS | lambday: was the matrix saved in ascii by now? | 17:05 |
| lambday | HeikoS: yes :D | 17:05 |
| @HeikoS | lambday: ok, then I dont need to send another one :) | 17:05 |
| lambday | HeikoS: yes.. its HUGE | 17:06 |
| @HeikoS | lambday: how big? | 17:06 |
| lambday | 71MB | 17:06 |
| @HeikoS | lambday: might be a good idea to save it to hdf via some modular interface | 17:06 |
| lambday | HeikoS: yup.. but first I wanna see which performs better | 17:07 |
| @HeikoS | lambday: yes go ahead :) | 17:07 |
| lambday | argh... segfault! | 17:09 |
| @HeikoS | lambday: valgrind :) | 17:09 |
| lambday | HeikoS: sonne|work unthreaded, unopenmp'd version - eigen3 wins by a small margin | 17:14 |
| lambday | trying others | 17:14 |
| -!- zxtx [~zv@cpe-75-83-151-252.socal.res.rr.com] has quit [Ping timeout: 245 seconds] | 17:15 | |
| lambday | HeikoS: sonne|work the difference was ~0.04 s | 17:16 |
| @HeikoS | lambday: well, so they are equal :) | 17:16 |
| lambday | HeikoS: pretty much! | 17:17 |
| lambday | I am hoping to get a better performance with the pthreaded one | 17:17 |
| -!- foulwall [~user@2001:da8:215:c252:c82:7dd9:e65a:75e6] has joined #shogun | 17:17 | |
| @HeikoS | lambday: yeah ... | 17:17 |
| @HeikoS | lambday: but thats not too interesting for us anyways ... but try it | 17:17 |
| lambday | HeikoS: yeah just trying | 17:17 |
| -!- iglesiasg [~Fernando@s83-179-44-135.cust.tele2.se] has quit [Ping timeout: 240 seconds] | 17:19 | |
| lambday | HeikoS: sonne|work nah! same! | 17:19 |
| lambday | oh wait! | 17:19 |
| @HeikoS | lambday: threaded will be more useful for larger matrices | 17:19 |
| @HeikoS | lambday: how long does on product take btw? | 17:20 |
| lambday | HeikoS: sonne|work with threaded, shogun wins | 17:20 |
| @HeikoS | lambday: nice | 17:20 |
| @HeikoS | so matlab needs 0.012 on my machine for one product | 17:21 |
| lambday | HeikoS: I am testing just the product, 100 times for each | 17:21 |
| lambday | o | 17:21 |
| lambday | oh | 17:21 |
| lambday | wait | 17:21 |
| lambday | 0.005090 for SG | 17:21 |
| lambday | 0.005908 for eigen3 | 17:22 |
| @HeikoS | nice | 17:22 |
| lambday | SG-pthreaded | 17:22 |
| @HeikoS | thats faster | 17:22 |
| lambday | yeah! | 17:22 |
| lambday | but I use corei7+16gb ram | 17:22 |
| @HeikoS | lambday: oh | 17:23 |
| @HeikoS | I dont have such things :) | 17:23 |
| lambday | HeikoS: I use insti's :D | 17:23 |
| lambday | my laptop is 1GB :D | 17:23 |
| @HeikoS | hehe | 17:23 |
| lambday | so, I am testing with octave on mine | 17:24 |
| @HeikoS | octave is very slow in most things | 17:24 |
| @HeikoS | asserts for example are incredibly slow | 17:25 |
| -!- iglesiasg [~Fernando@s83-179-44-135.cust.tele2.se] has joined #shogun | 17:25 | |
| -!- mode/#shogun [+o iglesiasg] by ChanServ | 17:25 | |
| lambday | HeikoS: 0.01413393 | 17:26 |
| @HeikoS | nice | 17:27 |
| lambday | phew!! | 17:27 |
| lambday | so, I can start using SGSparse then | 17:27 |
| lambday | so my todo list - (a) add SGSparse under param framework (b) add serialization (c) add mat-vec product method in SGSparseMatrix (HeikoS : do you think we should have the threaded one there as well?) (d) add sparse matrix operator | 17:29 |
| @HeikoS | lambday: looks good, one thing, lets do the serialisation a bit later ok? after the cocg_m work | 17:30 |
| lambday | HeikoS: alright | 17:30 |
| @HeikoS | c) we should have this in | 17:30 |
| @HeikoS | if its not too much wokr | 17:30 |
| lambday | HeikoS: alright :) | 17:30 |
| lambday | HeikoS: lol I'll copy paste sonne|work's code :D | 17:30 |
| @HeikoS | lambday: thats totally fine | 17:31 |
| @HeikoS | lambday: you could even go openmp here | 17:31 |
| @HeikoS | since its easier | 17:31 |
| lambday | HeikoS: yes but that doesn't help much! no idea why! | 17:32 |
| -!- vgorbati [c3ee5cb1@gateway/web/freenode/ip.195.238.92.177] has quit [Quit: Page closed] | 17:32 | |
| foulwall | ping lisitsyn | 17:32 |
| -!- pickle27 [~Kevin@d67-193-243-174.home3.cgocable.net] has joined #shogun | 17:36 | |
| @sonney2k | lambday, hmmhh that is just too fast | 17:37 |
| @sonney2k | lambday, I guess one cannot really gain anything by parallelizing stuff | 17:37 |
| @sonney2k | HeikoS, I tried openmp first but basically neither pthreads nor openmp really help | 17:37 |
| lambday | sonney2k: but pthread helps :-/ | 17:37 |
| @sonney2k | lambday, what is the speedup? | 17:37 |
| @sonney2k | lambday, how many CPU's did you use? | 17:37 |
| lambday | 2 | 17:38 |
| @HeikoS | lambday: we can also just leave the parallelization for now | 17:38 |
| @HeikoS | can always add that later | 17:38 |
| @sonney2k | lambday, on my i7 at home it didn't help much so what is the speedup single core vs multiple? | 17:38 |
| lambday | HeikoS: yeah | 17:38 |
| @HeikoS | its easy if there are unit tests that ensure that things compute exact products | 17:38 |
| @sonney2k | HeikoS, heh lambday already had that shogun's output is compared to eigen3's | 17:39 |
| lambday | sonney2k: 0.006664 (single thread) | 17:39 |
| lambday | sonney2k: 0.004662 (multiple) | 17:40 |
| lambday | i7 | 17:40 |
| lambday | (just for one multiplication) | 17:40 |
| @sonney2k | with 2 threads. and if you use say 4 threads? | 17:40 |
| lambday | sonney2k: that was 4 threads | 17:40 |
| @sonney2k | it is really fast anyways | 17:40 |
| lambday | earlier I was using 2 | 17:40 |
| @sonney2k | HeikoS, will that operation be the bottleneck? | 17:40 |
| lambday | HeikoS: I should add that unit-test anyway | 17:41 |
| @HeikoS | sonney2k: it is important, but when this stuff is parallelized on a larger scale anyway, we will usually only have 1cpu per job usually | 17:42 |
| @HeikoS | so its not very important to gain 20% | 17:42 |
| @sonney2k | 30% on lambday's i7 | 17:43 |
| @HeikoS | sonne|work: we can speed things up in more clever ways (preconditioning etc) | 17:43 |
| @HeikoS | sonney2k: its easy to add later on right? | 17:43 |
| @HeikoS | and it would be good to have, but not crucial for now I would say | 17:43 |
| @sonney2k | HeikoS, well it is already there just use my code | 17:43 |
| @sonney2k | I don't care though | 17:44 |
| @sonney2k | I was just interested in the benchmark | 17:44 |
| @sonney2k | lambday, waht was shogun single threaded? | 17:46 |
| lambday | sonney2k: eigen3 was slightly faster | 17:46 |
| @sonney2k | lambday, I meant the time | 17:46 |
| lambday | sonney2k: wait | 17:46 |
| lambday | sonney2k: [shogun] 0.006630, [eigen3] 0.005180 | 17:47 |
| lambday | (just for one multiplication) | 17:47 |
| @sonney2k | ok | 17:49 |
| @sonney2k | alright gtg | 17:50 |
| lambday | sonney2k: see you | 17:50 |
| -!- van51 [~van51@athedsl-399972.home.otenet.gr] has joined #shogun | 17:51 | |
| lisitsyn | foulwall: pong | 17:52 |
| -!- iglesiasg [~Fernando@s83-179-44-135.cust.tele2.se] has quit [Quit: Leaving] | 18:08 | |
| -!- sanyam [uid10602@gateway/web/irccloud.com/x-qnjvagnlypgbldrp] has quit [Ping timeout: 264 seconds] | 18:09 | |
| lambday | HeikoS: I'll be back later | 18:12 |
| -!- lambday [67157d37@gateway/web/freenode/ip.103.21.125.55] has quit [] | 18:13 | |
| -!- foulwall [~user@2001:da8:215:c252:c82:7dd9:e65a:75e6] has quit [Remote host closed the connection] | 18:32 | |
| -!- van51 [~van51@athedsl-399972.home.otenet.gr] has quit [Quit: Leaving.] | 18:34 | |
| -!- van51 [~van51@athedsl-399972.home.otenet.gr] has joined #shogun | 18:41 | |
| -!- nube [~rho@49.244.112.133] has quit [Quit: Leaving.] | 18:48 | |
| -!- nube [~rho@49.244.112.133] has joined #shogun | 18:50 | |
| -!- zxtx [~zv@rrcs-74-62-200-195.west.biz.rr.com] has joined #shogun | 18:58 | |
| hushell | lisitsyn: report coming soon :) | 19:18 |
| pickle27 | lisitsyn: just sent my report | 19:24 |
| pickle27 | lisitsyn: I'll be around for a while if you / anyone wants to discuss final examples | 19:24 |
| -!- marcus_zoq [~marcus@vps.virtual-artz.de] has joined #shogun | 19:27 | |
| hushell | HeikoS: Could you check for me this short code: http://pastebin.com/96ugwecq ? | 19:27 |
| hushell | HeikoS: I am using DynamicObjectArray but get mem leak :( | 19:28 |
| @HeikoS | hushell: what should I check it for? | 19:28 |
| @HeikoS | ah I see | 19:28 |
| marcus_zoq | Hello, I'm trying to run K-Means clustering with given starting points. But I get the following error: [ERROR] assertion idx_b<rhs->get_num_vectors() failed in file ../shogun/distance/Distance.h line 121. Perhaps anybody can help me? | 19:28 |
| hushell | HeikoS: mem leak detected in line 19 | 19:28 |
| @HeikoS | marcus_zoq: could you paste some code on pastebin or gist? | 19:29 |
| marcus_zoq | sure | 19:29 |
| @HeikoS | hushell: get_element increases REF | 19:30 |
| @HeikoS | hushell: removing the print lines removes the leak | 19:30 |
| marcus_zoq | https://gist.github.com/zoq/0c4181694e7e6d3d516b | 19:31 |
| hushell | HeikoS: so this means I have to keep the pointer returned by get_element() ... | 19:32 |
| @HeikoS | hushell: yes if you get_element you have to SG_UNREF afterwards | 19:33 |
| @HeikoS | marcus_zoq: why this derives class? | 19:33 |
| hushell | HeikoS: Thanks very much! I know next time similar problem, I go to check SG_REF somewhere | 19:33 |
| @HeikoS | hushell: no worries, these things are hard to catch if you dont know them, keep in mind that any method that returns a CSGObject should increase the ref-count, we need that for swig | 19:34 |
| marcus_zoq | HeikoS: I think shogun has no direct way to set initial centroids? | 19:35 |
| @HeikoS | marcus_zoq: ah that might be ... maybe write to the mailing list on this one then, I have never used nor written the KMeans code | 19:37 |
| marcus_zoq | ok, thanks | 19:38 |
| @HeikoS | marcus_zoq: sonney2k might know, or iglesias (not here currently) | 19:38 |
| -!- marcus_zoq [~marcus@vps.virtual-artz.de] has left #shogun [] | 19:42 | |
| -!- votjakovr [~votjakovr@host-46-241-3-209.bbcustomer.zsttk.net] has joined #shogun | 19:43 | |
| lisitsyn | pickle27: hey | 19:44 |
| lisitsyn | I am back | 19:44 |
| @sonney2k | HeikoS, hushell well any method that returns a *new* CSGObject does not need a SG_REF, only when you return an object that you use internally too | 19:45 |
| @HeikoS | sonney2k: yes sure, I forgot to say | 19:45 |
| @HeikoS | sonney2k: our kmeans seems a bit deprecated , s.o. | 19:46 |
| @sonney2k | HeikoS, only because we have no function to set the cluster centers? | 19:46 |
| @HeikoS | sonney2k: no I mean also the code with get/free feature vector | 19:47 |
| @HeikoS | sonney2k: is it as easy as add a method? | 19:47 |
| pickle27 | lisitsyn: cool! | 19:47 |
| pickle27 | lisitsyn: I'm working away on adding ICA right | 19:47 |
| pickle27 | now | 19:47 |
| pickle27 | lisitsyn: right now I have it as a public CEmbeddingConverter, not sure if this is the right fit yet | 19:47 |
| pickle27 | lisitsyn: I am just going to continue going forward and if I need to change the base class in the future I'll do so | 19:48 |
| @sonney2k | HeikoS, the code is pretty messy but it looks like the function clustknb can start with some predefined mean's | 19:51 |
| @HeikoS | sonney2k: yeah the things are also sometimes as rhs of the distance | 19:51 |
| @HeikoS | sonney2k: if you look at the code marcus_zoq: https://gist.github.com/zoq/0c4181694e7e6d3d516b | 19:52 |
| @HeikoS | this is what he tried | 19:52 |
| @sonney2k | looks reasonable | 19:52 |
| @HeikoS | but would be better if we offered that directly I would say | 19:52 |
| @sonney2k | HeikoS, file a bug report. I think the code should be heavily refactored too btw | 19:55 |
| @sonney2k | it is way to hard to read | 19:55 |
| @HeikoS | sonney2k: indeed ;) | 19:56 |
| naywhayare | both marcus_zoq and I are looking into this, by the way (he is off getting dinner, so he says) | 19:57 |
| naywhayare | "way too hard to read" +1000 | 19:57 |
| naywhayare | I'll also add that the code did work with an older version of shogun (1.0.0 I think) but I haven't diffed them to see what changed | 19:58 |
| votjakovr | HeikoS: i've just sent a PR, please have a look at it | 19:58 |
| pickle27 | lisitsyn: nvm the ICA methods are just vanilla converters now | 20:02 |
| -!- shogun-notifier- [~irker@7nn.de] has joined #shogun | 20:03 | |
| shogun-notifier- | shogun: Roman Votyakov :develop * a70e031 / src/shogun/ (6 files): https://github.com/shogun-toolbox/shogun/commit/a70e031e8f4f510693a8844837be9726d53a01be | 20:03 |
| shogun-notifier- | shogun: add evaluate_log_probabilities() method for CLikelihoodModel class | 20:03 |
| shogun-notifier- | shogun: Heiko Strathmann :develop * d602f99 / src/shogun/ (6 files): https://github.com/shogun-toolbox/shogun/commit/d602f99c95586016c0c827f50a659986498ed19b | 20:03 |
| shogun-notifier- | shogun: Merge pull request #1218 from votjakovr/feature/gp_refactoring | 20:03 |
| shogun-notifier- | shogun: | 20:03 |
| shogun-notifier- | shogun: add evaluate_log_probabilities() method for CLikelihoodModel class | 20:03 |
| @HeikoS | votjakovr: cool! | 20:03 |
| @HeikoS | votjakovr: how is the integral? | 20:03 |
| @sonney2k | HeikoS, no need for a smiley here. We should add a unit test and then sb. should rewrite this thing. | 20:04 |
| -!- sanyam [uid10602@gateway/web/irccloud.com/x-bxwsbyychdryheqd] has joined #shogun | 20:05 | |
| @HeikoS | sonney2k: yeah rewrite should be best, unit test might be hard to do since implementations might differ, I would rather do this after the rewrite | 20:05 |
| votjakovr | HeikoS: not ready yet, but i'd like to send another PR with probit | 20:05 |
| @HeikoS | votjakovr: go ahead, I will leave soon though | 20:05 |
| lisitsyn | pickle27: sorry got distracted - preparing for my flight tomorrow | 20:06 |
| pickle27 | np! | 20:06 |
| pickle27 | lisitsyn: We can discuss more later, also I should have the first PR for the ICA algs soon ish (maybe not until tomorrow or so) | 20:06 |
| @HeikoS | sonney2k: thats a good task for someone who is interested in hacking shogun | 20:06 |
| @HeikoS | maybe we can recruit someebody at the workshop | 20:07 |
| votjakovr | HeikoS: may i add also logit with 3 unimplemented methods? | 20:07 |
| @HeikoS | votjakovr: yep thats fine, as long as you implement and test them in the near future | 20:07 |
| votjakovr | HeikoS: ok | 20:08 |
| @sonney2k | HeikoS, I would not change the implementation though. This is like 5 functions in one so a cleanup would help | 20:09 |
| naywhayare | sonney2k: HeikoS: are you interested in a patch when we dig to the bottom of the issue, or are you planning on a complete rewrite (so a patch is not relevant)? | 20:09 |
| @HeikoS | sonney2k: yeah maybe | 20:10 |
| @sonney2k | naywhayare, we are interested in a patch | 20:10 |
| -!- zxtx [~zv@rrcs-74-62-200-195.west.biz.rr.com] has quit [Ping timeout: 264 seconds] | 20:10 | |
| @sonney2k | I am not a big fan of rewrites (that will never happen) | 20:10 |
| @HeikoS | yes like cleanup and expose cluster centres | 20:10 |
| naywhayare | sonney2k: okay. I don't know when either marcus or I will figure it out; this is difficult code to read and we're not familiar with the shogun design ideas :) | 20:11 |
| naywhayare | sonney2k: but I am beginning to understand what's going on so sooner or later I will get somewhere... :) | 20:11 |
| @sonney2k | naywhayare, this is pre-shogun code | 20:11 |
| @sonney2k | some research code from the last century | 20:11 |
| naywhayare | sonney2k: haha, really from the 90s? | 20:11 |
| naywhayare | wow | 20:12 |
| naywhayare | it has lasted quite a while :) | 20:12 |
| @sonney2k | ahh what am I saying millenioum | 20:12 |
| naywhayare | both are true :) | 20:12 |
| @sonney2k | yeah I 'rescued' it into shogun. at some point I understood it all but now I do regret that I didn't polish it when I did | 20:13 |
| naywhayare | when I took over mlpack development some years ago it had previously been done by a bunch of people who were interested in publishing papers and not code, so absolutely nothing was polished | 20:14 |
| @sonney2k | naywhayare, I think there are like 3-5 massacre classes in shogun. one is CHMM, then the legacy structured output code, kmeans and yay our string kernels :) | 20:14 |
| @HeikoS | sonney2k: there is also this EM thing somewhere ;) | 20:14 |
| @sonney2k | naywhayare, so then you know how it is | 20:14 |
| naywhayare | heh... I know how reading those goes... | 20:14 |
| @sonney2k | HeikoS, but that is 'new' GSoC code | 20:14 |
| naywhayare | yeah; when I discovered the executable that ran nearest neighbors, I noticed that the genius who wrote it did not give an option for the results to be saved | 20:15 |
| naywhayare | so the method would run on the dataset of your choice, complete the calculation, then exit, trashing the results | 20:15 |
| naywhayare | who needs results anyway? </sarcasm> | 20:15 |
| @sonney2k | naywhayare, well actually shogun started out as my student research project | 20:15 |
| @sonney2k | IIRC 1999 with an HMM | 20:15 |
| @sonney2k | I wrote | 20:15 |
| naywhayare | it must be neat having seen it come such a long way | 20:15 |
| @sonney2k | back then it was very readable code | 20:15 |
| @sonney2k | until it got some treats (parallelized and future massacred) | 20:16 |
| naywhayare | I've avoided parallelization to some extent because of the nightmare it makes code into | 20:16 |
| @sonney2k | the svm framework & kernels were done in 2000 | 20:16 |
| @sonney2k | and I basicaly wrote all code in trains | 20:16 |
| @sonney2k | (I had 7hr train rides back then) | 20:17 |
| @sonney2k | twice a week | 20:17 |
| naywhayare | wow, that is a serious commute | 20:17 |
| @sonney2k | naywhayare, well we already ran it on some alpha cluster in 2000 | 20:18 |
| @sonney2k | distributed on > 100 CPUs | 20:18 |
| naywhayare | wow, alpha, I don't think you can even find those anymore | 20:18 |
| @sonney2k | no but they were fast | 20:18 |
| shogun-buildbot | build #1213 of bsd1 - libshogun is complete: Failure [failed test] Build details are at http://www.shogun-toolbox.org/buildbot/builders/bsd1%20-%20libshogun/builds/1213 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com> | 20:18 |
| @sonney2k | and the cluster was fresh and empty and to our disposal | 20:18 |
| naywhayare | convenient :) | 20:19 |
| @sonney2k | so I trained thousands of HMMs | 20:19 |
| @sonney2k | and later SVMs utilizing a kernel that was computed on HMMs on-the-fly | 20:19 |
| @sonney2k | requiring lots of memory | 20:19 |
| @sonney2k | I am glad to say that we have come a long way and I am not sure this code is even useful nowadays | 20:20 |
| naywhayare | now I know a lot about the history of shogun. :) also, I would not be surprised if someone out there is using your HMM code | 20:23 |
| naywhayare | there is kind of a lack of HMM C++ code out there | 20:24 |
| votjakovr | HeikoS: i've sent | 20:24 |
| naywhayare | there's HTK but last I checked it won't even compile on amd64 | 20:24 |
| @HeikoS | votjakovr: reading :) | 20:24 |
| shogun-buildbot | build #1009 of cyg1 - libshogun is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/1009 | 20:25 |
| @sonney2k | naywhayare, yeah but we lost multithreading during some refactoring (yes it was even more messy before!) | 20:25 |
| shogun-buildbot | build #1010 of cyg1 - libshogun is complete: Failure [failed configure] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/1010 blamelist: Roman Votyakov <votjakovr@gmail.com> | 20:25 |
| @sonney2k | naywhayare, ohh and the first name of shogun was 'gf' for genefinder | 20:26 |
| pickle27 | naywhayare: totally agree, there is lacking HMM c++ code and examples | 20:26 |
| @sonney2k | this thing became pretty big before gee eff got a real name | 20:26 |
| -!- zxtx [~zv@rrcs-76-79-81-162.west.biz.rr.com] has joined #shogun | 20:26 | |
| @sonney2k | and we started with the cmdline itnerface then matlab | 20:27 |
| @sonney2k | cmdline for running things on the cluster and matlab to try things out | 20:27 |
| @sonney2k | but then I just tried out swig for fun and I got addicted to python | 20:27 |
| @sonney2k | so that's it | 20:28 |
| shogun-notifier- | shogun: Roman Votyakov :develop * 3641eb7 / / (10 files): https://github.com/shogun-toolbox/shogun/commit/3641eb7eb626541c65cb2055524ec330fc53eaad | 20:28 |
| shogun-notifier- | shogun: add probit and logit likelihood models | 20:28 |
| shogun-notifier- | shogun: Heiko Strathmann :develop * 330626c / / (10 files): https://github.com/shogun-toolbox/shogun/commit/330626ce0556f4f755a1ddc51ac4a8674499ba17 | 20:28 |
| shogun-notifier- | shogun: Merge pull request #1219 from votjakovr/feature/gp_binary_classification | 20:28 |
| shogun-notifier- | shogun: | 20:28 |
| shogun-notifier- | shogun: add probit and logit likelihood models | 20:28 |
| @HeikoS | ladies and gentlemen, we have the first binary GP classifier :) | 20:28 |
| votjakovr | Yeah :) | 20:28 |
| @sonney2k | naywhayare, hardcore hackers like lisitsyn, HeikoS and all our gsoc'ers and bug reporters did the rest | 20:28 |
| @HeikoS | yeah :) | 20:28 |
| shogun-buildbot | build #1214 of bsd1 - libshogun is complete: Failure [failed test] Build details are at http://www.shogun-toolbox.org/buildbot/builders/bsd1%20-%20libshogun/builds/1214 blamelist: Roman Votyakov <votjakovr@gmail.com> | 20:28 |
| @sonney2k | votjakovr, HeikoS, lisitsyn vodka for everyone! | 20:28 |
| gsomix_ | good evening | 20:29 |
| @sonney2k | gsomix_, still in train? | 20:29 |
| naywhayare | :) | 20:29 |
| -!- gsomix_ is now known as gsomix | 20:29 | |
| @sonney2k | gsomix, your keyword ;) | 20:29 |
| gsomix | sonney2k, nope. I will be in the train tomorrow. | 20:29 |
| lisitsyn | gsomix: are you in train already? | 20:29 |
| @HeikoS | votjakovr: nice, I will use this for the workshop if I can get a graphical example running | 20:29 |
| lisitsyn | ah | 20:29 |
| @HeikoS | gotta go, bye all! | 20:29 |
| pickle27 | later! | 20:29 |
| @sonney2k | gsomix, could you please not use fgets instead of getline to fix the bsd1 buildbot failure | 20:29 |
| pickle27 | also unfortunately I won't be joining for the workshop | 20:30 |
| gsomix | sonney2k, of course. preparing PR. | 20:30 |
| pickle27 | too expensive, maybe next year! (hoping I can get my future employer to pick up the tab!) | 20:30 |
| @sonney2k | naywhayare, ohh btw I tried hard to merge collaborate with others but shogun was already too big (and the other projects too) so I think the destiny will be 1000 ml toolboxes or whatever | 20:30 |
| @sonney2k | pickle27, wiking has set up some live stream | 20:31 |
| @sonney2k | pickle27, I mean will be setting up | 20:31 |
| pickle27 | excellent! | 20:31 |
| @sonney2k | and we will have recordings of the talks | 20:31 |
| naywhayare | sonney2k: I had the same thoughts early on -- why not merge with something else? -- but then I thought that everyone taking different approaches is not a bad thing | 20:31 |
| @sonney2k | to be put on youtube | 20:31 |
| @sonney2k | seems like 1080p even | 20:31 |
| naywhayare | the general community that you have set up through MLOSS is a great thing though | 20:31 |
| pickle27 | awesome I will deffs watch! | 20:31 |
| naywhayare | some amount of collaboration between libraries is definitely useful, especially in interchangeable formats, etc. | 20:31 |
| @sonney2k | naywhayare, well I wish it would be building blocks | 20:32 |
| @sonney2k | I mean some kind of general framework everyone could hook to | 20:32 |
| votjakovr | HeikoS: good:) So next step: finish numerical evaluation of integrals and implement missing logit and student's methods and then EP i think | 20:32 |
| pickle27 | yeah actually I had a random question about the ml community did anyone see that lib that Iglesiasg posted about | 20:32 |
| naywhayare | pickle27: I heard about it once | 20:32 |
| @sonney2k | naywhayare, yeah data formats... mldata was my attempt on that but I see some patterns evolving but much much slower than I expected | 20:32 |
| pickle27 | seems like a waste of duplicated effort is all | 20:33 |
| naywhayare | pickle27: thanks ;) | 20:33 |
| @HeikoS | votjakovr: go for it, this is really good stuff, looking forward to the other things :) | 20:33 |
| @sonney2k | pickle27, naywhayare is the author of mlpack (or one of the...) | 20:33 |
| pickle27 | haha oops! | 20:33 |
| @sonney2k | pickle27, naywhayare but I think so too | 20:33 |
| @HeikoS | votjakovr: ok running now, bye! | 20:33 |
| naywhayare | pickle27: it's okay :). mlpack focuses on different things than shogun does | 20:34 |
| pickle27 | well I was basically wondering if we talk to them at all so there is my answer | 20:34 |
| @sonney2k | I would join some other projects and not start a new one nowadays | 20:34 |
| votjakovr | HeikoS: see you | 20:34 |
| pickle27 | yeah I hadn't looked into it | 20:34 |
| naywhayare | the focus is tree-based algorithms | 20:34 |
| @sonney2k | naywhayare, well I hope so :) | 20:34 |
| pickle27 | its good that we talk! | 20:34 |
| @sonney2k | yeah we have 2 trees in here | 20:34 |
| -!- HeikoS [~heiko@nat-166-97.internal.eduroam.ucl.ac.uk] has quit [Quit: Leaving.] | 20:34 | |
| @sonney2k | one for string kernels | 20:34 |
| @sonney2k | and covertree | 20:35 |
| naywhayare | the cover tree code is just jl's horrendous ugly code wrapped though | 20:35 |
| naywhayare | what a nightmare that code is | 20:35 |
| @sonney2k | exactly like k-means :) | 20:35 |
| naywhayare | haha | 20:35 |
| @sonney2k | written by geniouses though | 20:35 |
| naywhayare | definitely :) | 20:35 |
| naywhayare | I met jl at ICML last week. interesting guy, maybe a bit eccentric | 20:35 |
| @sonney2k | naywhayare, yeah I know him well. | 20:36 |
| @sonney2k | he was mentoring for shogun even | 20:36 |
| naywhayare | I didn't know that he was involved with shogun | 20:36 |
| @sonney2k | naywhayare, we tried to interface somehow | 20:36 |
| @sonney2k | basically the streaming features in shogun are the result of this | 20:37 |
| @sonney2k | unfortunately we didn't have unit tests back then | 20:37 |
| @sonney2k | and our integration tests were b0rken / disabled | 20:37 |
| naywhayare | oh, so this was a collaboration between shogun and VW? or was this before then | 20:37 |
| @sonney2k | so some refactoring killed halve the code | 20:37 |
| @sonney2k | exactly | 20:38 |
| @sonney2k | nowadays we would do it differently | 20:38 |
| @sonney2k | rather use VW as a library | 20:38 |
| @sonney2k | I mean have a student design soem clean interfaces to VW | 20:38 |
| @sonney2k | and then use it as lib | 20:38 |
| naywhayare | right | 20:38 |
| @sonney2k | which we didn't back then | 20:38 |
| @sonney2k | and the student disappeared an no one picked up | 20:39 |
| @sonney2k | problem with online learnign is that you need HUGE data sets | 20:39 |
| naywhayare | huge as in GB or as in TB? | 20:39 |
| @sonney2k | as in TB | 20:39 |
| naywhayare | oye, that gets to be a bit frustrating to deal with | 20:40 |
| @sonney2k | no I mean it will work with GB's too | 20:40 |
| @sonney2k | but with GB's you can still use batch and get more reliable results | 20:40 |
| naywhayare | ah, okay; even so, once you exceed the limit of the RAM things you have to rewrite to account for that | 20:40 |
| naywhayare | although I did have an idea recently; I wonder if it's in use anywhere: use mmap() to get a double* to your raw packed data matrix on disk, then wrap a matrix around that memory pointer, and let the OS handle smartly accessing it | 20:41 |
| @sonney2k | naywhayare, yeah but with shogun we tried to stretch that limit as far as possible by having all the native data representations | 20:41 |
| naywhayare | it wouldn't be optimal but it sure would be easy | 20:41 |
| @sonney2k | naywhayare, yeah I mmap'd in shogun too (and IIRC python numpy has that too) | 20:41 |
| @sonney2k | but it is rather not doing the trick | 20:42 |
| @sonney2k | it is easy access though | 20:42 |
| @sonney2k | you need some clever memory access pattern | 20:42 |
| @sonney2k | some kind of mini batch | 20:42 |
| naywhayare | yeah, it's definitely not the smartest way to do that. but you could do it and pester the OS guys to make it faster :) | 20:43 |
| lisitsyn | sonney2k: have you prepared your talk? | 20:43 |
| @sonney2k | so load batches of data that fit in memory do some heavy stuff etc | 20:43 |
| @sonney2k | lisitsyn, you are right | 20:43 |
| @sonney2k | not at all :/ | 20:43 |
| lisitsyn | sonney2k: the same here *crying* | 20:43 |
| @sonney2k | naywhayare, no it is not possible | 20:43 |
| lisitsyn | I depart tomorrow AAAAA | 20:43 |
| shogun-buildbot | build #1335 of deb3 - modular_interfaces is complete: Failure [failed compile csharp_modular] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/1335 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com> | 20:43 |
| @sonney2k | lisitsyn, ohh man then hurry up! or do it in the plane/airport... | 20:44 |
| lisitsyn | sonney2k: it is mostly on paper already | 20:44 |
| lisitsyn | time to convert it to impress.js | 20:44 |
| naywhayare | :) | 20:44 |
| @sonney2k | naywhayare, mmap is fast but you need a lot of virtual memory (swap!) | 20:44 |
| naywhayare | true | 20:45 |
| @sonney2k | naywhayare, back in 2000 I had some RealFileFeatures (as they were called in shogun) which did some caching / reading from disk of features | 20:45 |
| @sonney2k | damn they even exist today | 20:45 |
| @sonney2k | something to be removed :) | 20:46 |
| @sonney2k | so we did the caching of vectors manually | 20:46 |
| naywhayare | there was someone in our lab who had refactored mlpack to read from databases; but he never once talked to me about it and graduated and I never heard about it again | 20:46 |
| @sonney2k | I guess mmap does it much better for random access patterns (though needing swap) | 20:46 |
| naywhayare | so I'm not actually sure if he ever did it or if his committee was asleep | 20:47 |
| @sonney2k | yeah I've seen papers about people doing SVMs directly from databases | 20:47 |
| @sonney2k | heh | 20:47 |
| @sonney2k | naywhayare, the biggest problem with any mloss project is to keep it alive and to get contributors | 20:51 |
| pickle27 | how would one run a single unit test? | 20:51 |
| @sonney2k | naywhayare, that is if you are not a professor and have a team of students working on this (e.g. Weka, libsvm, liblinear, ...) | 20:51 |
| @sonney2k | pickle27, you need to set some environment varialbe IIRC GTEST_FILTER | 20:52 |
| @sonney2k | pickle27, google for it | 20:52 |
| pickle27 | kk | 20:52 |
| @sonney2k | votjakovr, do you already have an example for using GPC? | 20:54 |
| shogun-buildbot | build #1215 of bsd1 - libshogun is complete: Failure [failed test] Build details are at http://www.shogun-toolbox.org/buildbot/builders/bsd1%20-%20libshogun/builds/1215 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, Roman Votyakov <votjakovr@gmail.com> | 20:54 |
| naywhayare | sonney2k: this is true. I have a lot of trouble finding the time to balance both my research and mlpack | 20:54 |
| naywhayare | but, the library is starting to get some momentum, and with GSoC it may find its feet | 20:55 |
| votjakovr | sonney2k: yep, but i need to polish it | 20:55 |
| @sonney2k | naywhayare, I know exactly what you are talking about... | 20:56 |
| pickle27 | I have a lot of respect for researchers who also maintain open libs of their code | 20:57 |
| -!- travis-ci [~travis-ci@ec2-54-235-27-28.compute-1.amazonaws.com] has joined #shogun | 20:58 | |
| travis-ci | [travis-ci] it's Heiko Strathmann'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/8856960 | 20:58 |
| -!- travis-ci [~travis-ci@ec2-54-235-27-28.compute-1.amazonaws.com] has left #shogun [] | 20:58 | |
| lisitsyn | pickle27: run it with | 20:59 |
| lisitsyn | --gtest-filter=Something | 20:59 |
| pickle27 | run what exactly? i tried make unit-tests --gtest-filter=Jade and it said unrecognized option | 21:00 |
| votjakovr | sonney2k: hmm, c# modular is failed again... | 21:00 |
| lisitsyn | pickle27: not make | 21:00 |
| lisitsyn | ./shogun-unit-test --gtest-filter=Jade | 21:00 |
| pickle27 | kk | 21:00 |
| votjakovr | sonney2k: i'm not sure, but i think, because there are 2 SGVectors in parameters of a function | 21:02 |
| lisitsyn | votjakovr: yes your guess is right | 21:02 |
| shogun-buildbot | build #1011 of cyg1 - libshogun is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/1011 | 21:03 |
| @sonney2k | votjakovr, then please add them to modshogun_ignores.i | 21:05 |
| @sonney2k | votjakovr, in the very same way I did it last time - you will find your mean_* in there | 21:05 |
| @sonney2k | and send a PR | 21:05 |
| shogun-buildbot | build #1336 of deb3 - modular_interfaces is complete: Failure [failed compile csharp_modular] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/1336 blamelist: Roman Votyakov <votjakovr@gmail.com> | 21:06 |
| -!- travis-ci [~travis-ci@ec2-54-226-19-153.compute-1.amazonaws.com] has joined #shogun | 21:08 | |
| travis-ci | [travis-ci] it's Heiko Strathmann'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/8857853 | 21:08 |
| -!- travis-ci [~travis-ci@ec2-54-226-19-153.compute-1.amazonaws.com] has left #shogun [] | 21:08 | |
| votjakovr | sonney2k: ok, i'll do it | 21:10 |
| shogun-buildbot | build #1337 of deb3 - modular_interfaces is complete: Failure [failed compile csharp_modular] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/1337 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, Roman Votyakov <votjakovr@gmail.com> | 21:12 |
| van51 | sonney2k: ping | 21:23 |
| van51 | sonney2k: I had to make some changes to StreamingFileFromStringFeatures to get it working | 21:24 |
| van51 | sonney2k: should I make a different PR for those? | 21:24 |
| @sonney2k | van51, yes please | 21:26 |
| pickle27 | lisitsyn: do I need to do anything for my code to become part of the wrappers? | 21:27 |
| lisitsyn | pickle27: yes | 21:27 |
| pickle27 | what do I need to do? | 21:27 |
| lisitsyn | pickle27: I guess you want to make your class visible in swig interfaces, right? | 21:28 |
| pickle27 | yeah | 21:28 |
| lisitsyn | pickle27: check interfaces/Converter.i | 21:28 |
| pickle27 | kk | 21:28 |
| lisitsyn | and interfaces/Converter_includes.i | 21:28 |
| lisitsyn | pickle27: just add similar includes | 21:28 |
| lisitsyn | one there and one here | 21:28 |
| @sonney2k | van51, btw we should expose your new classes to python/csharp etc too | 21:31 |
| @sonney2k | very easy though | 21:31 |
| van51 | sonney2k: I made the PR | 21:32 |
| van51 | sonney2k: sure.. is there something I can look at to get an idea of how to do it? | 21:32 |
| shogun-notifier- | shogun: van51 :develop * 2279539 / src/shogun/io/streaming/StreamingFileFromStringFeatures.h: https://github.com/shogun-toolbox/shogun/commit/22795395075fd3f9562211c08b453f623e193800 | 21:33 |
| shogun-notifier- | shogun: Changes in StreamingFileFromStringFeatures to make it work | 21:33 |
| shogun-notifier- | shogun: Soeren Sonnenburg :develop * 7862aad / src/shogun/io/streaming/StreamingFileFromStringFeatures.h: https://github.com/shogun-toolbox/shogun/commit/7862aadc7aef77608fe4aecd2e7027ea58612411 | 21:33 |
| shogun-notifier- | shogun: Merge pull request #1220 from van51/develop | 21:33 |
| shogun-notifier- | shogun: | 21:33 |
| shogun-notifier- | shogun: Changes in StreamingFileFromStringFeatures to make it work | 21:33 |
| van51 | sonney2k: good.. took me some time to find what was wrong there :/ | 21:34 |
| @sonney2k | van51, per class taht you want to expose it is adding 3 lines to .i files in shogun/src/interfaces/modular/ | 21:34 |
| @sonney2k | van51, these features need to use SGVector | 21:34 |
| @sonney2k | van51, they are from the dawn of ages | 21:34 |
| van51 | sonney2k: the streaming features? | 21:34 |
| @sonney2k | I mean before we had refcounted sgvector | 21:34 |
| @sonney2k | yeah | 21:34 |
| pickle27 | lisitsyn: I just made a PR for ICA with Jade | 21:35 |
| @sonney2k | so the problem now is that they don't de-alloc memory or do twice bah! | 21:35 |
| van51 | sonney2k: ah ok, I thought you were saying I should switch to returning a SGVector instead of a SGSparseVector | 21:35 |
| @sonney2k | van51, no | 21:35 |
| van51 | sonney2k: yea it was really frustrating | 21:35 |
| @sonney2k | van51, look at e.g. Clustering.i | 21:36 |
| lisitsyn | pickle27: nice I'll check | 21:36 |
| @sonney2k | and then KMeans | 21:36 |
| @sonney2k | pickle27, that is also answering your question :) | 21:36 |
| @sonney2k | so CKMeans gets renamed to KMeans in e.g. python | 21:37 |
| @sonney2k | and you need the %include to get the class wrapped | 21:37 |
| @sonney2k | then there is a Clustering_includes.i file | 21:38 |
| @sonney2k | where Kmeans is regularly #included | 21:38 |
| @sonney2k | that's all | 21:38 |
| shogun-buildbot | build #1012 of cyg1 - libshogun is complete: Failure [failed configure] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/1012 blamelist: van51 <vangelis_51@hotmail.com> | 21:38 |
| van51 | sonney2k: ok. I'll add it to my todo list :) | 21:39 |
| van51 | sonney2k: I want to get done with the streaming features today | 21:39 |
| @sonney2k | van51, pickle27 now any type that returns an SGVector or other SG* datatype or gets it as argument is wrapped to the native' lang's representation | 21:39 |
| @sonney2k | for example in octave or python a SGMatrix would be mapped to a matrix or numpy array | 21:39 |
| @sonney2k | van51, yeah it is trivial anyways | 21:39 |
| shogun-buildbot | build #1216 of bsd1 - libshogun is complete: Failure [failed test] Build details are at http://www.shogun-toolbox.org/buildbot/builders/bsd1%20-%20libshogun/builds/1216 blamelist: van51 <vangelis_51@hotmail.com> | 21:46 |
| pickle27 | Im trying a build of the python modular now lets see how it works! | 21:49 |
| votjakovr | \names | 21:52 |
| votjakovr | oops | 21:52 |
| votjakovr | sonney2k: i've just sent a PR | 21:52 |
| -!- iglesiasg [~Fernando@s83-179-44-135.cust.tele2.se] has joined #shogun | 21:53 | |
| -!- mode/#shogun [+o iglesiasg] by ChanServ | 21:53 | |
| shogun-notifier- | shogun: Roman Votyakov :develop * a8efb26 / src/interfaces/modular/ (3 files): https://github.com/shogun-toolbox/shogun/commit/a8efb2627df57ff67b8557d32adf552f82907371 | 21:54 |
| shogun-notifier- | shogun: add swig interfaces for GPC and update ignore list for c# modular | 21:54 |
| shogun-notifier- | shogun: Soeren Sonnenburg :develop * c80366d / src/interfaces/modular/ (3 files): https://github.com/shogun-toolbox/shogun/commit/c80366d5a23082baa6a0932ff82035ddeef4cd7e | 21:54 |
| shogun-notifier- | shogun: Merge pull request #1222 from votjakovr/develop | 21:54 |
| shogun-notifier- | shogun: | 21:54 |
| shogun-notifier- | shogun: add swig interfaces for GPC and update ignore list for c# modular | 21:54 |
| @iglesiasg | hi all | 21:54 |
| @sonney2k | votjakovr, excellent! | 21:54 |
| @sonney2k | votjakovr, now if only the build would be back to green with that gp test... | 21:54 |
| @sonney2k | gsomix, and the bsd1 getline fgets... | 21:54 |
| @sonney2k | evening iglesiasg! | 21:55 |
| votjakovr | sonney2k: yep, but i still can't find what is actually wrong with it | 21:56 |
| @sonney2k | votjakovr, the only way to figure this out is figure out which change caused this | 21:58 |
| shogun-buildbot | build #1217 of bsd1 - libshogun is complete: Failure [failed test] Build details are at http://www.shogun-toolbox.org/buildbot/builders/bsd1%20-%20libshogun/builds/1217 blamelist: Soeren Sonnenburg <sonne@debian.org> | 21:58 |
| -!- travis-ci [~travis-ci@ec2-54-226-19-153.compute-1.amazonaws.com] has joined #shogun | 21:59 | |
| travis-ci | [travis-ci] it's Soeren Sonnenburg's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: http://travis-ci.org/shogun-toolbox/shogun/builds/8860165 | 21:59 |
| -!- travis-ci [~travis-ci@ec2-54-226-19-153.compute-1.amazonaws.com] has left #shogun [] | 21:59 | |
| lisitsyn | iglesiasg: hey | 21:59 |
| @iglesiasg | lisitsyn: how is it going with the slides? | 22:00 |
| lisitsyn | iglesiasg: terrible :D | 22:00 |
| @iglesiasg | I don't believe that! | 22:00 |
| lisitsyn | iglesiasg: I am htmling them now | 22:01 |
| @iglesiasg | lisitsyn: I bet they will look superb, looking forward to seeing them | 22:02 |
| lisitsyn | iglesiasg: I have procrastinated too much | 22:02 |
| @sonney2k | lisitsyn, can you do mine too :) | 22:02 |
| pickle27 | hey guys 2 things | 22:03 |
| @sonney2k | I don't care if it is via procrastination or anything | 22:03 |
| @iglesiasg | sonney2k: you must be a professional already doing slides :) | 22:03 |
| lisitsyn | sonney2k: I will not be in time | 22:03 |
| pickle27 | first there is a prob in develop with Logit but Im sure you knew that | 22:03 |
| lisitsyn | like before flight :) | 22:03 |
| @sonney2k | iglesiasg, that doesn't make it more interesting | 22:03 |
| @sonney2k | lisitsyn, me neither | 22:03 |
| pickle27 | second what is the difference between the doc and undoc examples exactly? | 22:03 |
| shogun-buildbot | build #1338 of deb3 - modular_interfaces is complete: Failure [failed compile csharp_modular] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/1338 blamelist: van51 <vangelis_51@hotmail.com> | 22:03 |
| lisitsyn | sonney2k: but you won't take a flight ;) | 22:03 |
| lisitsyn | pickle27: doc folder is autogenerated | 22:03 |
| @sonney2k | pickle27, documented examples are generated from undocumented ones | 22:04 |
| @sonney2k | and the descriptions | 22:04 |
| pickle27 | kk I thought thats what happened | 22:04 |
| @sonney2k | make examples does that | 22:04 |
| @sonney2k | pickle27, rationale is that you write an example in the 5 languages doing the same thing but document it just once | 22:04 |
| pickle27 | logit crashes travis before I can see if my unit test runs on travis :( | 22:05 |
| pickle27 | sonney2k: ooooh cool | 22:05 |
| @sonney2k | pickle27, blame votjakovr | 22:05 |
| pickle27 | votjakovr: ! lol | 22:05 |
| * sonney2k round 1 - fight! | 22:05 | |
| lisitsyn | AAAHH my plane is 13:50 UTC | 22:06 |
| lisitsyn | with crazy 1h transfer in SVO it must be funny hah | 22:07 |
| pickle27 | ha regretting that upstream merge now, I could have waited lol | 22:07 |
| @iglesiasg | lisitsyn: you are flying already tomorrow, aren't you? | 22:08 |
| lisitsyn | iglesiasg: yes | 22:08 |
| @sonney2k | iglesiasg, when are you? | 22:08 |
| lisitsyn | iglesiasg: in 17 hrs | 22:08 |
| shogun-buildbot | build #1013 of cyg1 - libshogun is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/1013 | 22:08 |
| @sonney2k | shogun-buildbot, dance | 22:09 |
| shogun-buildbot | <(^.^<) | 22:09 |
| @iglesiasg | lisitsyn: cool cool, will you be using there your current cell number? | 22:09 |
| shogun-buildbot | <(^.^)> | 22:09 |
| shogun-buildbot | (>^.^)> | 22:09 |
| shogun-buildbot | (7^.^)7 | 22:09 |
| shogun-buildbot | (>^.^<) | 22:09 |
| @iglesiasg | sonney2k: on Wednesday | 22:09 |
| @sonney2k | I am damn impressed that cyg1 is happy | 22:09 |
| lisitsyn | iglesiasg: not sure I will be using it heavily with its price | 22:09 |
| @iglesiasg | I see | 22:09 |
| lisitsyn | iglesiasg: wifi for the win (I hope) | 22:09 |
| @iglesiasg | then I will contact you through gtalk so we can meet on Thursday :) | 22:10 |
| lisitsyn | alright! | 22:10 |
| @iglesiasg | let's hope I share room with nice people :P | 22:10 |
| lisitsyn | iglesiasg: if wifi in the hotel is ok I will definitely be online some time morning and evening | 22:10 |
| lisitsyn | iglesiasg: hah I hope so too | 22:11 |
| lisitsyn | iglesiasg: when you're back to sweden? | 22:11 |
| @iglesiasg | lisitsyn: on Sunday | 22:11 |
| lisitsyn | I see | 22:11 |
| @sonney2k | lisitsyn, you too right? | 22:12 |
| lisitsyn | sonney2k: no I am departing monday morning | 22:13 |
| lisitsyn | like 8-50 or so | 22:13 |
| @sonney2k | iglesiasg, will you be at the hands on workshop on saturday/sunday? | 22:13 |
| lisitsyn | I guess I'd have to get up eeearrly | 22:13 |
| @iglesiasg | sonney2k: sure! | 22:13 |
| @sonney2k | lisitsyn, sxf or txl? | 22:13 |
| lisitsyn | sonney2k: sxf | 22:13 |
| @sonney2k | ohh man | 22:14 |
| @sonney2k | poor guy | 22:14 |
| @iglesiasg | sonney2k: will you be able to be a little bit there too any of those days? | 22:14 |
| @iglesiasg | IIRC last time I heard of you mentioned you wouldn't | 22:14 |
| lisitsyn | sonney2k: well I'll take taxi but I guess it is a hour still, right? | 22:14 |
| @iglesiasg | I heard of it* | 22:14 |
| @sonney2k | well I am away wednesday,thursday,friday for the workshop | 22:14 |
| @sonney2k | yeah on friday | 22:14 |
| @sonney2k | lisitsyn, $$$ | 22:14 |
| @iglesiasg | sonney2k: but no Saturday nor Sunday? | 22:15 |
| lisitsyn | sonney2k: 38 euro according to the website? | 22:15 |
| @sonney2k | maybe a little bit of saturday | 22:15 |
| @iglesiasg | nice | 22:15 |
| @sonney2k | but I will be dead | 22:15 |
| @iglesiasg | sonney2k: is it SXF so bad? I read on the website it didn't take that long to the city centre | 22:15 |
| @sonney2k | a bit too much | 22:15 |
| @iglesiasg | not that long ~ less than one hour | 22:15 |
| @sonney2k | no it is ok | 22:15 |
| @iglesiasg | in public transportation I am talking about | 22:16 |
| @sonney2k | but you have to walk 10 mins to the s-bahn station | 22:16 |
| lisitsyn | it takes a few hops to my hotel from SXF | 22:16 |
| @sonney2k | one cannot miss it though there is just one way to walk to | 22:16 |
| @iglesiasg | I really have to check how to download the map of the city in my phone before going! | 22:16 |
| @sonney2k | iglesiasg, android? | 22:16 |
| @sonney2k | long press | 22:16 |
| @sonney2k | then download | 22:16 |
| @iglesiasg | sonney2k: long press in google maps pointing at Berlin? | 22:17 |
| @iglesiasg | yes, android | 22:17 |
| @sonney2k | yes | 22:17 |
| @iglesiasg | oh cool, it sounds easy enough | 22:18 |
| @sonney2k | iglesiasg, actually no | 22:18 |
| @sonney2k | iglesiasg, just menu | 22:18 |
| @sonney2k | then download for offline use | 22:18 |
| @iglesiasg | I am reading http://www.google.com/help/maps/helloworld/tips/travel.html | 22:18 |
| @sonney2k | iglesiasg, lisitsyn weather is supposed to be very nice | 22:20 |
| lisitsyn | that's indeed cool | 22:20 |
| @sonney2k | like 25 C or so | 22:20 |
| @sonney2k | not too hot | 22:21 |
| @iglesiasg | yes! That sounds perfect | 22:21 |
| shogun-buildbot | build #1339 of deb3 - modular_interfaces is complete: Failure [failed compile csharp_modular] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/1339 blamelist: Soeren Sonnenburg <sonne@debian.org> | 22:21 |
| @iglesiasg | more than 25 gets close to 30 and #@%& hot | 22:21 |
| @iglesiasg | I wonder how I survived that many years in Spain :-O | 22:21 |
| @iglesiasg | nice that Germany is in the offline list | 22:22 |
| @iglesiasg | https://support.google.com/gmm/answer/2650347?hl=en&topic=2649131&ctx=topic# | 22:22 |
| @sonney2k | iglesiasg, at least you have sunlight in winter! | 22:22 |
| @iglesiasg | this year was pretty good in that matter here in Stockholm actually | 22:23 |
| @iglesiasg | lisitsyn: if it were in Russia or Spain we would be screwed -- no offline maps mode :S | 22:23 |
| @sonney2k | berlin had no sun the whole winter | 22:23 |
| -!- travis-ci [~travis-ci@ec2-54-235-60-251.compute-1.amazonaws.com] has joined #shogun | 22:23 | |
| travis-ci | [travis-ci] it's Soeren Sonnenburg's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: http://travis-ci.org/shogun-toolbox/shogun/builds/8860899 | 22:23 |
| -!- travis-ci [~travis-ci@ec2-54-235-60-251.compute-1.amazonaws.com] has left #shogun [] | 22:23 | |
| lisitsyn | iglesiasg: if it were in russia we all would be screwed | 22:23 |
| @iglesiasg | :DD | 22:24 |
| @iglesiasg | lisitsyn: more reasons other than the offline maps? | 22:24 |
| lisitsyn | iglesiasg: yes dangerous! | 22:25 |
| @sonney2k | what? | 22:25 |
| @sonney2k | having a phone or what? | 22:25 |
| lisitsyn | everything! | 22:25 |
| @sonney2k | to breathe? | 22:25 |
| lisitsyn | I bet an foreigner in real russia (not like the center of moscow) | 22:26 |
| lisitsyn | will be despoiled very fast | 22:26 |
| lisitsyn | :D | 22:26 |
| lisitsyn | like once they realize you have no idea where to go | 22:27 |
| shogun-notifier- | shogun: Roman Votyakov :develop * f8704e4 / src/shogun/machine/gp/LogitLikelihood.cpp: https://github.com/shogun-toolbox/shogun/commit/f8704e450763edd6734563b7d118bae1663545f6 | 22:27 |
| shogun-notifier- | shogun: fix bug in CLogitLikelihood class | 22:27 |
| shogun-notifier- | shogun: Soeren Sonnenburg :develop * 4e6e445 / src/shogun/machine/gp/LogitLikelihood.cpp: https://github.com/shogun-toolbox/shogun/commit/4e6e445f2e0004358ef7527a0ca1c236f614a1ea | 22:27 |
| shogun-notifier- | shogun: Merge pull request #1223 from votjakovr/develop | 22:27 |
| shogun-notifier- | shogun: | 22:27 |
| shogun-notifier- | shogun: fix bug in CLogitLikelihood class | 22:27 |
| @sonney2k | alright | 22:28 |
| * sonney2k ZZzz | 22:28 | |
| @iglesiasg | ok I am saving 82MB of Berlin, that should be enough! | 22:28 |
| lisitsyn | iglesiasg: I saved a bit too! | 22:28 |
| * iglesiasg is surprised all the stuff you get to do while compiling after rebase! | 22:29 | |
| shogun-buildbot | build #1218 of bsd1 - libshogun is complete: Failure [failed test] Build details are at http://www.shogun-toolbox.org/buildbot/builders/bsd1%20-%20libshogun/builds/1218 blamelist: Soeren Sonnenburg <sonne@debian.org>, Roman Votyakov <votjakovr@gmail.com> | 22:29 |
| pickle27 | ahhhhhh I have merge files in my git commit now | 22:50 |
| pickle27 | ah there we are | 22:51 |
| pickle27 | lisitsyn: pending travis success I think I might be good to merge the first ICA technique | 22:52 |
| pickle27 | lisitsyn: I am pretty happy with the current basic examples too! | 22:52 |
| lisitsyn | pickle27: I'll check it in a bit | 22:53 |
| pickle27 | yeah let Travis do his thing | 22:53 |
| shogun-buildbot | build #1219 of bsd1 - libshogun is complete: Failure [failed test] Build details are at http://www.shogun-toolbox.org/buildbot/builders/bsd1%20-%20libshogun/builds/1219 blamelist: Soeren Sonnenburg <sonne@debian.org>, Roman Votyakov <votjakovr@gmail.com> | 23:00 |
| shogun-buildbot | build #1340 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/1340 blamelist: Soeren Sonnenburg <sonne@debian.org>, Roman Votyakov <votjakovr@gmail.com> | 23:01 |
| lisitsyn | pickle27: alright looks nice! | 23:03 |
| lisitsyn | pickle27: thanks! | 23:03 |
| shogun-notifier- | shogun: Kevin :develop * e7f36b5 / / (7 files): https://github.com/shogun-toolbox/shogun/commit/e7f36b554a1e2061184e25ea75fe85ece6035401 | 23:03 |
| shogun-notifier- | shogun: added Jade algorithm for ICA and BSS along with a unit test and example | 23:03 |
| shogun-notifier- | shogun: Sergey Lisitsyn :develop * 20f94d3 / / (7 files): https://github.com/shogun-toolbox/shogun/commit/20f94d361fc821c13d031b34238c6dea7c029314 | 23:03 |
| shogun-notifier- | shogun: Merge pull request #1221 from pickle27/develop | 23:03 |
| shogun-notifier- | shogun: | 23:03 |
| shogun-notifier- | shogun: added Jade algorithm for ICA and BSS along with a unit test and example | 23:03 |
| pickle27 | lisitsyn: thanks! | 23:06 |
| van51 | question, suppose you have a PR standing by and things get merged in the meantime.. do that PR need to be rebased? :) | 23:10 |
| van51 | does* | 23:10 |
| @iglesiasg | hey hushell! I will have a look to the PR ASAP | 23:11 |
| @iglesiasg | some time tomorrow afternoon probably | 23:11 |
| @iglesiasg | hushell: you can continue working before we revise, right? | 23:11 |
| -!- travis-ci [~travis-ci@ec2-54-235-27-28.compute-1.amazonaws.com] has joined #shogun | 23:12 | |
| travis-ci | [travis-ci] it's Soeren Sonnenburg's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: http://travis-ci.org/shogun-toolbox/shogun/builds/8862057 | 23:12 |
| -!- travis-ci [~travis-ci@ec2-54-235-27-28.compute-1.amazonaws.com] has left #shogun [] | 23:12 | |
| pickle27 | van51: if you don't merge it into your own branch then you can just make a PR | 23:16 |
| pickle27 | but if you merge it in yourself then yes rebase | 23:17 |
| pickle27 | thats what I just had to do because I wanted to merge votjakovr latest PR to see if Travis would run | 23:17 |
| hushell | iglesiasg: thanks! yes, I can keep working on unit tests | 23:20 |
| hushell | iglesiasg: But I may not be able to finish all of them today, cause I have to prepare a presentation for tomorrow | 23:21 |
| @iglesiasg | hushell: sure, that's fine | 23:22 |
| van51 | pickle27: ok thanks :) | 23:22 |
| pickle27 | lisitsyn: woooo a clean build from my machine to the build bot! | 23:30 |
| pickle27 | http://shogun-toolbox.org/buildbot/builders/deb1%20-%20libshogun/builds/1414 | 23:30 |
| shogun-buildbot | build #1341 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/1341 blamelist: Soeren Sonnenburg <sonne@debian.org>, Roman Votyakov <votjakovr@gmail.com> | 23:30 |
| lisitsyn | pickle27: good! | 23:30 |
| pickle27 | lisitsyn: I trust you saw my mail today about the final example? | 23:31 |
| pickle27 | sonney2k seemed to think my modified idea would work | 23:31 |
| lisitsyn | pickle27: sorry I am a bit hectic last days | 23:32 |
| pickle27 | no worries! | 23:32 |
| shogun-buildbot | build #1220 of bsd1 - libshogun is complete: Failure [failed test] Build details are at http://www.shogun-toolbox.org/buildbot/builders/bsd1%20-%20libshogun/builds/1220 blamelist: Sergey Lisitsyn <lisitsyn.s.o@gmail.com>, Kevin <kevinhughes27@gmail.com> | 23:32 |
| pickle27 | hmm wut | 23:32 |
| pickle27 | I think this error is not from our merhe | 23:33 |
| pickle27 | lisitsyn: I'll probably spend the rest of this week porting the rest of the algorithms and then start on the example after everyone is done with the workshop | 23:34 |
| lisitsyn | pickle27: I am ok with the new approach yes | 23:35 |
| lisitsyn | just select a few tracks, mix then demix | 23:35 |
| pickle27 | yeah! | 23:35 |
| pickle27 | I'll try and pick some interesting tracks | 23:36 |
| lisitsyn | pickle27: something from venetian snares | 23:36 |
| lisitsyn | :D | 23:36 |
| lisitsyn | there is a nice album of venetian snares | 23:36 |
| pickle27 | haha maybe | 23:36 |
| lisitsyn | winnipeg is a frozen shitty hole or so | 23:36 |
| pickle27 | I was thinking more along the lines of mashing together movie quotes or something but music too | 23:37 |
| pickle27 | haha yeah winnipeg sucks! | 23:37 |
| lisitsyn | pickle27: is it really that bad? | 23:37 |
| pickle27 | I've actually never been there lol | 23:37 |
| lisitsyn | hahah | 23:37 |
| pickle27 | but I have been to Saskatchewan and it was fairly boring | 23:38 |
| naywhayare | lisitsyn: have you listened to Rossz Csillag Alatt Sz?letett? I enjoyed that album a lot (okay, I know this is off-topic...) | 23:41 |
| lisitsyn | naywhayare: yes sure, interesting thing | 23:41 |
| lisitsyn | naywhayare: are you into such IDM music? | 23:43 |
| lisitsyn | I am actually not but he got into my sight one day so I listened to it | 23:44 |
| lisitsyn | pickle27: so winnipeg should be boring but anything else? | 23:44 |
| -!- votjakovr [~votjakovr@host-46-241-3-209.bbcustomer.zsttk.net] has left #shogun ["Fallen asleep!"] | 23:44 | |
| lisitsyn | naywhayare: szamar madar is kind of classic! | 23:45 |
| naywhayare | :) | 23:47 |
| naywhayare | I am into IDM (although I think that's a stupid name for the genre) | 23:47 |
| naywhayare | I found the genre via Boards of Canada | 23:47 |
| pickle27 | naywhayare: are you Canadian? | 23:47 |
| naywhayare | nope, I'm in Atlanta | 23:48 |
| naywhayare | but I have been close to Canada before :) | 23:48 |
| pickle27 | cool | 23:50 |
| pickle27 | alright guys Im off to play some Frisbee, see you tomorrow! | 23:50 |
| -!- pickle27 [~Kevin@d67-193-243-174.home3.cgocable.net] has quit [Quit: Leaving] | 23:52 | |
| lisitsyn | ha! | 23:54 |
| --- Log closed Tue Jul 09 00:00:23 2013 | ||
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!