| --- Log opened Wed Jul 03 00:00:15 2013 | ||
| @iglesiasg | hey hushell, how is it going? | 00:00 |
|---|---|---|
| -!- iglesiasg [~iglesias@s83-179-44-135.cust.tele2.se] has quit [Quit: Leaving] | 00:40 | |
| -!- pickle27 [~Kevin@d67-193-243-174.home3.cgocable.net] has joined #shogun | 01:21 | |
| -!- hushell [~hushell@8-92.ptpg.oregonstate.edu] has quit [Ping timeout: 256 seconds] | 02:32 | |
| -!- wiking [~wiking@huwico/staff/wiking] has quit [Read error: Connection reset by peer] | 03:09 | |
| -!- wiking [~wiking@info2k1.hu] has joined #shogun | 03:10 | |
| -!- pickle27 [~Kevin@d67-193-243-174.home3.cgocable.net] has quit [Quit: Leaving] | 04:24 | |
| shogun-buildbot | build #446 of nightly_default is complete: Failure [failed test] Build details are at http://www.shogun-toolbox.org/buildbot/builders/nightly_default/builds/446 | 04:27 |
| -!- zxtx [~zv@rrcs-74-62-200-195.west.biz.rr.com] has quit [Read error: Operation timed out] | 04:38 | |
| -!- nube [~rho@49.244.47.218] has quit [Ping timeout: 252 seconds] | 04:48 | |
| -!- nube [~rho@116.90.239.3] has joined #shogun | 05:34 | |
| -!- nube [~rho@116.90.239.3] has quit [Client Quit] | 05:35 | |
| -!- nube1 [~rho@116.90.239.3] has joined #shogun | 05:35 | |
| -!- iglesiasg [~iglesias@s83-179-44-135.cust.tele2.se] has joined #shogun | 06:50 | |
| -!- mode/#shogun [+o iglesiasg] by ChanServ | 06:50 | |
| -!- gsomix [~gsomix@109.188.126.139] has joined #shogun | 07:03 | |
| gsomix | good morning | 07:04 |
| @iglesiasg | good morning | 07:05 |
| -!- iglesiasg [~iglesias@s83-179-44-135.cust.tele2.se] has quit [Quit: Leaving] | 07:24 | |
| -!- zxtx [~zv@cpe-76-166-29-100.socal.res.rr.com] has joined #shogun | 07:26 | |
| @sonney2k | gsomix, awake? | 07:55 |
| @sonney2k | gsomix, we were desperately looking for you yesterday | 07:55 |
| @sonney2k | gsomix, would be nice if you could make use of the delimitertokenizer such that we can finally merge your patch | 07:56 |
| gsomix | sonney2k, doing this thing now. | 08:03 |
| -!- zxtx [~zv@cpe-76-166-29-100.socal.res.rr.com] has quit [Read error: Operation timed out] | 08:07 | |
| gsomix | sonney2k, btw, should CircularBuffer be inheritor of the Tokenizer? | 08:11 |
| gsomix | it seems my buffer and tokenizer are doing the same thing, but buffer have additional functionality like data storage. | 08:12 |
| gsomix | hm, it's good idea, I think. doing that. | 08:22 |
| sonne|work | gsomix: hmmhh maybe not inherit but just get the tokenizer as argument | 08:23 |
| sonne|work | gsomix: go go :) | 08:23 |
| gsomix | sonne|work, I really like the Tokenizer interface, I want the same in my class :) | 08:24 |
| sonne|work | gsomix: yeah van51 write nicely readable code :) | 08:25 |
| -!- nube1 [~rho@116.90.239.3] has quit [Ping timeout: 256 seconds] | 08:36 | |
| -!- gsomix [~gsomix@109.188.126.139] has quit [Ping timeout: 256 seconds] | 08:58 | |
| -!- gsomix [~gsomix@109.188.126.139] has joined #shogun | 08:59 | |
| -!- zxtx [~zv@cpe-75-83-151-252.socal.res.rr.com] has joined #shogun | 09:14 | |
| -!- iglesiasg [~iglesias@s83-179-44-135.cust.tele2.se] has joined #shogun | 09:22 | |
| -!- mode/#shogun [+o iglesiasg] by ChanServ | 09:22 | |
| -!- nube [~rho@116.90.239.3] has joined #shogun | 09:22 | |
| -!- gsomix [~gsomix@109.188.126.139] has quit [Ping timeout: 246 seconds] | 09:29 | |
| -!- gsomix [~gsomix@109.188.127.26] has joined #shogun | 09:42 | |
| -!- lisitsyn [~lisitsin@mxs.kg.ru] has joined #shogun | 09:56 | |
| -!- votjakovr [~votjakovr@host-46-241-3-209.bbcustomer.zsttk.net] has joined #shogun | 09:59 | |
| gsomix | sonney2k, sonne|work almost things are done, but now I need go to zoo with gf :) | 10:17 |
| gsomix | interface of CircularBuffer looks very fine | 10:17 |
| gsomix | Tokenizer interface + push/pop (now with SGVectors - very fine and laconically) + decorates DelimiterTokenizer + set_tokenizer | 10:19 |
| sonne|work | gsomix: so now what? | 10:20 |
| gsomix | sonne|work, I need little modify my tokenize methods for finding N-char tokens in CircularBuffer. and then PR at evening. | 10:23 |
| sonne|work | n-char tokens? | 10:23 |
| gsomix | err, just tokens. :) CircularBuffer works fine for single delimiters now. DelimiterTokenizer allows to search tokens, but in CircularBuffer tokens can be situated from end of physical memory to begin. | 10:25 |
| gsomix | because of buffer is circular, hm | 10:26 |
| sonne|work | gsomix: it is sufficient that it works with delimitertokenizer | 10:28 |
| lisitsyn | sonne|work: is our MKL using ||w||=1 constraint? | 10:28 |
| sonne|work | lisitsyn: we can do any p-norm >=1 | 10:28 |
| lisitsyn | sonne|work: last mail in the mailing list | 10:29 |
| lisitsyn | he asked about norm regularizer | 10:29 |
| lisitsyn | instead of norm constraint | 10:29 |
| lisitsyn | or ivanov vs tikhonov as he said | 10:30 |
| gsomix | sonne|work, hm, I don't think so. look, buffer [' ','a','b',' ',' '], delimiter is ' ' (space) | 10:30 |
| sonne|work | lisitsyn: IIRC these formulations are equivalent | 10:30 |
| lisitsyn | sonne|work: in terms of math yes but numerically not I guess? | 10:31 |
| sonne|work | lisitsyn: I don't see why not optimum IIRC is always at the ||w||_p = 1 | 10:32 |
| sonne|work | gsomix: I dont' get what you mean | 10:32 |
| gsomix | sonne|work, for example buffer being is 'a' (buffer[1]) | 10:32 |
| gsomix | now I use DelimiterTokenizer for find tokens in parts buffer[1:5] and buffer[0:1] | 10:33 |
| gsomix | but token is continuous | 10:33 |
| gsomix | token is buffer[3:5]+buffer[0] | 10:33 |
| gsomix | I must take this into account. | 10:34 |
| sonne|work | gsomix: but why do you want to support more than a single char as delimiter? | 10:34 |
| gsomix | sonne|work, hm, interesting question. :) because of DelimiterTokenizer potential, I think. | 10:35 |
| gsomix | sonne|work, but I can support single delimiters, yep. | 10:36 |
| sonne|work | IMHO not essential | 10:37 |
| gsomix | then I need clean up code and send PR | 10:37 |
| sonne|work | we should rather speed up and support some file format | 10:37 |
| sonne|work | s | 10:37 |
| gsomix | sonne|work, ok, sorry. :( | 10:37 |
| gsomix | so, need to go, sorry twice | 10:38 |
| gsomix | cu at evening | 10:38 |
| -!- gsomix [~gsomix@109.188.127.26] has quit [Quit: Leaving] | 10:39 | |
| -!- nube [~rho@116.90.239.3] has quit [Quit: Leaving.] | 11:20 | |
| -!- nube [~rho@116.90.239.3] has joined #shogun | 11:21 | |
| -!- HeikoS [~heiko@nat-189-68.internal.eduroam.ucl.ac.uk] has joined #shogun | 12:01 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 12:01 | |
| votjakovr | HeikoS: hi! now i'm working again on refactoring: i think that it's better to create a methods like: get_posterior_means(features) and get_posterior_variances(features) in CGaussianProcessMachine class. These two methods will return mu and s2 from N(mu, s2), where N(mu, s2) approximates posterior p(f*|x*,x,y) | 12:09 |
| @HeikoS | votjakovr: hi! | 12:10 |
| @HeikoS | any problems with the old scheme? | 12:10 |
| @HeikoS | votjakovr: wait | 12:11 |
| @HeikoS | is this the conditioned GP | 12:11 |
| votjakovr | HeikoS: we will use these methods in classification and regression parts | 12:11 |
| @HeikoS | or the posterior (which is not always Gaussian) | 12:11 |
| -!- foulwall [~user@2001:da8:215:6100:1cf2:7cef:b86d:5a1b] has joined #shogun | 12:11 | |
| @HeikoS | votjakovr: p(f|y) not not always Gaussian | 12:12 |
| @HeikoS | for regression, it is | 12:12 |
| @HeikoS | for laplace approximation, it is | 12:13 |
| @HeikoS | but not otherwise | 12:13 |
| @HeikoS | not even for sparse regression with student -t likelihood | 12:13 |
| @HeikoS | votjakovr: on the other hand, gpml also does this | 12:14 |
| @HeikoS | votjakovr: maybe give it a try, we can change it later, it should not be too much work right? | 12:17 |
| -!- nube [~rho@116.90.239.3] has quit [Ping timeout: 246 seconds] | 12:17 | |
| @HeikoS | for EP, it will also work | 12:17 |
| @HeikoS | votjakovr: the only thing I am concerned about is then the posterior is actually not Gaussian. Then integrating over it for predictions will use different methods (for example sampling) and things wont be nicely unified anymore | 12:18 |
| @HeikoS | for std cases it should be fine and as said we can change it later | 12:18 |
| votjakovr | HeikoS: i mean mu from the 4th line, s2 from the 6th line of the algorithm 3.2, p. 44 | 12:28 |
| @HeikoS | i got a differen edition | 12:29 |
| @HeikoS | is this the prediction algorithm, votjakovr? | 12:29 |
| votjakovr | HeikoS: ohh, i'm sorry, not mu and s2, but f*- and V[f*] | 12:31 |
| votjakovr | HeikoS: yep | 12:31 |
| votjakovr | HeikoS: these two things i'd like to to have in GaussianMachine class | 12:32 |
| @HeikoS | votjakovr: as I said, this is fine, but only can be used if the posterior is Gaussian | 12:32 |
| @HeikoS | if we try to do exact inference, we cannot call these methods | 12:32 |
| @HeikoS | so it kind of depends on the inference method used, you see what I mean? | 12:32 |
| votjakovr | HeikoS: yep, totally | 12:33 |
| @HeikoS | line 7 of the algorithm, this Gaussian is not always a Gaussian | 12:33 |
| @HeikoS | so if the methods are in the GPmachine | 12:33 |
| @HeikoS | votjakovr: how do they compute the posterior? | 12:33 |
| @HeikoS | over which interfaces? | 12:33 |
| @HeikoS | votjakovr: I mean the way to solve this integral is inference method dependent | 12:38 |
| @HeikoS | votjakovr: however, please go ahead and do your changes, as for this project, all posterior GPs will be approximated by Gaussians :) | 12:38 |
| @HeikoS | we can do changes later | 12:38 |
| @HeikoS | this makes things easier | 12:39 |
| votjakovr | HeikoS: sure, it depends on inference method, but we can get cholesky, alpha and sqrt(W) from each inference method class and compute posterior | 12:41 |
| @HeikoS | votjakovr: again, that is only possible if the posterior is Gaussian, doesnt work for other forms | 12:42 |
| @HeikoS | we can only handle different Gaussians this way (i.e. Laplace, EP, and exact regression) | 12:44 |
| @HeikoS | but not posterior distributions which dont have a closed form expression | 12:44 |
| votjakovr | HeikoS: i agree | 12:44 |
| @HeikoS | votjakovr: but since the current framework is kind of based on only gaussians, lets stick with it for now | 12:44 |
| @HeikoS | votjakovr: we can later on think about more things, but first we need baseline methods, so do what you suggested :) | 12:45 |
| votjakovr | HeikoS: ok:) honestly, i didn't even think about non Gaussian posteriors | 12:47 |
| @HeikoS | votjakovr: keep in mind that it is *never* Gaussian if the likelihood is not ;) we are doing approximate inference here | 12:48 |
| @HeikoS | votjakovr: but one can also do exact things (which are slow usually) | 12:48 |
| votjakovr | HeikoS: yep, i knew that posterior is non Gaussian, when likelihood is not. But i didn't think about posterior distributions which dont have a closed form | 12:51 |
| votjakovr | expression | 12:51 |
| -!- iglesiasg [~iglesias@s83-179-44-135.cust.tele2.se] has quit [Quit: Ex-Chat] | 12:51 | |
| @HeikoS | votjakovr: this will be an issue after multiclass is finished, so a long way, how long do you think it will take for the logit one to be working? | 12:52 |
| votjakovr | HeikoS: i think, that i'll finish it today | 12:53 |
| @HeikoS | votjakovr: nice! | 12:54 |
| -!- nube [~rho@49.244.96.166] has joined #shogun | 13:19 | |
| -!- nube [~rho@49.244.96.166] has quit [Ping timeout: 276 seconds] | 13:29 | |
| -!- foulwall [~user@2001:da8:215:6100:1cf2:7cef:b86d:5a1b] has quit [Remote host closed the connection] | 13:42 | |
| -!- nube [~rho@49.244.104.21] has joined #shogun | 13:42 | |
| -!- iglesiasg [~iglesias@s83-179-44-135.cust.tele2.se] has joined #shogun | 13:50 | |
| -!- mode/#shogun [+o iglesiasg] by ChanServ | 13:50 | |
| -!- benibadman [~benibadma@62.217.45.102] has joined #shogun | 14:16 | |
| -!- nube [~rho@49.244.104.21] has quit [Ping timeout: 260 seconds] | 14:19 | |
| -!- van51 [~van51@athedsl-408350.home.otenet.gr] has joined #shogun | 14:28 | |
| van51 | hello | 14:28 |
| -!- van51 [~van51@athedsl-408350.home.otenet.gr] has quit [Read error: Connection reset by peer] | 14:33 | |
| -!- van51 [~van51@athedsl-408350.home.otenet.gr] has joined #shogun | 14:34 | |
| @iglesiasg | lisitsyn, more people register to the workshop, right? | 14:43 |
| lisitsyn | iglesiasg: yes two more | 15:01 |
| @iglesiasg | lisitsyn, cool | 15:01 |
| @sonney2k | wiking, could you please tell me the URL under which we will have the workshop live stream? | 15:26 |
| -!- iglesiasg [~iglesias@s83-179-44-135.cust.tele2.se] has quit [Quit: Ex-Chat] | 15:38 | |
| -!- benibadman [~benibadma@62.217.45.102] has quit [Remote host closed the connection] | 15:41 | |
| van51 | sonney2k: if I run liblinear | 15:52 |
| van51 | sonney2k: without specifying num_of_threads =1 , I'm getting segfaults sometimes | 15:52 |
| van51 | sonney2k: and almost always if the number of examples >= 100 | 15:53 |
| van51 | sonney2k: should that worry me a little or a lot ? :) | 15:53 |
| -!- nube [~rho@49.244.83.95] has joined #shogun | 16:16 | |
| -!- lambday [67157f4c@gateway/web/freenode/ip.103.21.127.76] has joined #shogun | 16:54 | |
| lisitsyn | van51: yes that should worry us | 17:20 |
| lisitsyn | van51: please try to reproduce it under valgrind | 17:20 |
| van51 | lisitsyn: okie | 17:21 |
| van51 | lisitsyn: I am not sure atm but I think it was in a unref method of sgreferenceddata or something | 17:22 |
| van51 | lisitsyn: I will try to reproduce it ofc | 17:23 |
| van51 | lisitsyn: but could it be bc of the way I initialize my data? | 17:23 |
| lisitsyn | van51: I don't know everything is possible :) | 17:24 |
| -!- pickle27 [~Kevin@130.15.32.52] has joined #shogun | 17:39 | |
| votjakovr | HeikoS: i've just sent a PR (with refactoring parts). Please, have a look at it. | 17:50 |
| @HeikoS | votjakovr: just did, looks fine | 17:50 |
| -!- shogun-notifier- [~irker@7nn.de] has joined #shogun | 17:50 | |
| shogun-notifier- | shogun: Roman Votyakov :develop * 971d4fb / src/shogun/ (8 files): https://github.com/shogun-toolbox/shogun/commit/971d4fbb6186ca10b168f76f999e474e31918a50 | 17:50 |
| shogun-notifier- | shogun: refactor evaluation of posterior and predictive distributions | 17:50 |
| shogun-notifier- | shogun: Heiko Strathmann :develop * 2c0f087 / src/shogun/ (8 files): https://github.com/shogun-toolbox/shogun/commit/2c0f08749fb47800f8a5ef038b0ada76e585b13c | 17:50 |
| shogun-notifier- | shogun: Merge pull request #1206 from votjakovr/feature/gp_refactoring | 17:50 |
| shogun-notifier- | shogun: | 17:50 |
| shogun-notifier- | shogun: refactor evaluation of posterior and predictive distributions | 17:50 |
| van51 | lisitsyn: here is a valgrind output http://pastebin.com/47j8QRB8 | 17:51 |
| votjakovr | HeikoS: ok, then, i'll send next one (with logit) tonight | 17:52 |
| @HeikoS | votjakovr: cool! this will be the first major step taken :) | 17:52 |
| lisitsyn | van51: hashed doc dot features is something you work on, right? | 17:54 |
| van51 | lisitsyn: yeah | 17:54 |
| lisitsyn | van51: looks like you are working on a vector that was free'd | 17:57 |
| pickle27 | lisitsyn, saw your comment | 18:00 |
| pickle27 | will be updating the PR shortly | 18:01 |
| lisitsyn | votjakovr: would you go for implementing the same thing you posted at g+? ;) | 18:02 |
| -!- lisitsyn [~lisitsin@mxs.kg.ru] has quit [Quit: Leaving.] | 18:07 | |
| shogun-buildbot | build #1181 of bsd1 - libshogun is complete: Failure [failed test_1] Build details are at http://www.shogun-toolbox.org/buildbot/builders/bsd1%20-%20libshogun/builds/1181 blamelist: Roman Votyakov <votjakovr@gmail.com> | 18:08 |
| lambday | HeikoS: hi | 18:12 |
| lambday | HeikoS: do you think I should rather override the clone method of SGObject for DenseMatrixOperators instead of doing it in the copy constructor | 18:12 |
| @HeikoS | lambday: hi | 18:12 |
| @HeikoS | lambday: nono | 18:12 |
| @HeikoS | clone implements a deep copy for all SGObject subclasses already | 18:12 |
| @HeikoS | so you can use that | 18:13 |
| lambday | HeikoS: I tried, but gives segfaults :( | 18:13 |
| @HeikoS | lambday: aha! | 18:13 |
| @HeikoS | wiking: where are my unit tests!!! | 18:13 |
| @HeikoS | lambday: I added that recently, its experimental | 18:13 |
| @HeikoS | lambday: can you reproduce and isolate the segfault and send me the program? | 18:13 |
| lambday | HeikoS: I was testing with logdet itself, I'll create a small one and sending you then | 18:14 |
| @HeikoS | ok thanks! | 18:14 |
| @HeikoS | turn on debug then you see where the problem happens | 18:14 |
| lambday | HeikoS: it prints clone successful... | 18:14 |
| lambday | yes | 18:14 |
| lambday | it comes back | 18:14 |
| @HeikoS | and then? | 18:15 |
| lambday | I put a print in the caller, that too prints.. so shouldn | 18:15 |
| lambday | t' be any problem with that | 18:15 |
| lambday | BUT | 18:15 |
| lambday | then I get the diagonal and it doesn't move any further | 18:15 |
| lambday | wait I will send you | 18:16 |
| lambday | I do have a REQUIRE statement that ensures that the matrix isn't NULL | 18:16 |
| @HeikoS | ok | 18:17 |
| @HeikoS | I dont get it, waiting for the code ;) | 18:17 |
| lambday | yes I understand.. sounds way too messy :D | 18:17 |
| lambday | wait.. sending | 18:17 |
| shogun-buildbot | build #1182 of bsd1 - libshogun is complete: Failure [failed test_1] Build details are at http://www.shogun-toolbox.org/buildbot/builders/bsd1%20-%20libshogun/builds/1182 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com> | 18:18 |
| shogun-buildbot | build #1305 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/1305 blamelist: Roman Votyakov <votjakovr@gmail.com> | 18:31 |
| lambday | HeikoS: https://gist.github.com/lambday/5920296 | 18:42 |
| lambday | HeikoS: I have some bug in my program as well.. I should check | 18:43 |
| lambday | in the code I mistakenly used the pointer! | 18:43 |
| lambday | Argh! explains the deviation! I'll fix it soon! | 18:43 |
| -!- gsomix [~gsomix@109.188.124.200] has joined #shogun | 18:45 | |
| lambday | HeikoS: oh! It gives segfaults cause I tried to delete it! | 18:47 |
| gsomix | good evening | 18:47 |
| @HeikoS | lambday: that means? | 18:47 |
| lambday | HeikoS: no, ummm.. that's not it :- | 18:48 |
| lambday | HeikoS: sorry I am really confused :( | 18:48 |
| @HeikoS | lambday: dont worry, so whats the current problem then? | 18:48 |
| lambday | but I found a bug in my program! | 18:48 |
| @HeikoS | lambday: so clone works? | 18:48 |
| lambday | HeikoS: nope! because using copy constructor that I used fails on REQUIRE of the get_diagonal, but when I used clone, it gives segfaults, doesn't fail on REQUIRE | 18:49 |
| lambday | my program is buggy as well | 18:49 |
| lambday | :( | 18:50 |
| lambday | please uncomment that and run... | 18:50 |
| lambday | (I wrote in comments) | 18:50 |
| @HeikoS | could we have a program without the copy constructor business? | 18:50 |
| @HeikoS | that confuses me a bi | 18:50 |
| @HeikoS | t | 18:50 |
| -!- pickle27 [~Kevin@130.15.32.52] has quit [Quit: Leaving] | 18:50 | |
| lambday | yes! deep copy of the operator we need.. I could have used same op and set the diagonal different for each jobs but that would only work for sequential computation and not the parallel | 18:51 |
| -!- travis-ci [~travis-ci@ec2-54-235-27-215.compute-1.amazonaws.com] has joined #shogun | 18:51 | |
| 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/8701802 | 18:51 |
| -!- travis-ci [~travis-ci@ec2-54-235-27-215.compute-1.amazonaws.com] has left #shogun [] | 18:51 | |
| lambday | so, once clone works, we'll have a deep copy of the operators with each of the jobs | 18:51 |
| lambday | that's exactly what we need | 18:51 |
| @HeikoS | yep deep copy is what we want | 18:52 |
| lambday | yep | 18:52 |
| @HeikoS | and what is broken in there? | 18:52 |
| lambday | 1. my copy constructor is buggy! 2. clone gives segfaults | 18:53 |
| @HeikoS | ok the the clone call fails in the example? | 18:53 |
| lambday | yes, please try to run it once... uncommenting the get_diagonal() for the cloned one | 18:54 |
| @HeikoS | lets see | 18:54 |
| shogun-buildbot | build #1306 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/1306 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com> | 18:55 |
| @HeikoS | lambday: example fails to compile here, SGMatrix not found, annoying .... | 18:56 |
| lambday | errr! :-/ | 18:57 |
| @HeikoS | ../shogun-test.cpp:19:2: error: 'SGMatrix' was not declared in this scope | 18:57 |
| @HeikoS | dont know why this is happening | 18:57 |
| lambday | oh shit! | 18:57 |
| lambday | using namespace shogun; | 18:57 |
| lambday | :D | 18:57 |
| @HeikoS | ah namespace | 18:57 |
| lambday | I copied and pasted a part of my code, missed that :( | 18:58 |
| @HeikoS | lambday: now I get linker errors *sigh* | 18:59 |
| @HeikoS | thats something else | 18:59 |
| @HeikoS | let me find out ... | 18:59 |
| lambday | linking errors :'( | 18:59 |
| @HeikoS | gotta recompile shogun, | 19:00 |
| lambday | oh.. yes! | 19:00 |
| @HeikoS | messed up source tree here | 19:00 |
| lambday | its newly added stuff | 19:00 |
| @HeikoS | just pulled | 19:00 |
| lambday | okay | 19:00 |
| lambday | (good that I kept this week for bugfixing! this explains all the deviations! things should work properly once I do the clone properly) | 19:02 |
| @HeikoS | lambday: yeah, always important to look at the valgrind output :) | 19:02 |
| @HeikoS | clone is also not stable yet | 19:02 |
| @HeikoS | but just 95% | 19:02 |
| lambday | should work, right? | 19:03 |
| @HeikoS | I am still waiting for wiking to write some automated unit test magic :) | 19:03 |
| @HeikoS | still compiling | 19:03 |
| lambday | yes I always use valgrind.. I test the class separately, write tests separately, debug, and then add to shogun :D | 19:03 |
| lambday | but this is a stupid error.. I set the same pointer instead of calling copy constructor... so it keeps on adding shifts in each iterations.. explains why we got so large deviations for higher number of shifts | 19:04 |
| lambday | aah! | 19:05 |
| lambday | HeikoS: automated unit-test? | 19:05 |
| @HeikoS | lambday: yeah for clone its quite easy | 19:05 |
| @HeikoS | assert(a->equals(a->clone())) | 19:05 |
| @HeikoS | for all SGObhjects | 19:05 |
| @HeikoS | makes sure that both equals and clone works | 19:06 |
| lambday | ahan! | 19:06 |
| -!- pickle27 [~kevin@rcv3-lab-pc.ee.queensu.ca] has joined #shogun | 19:07 | |
| lambday | feels so relaxing to work on this again after 6 hours of brainstorming at that Intel project I was talking about :D | 19:07 |
| @HeikoS | lambday: haha :) | 19:08 |
| @HeikoS | man :D | 19:08 |
| lambday | HeikoS: you won't believe I'll be working 12-14 hours a day :D | 19:08 |
| lambday | lol | 19:08 |
| @HeikoS | lambday: I *do* believe you, all this stuff has to be written at some point right? :D | 19:09 |
| @HeikoS | so I got it running now | 19:09 |
| @HeikoS | there is something wrong with clone I think | 19:09 |
| lambday | reproduces | 19:09 |
| @HeikoS | doesnt copy the complex value | 19:09 |
| lambday | you implemented that before I added complex I guess | 19:09 |
| lambday | :-/ | 19:10 |
| @HeikoS | lambday: no afterwards | 19:10 |
| @HeikoS | lambday: the m_operator is not registered | 19:10 |
| @HeikoS | that definitely causes a problem | 19:10 |
| lambday | where? | 19:10 |
| @HeikoS | of DenseMatrix | 19:10 |
| lambday | oh! | 19:10 |
| @HeikoS | so clone does not handle it | 19:10 |
| @HeikoS | wiking: exactly this is why we need the unit tests asap! ^ | 19:11 |
| @HeikoS | since when one forgets to register parameters, the unit test will fail | 19:11 |
| lambday | HeikoS: I faced a problem when I was registering it | 19:11 |
| @HeikoS | lambday: which is? | 19:11 |
| lambday | wait.. let me check | 19:12 |
| @HeikoS | only registered parameters are handled by clone | 19:12 |
| lambday | yes... so once I solve that, it solves it all... | 19:12 |
| @HeikoS | hopefully :) | 19:12 |
| lambday | I remember I kept it like that for some reason... for all other classes I registered params.. | 19:12 |
| @HeikoS | what happens if you register it? | 19:14 |
| lambday | HeikoS: wait I'm testing again... I also can't use SG_GCDEBUG but rather I had to use SG_SGCDEBUG for this | 19:16 |
| lambday | says "io" not defined | 19:16 |
| @HeikoS | thats no problem | 19:16 |
| @HeikoS | you can only use the non-static one when you have SGobjects | 19:16 |
| @HeikoS | not from static context | 19:16 |
| lambday | https://gist.github.com/lambday/5920710 | 19:22 |
| lambday | umm but its a subclass of SGObject and the methods I used are not static | 19:23 |
| lambday | I did include shogun/base/Parameter.h | 19:24 |
| @HeikoS | maybe you forgot to include SGIO? | 19:25 |
| @HeikoS | lambday: so, does registering it work? | 19:29 |
| lambday | HeikoS: that shouldn't be the case, SGObject.h includes SGIO.h itself | 19:29 |
| lambday | HeikoS: no :( | 19:29 |
| @HeikoS | whats the problem? | 19:29 |
| lambday | check the gist I pasted.. this is the error msg I get when I add init and use SG_ADD | 19:29 |
| @HeikoS | ah so same problem | 19:31 |
| @HeikoS | so base class seems like | 19:31 |
| @HeikoS | thats so weird | 19:33 |
| lambday | yes :( :( | 19:33 |
| lambday | its not getting anything from its base | 19:33 |
| lambday | some mistake is there! | 19:33 |
| -!- gsomix [~gsomix@109.188.124.200] has quit [Remote host closed the connection] | 19:34 | |
| @HeikoS | lambday: yeah must be some subtle thing | 19:34 |
| lambday | I checked it twice today.. must be missing something... I'll check it again | 19:35 |
| @sonney2k | van51, that segfault is probably due to some bug in your dotfeatures /converter then | 19:39 |
| van51 | sonney2k: yea probably, I'm trying to locate it | 19:39 |
| @sonney2k | van51, but post your example / code | 19:39 |
| @sonney2k | on some gist.github.com | 19:39 |
| van51 | sonney2k: https://gist.github.com/van51/5920880 | 19:41 |
| @sonney2k | van51, btw one test would be to run your converter / dotfeatures under valgrind (e.g. just the test) | 19:41 |
| van51 | sonney2k: I have ran the unit tests in valgrind and they were ok | 19:41 |
| @sonney2k | van51, you can use init_shogun_with_defaults() btw | 19:41 |
| @HeikoS | lambday: its weird, base constructor is called | 19:44 |
| @HeikoS | so the things *are* there | 19:44 |
| @HeikoS | but I am already tired, probably will find it with fresh eyes ;) | 19:45 |
| @sonney2k | van51, and yes you only need to unref lib_linear | 19:45 |
| van51 | sonney2k: hehe ok | 19:46 |
| van51 | sonney2k: I will find it or I won't sleep -.- | 19:46 |
| van51 | sonney2k: is the plain dot function called at all from liblinear? | 19:48 |
| @sonney2k | van51, btw you can load the label vector much more easy - just use a SGVector and then do load with CAsciiFile | 19:48 |
| @sonney2k | van51, not sure - I *think* not | 19:49 |
| @sonney2k | van51, but it depends on the liblinear solver that is used | 19:49 |
| van51 | sonney2k: yea I saw that in an example, but I wanted to only load the first K labels | 19:49 |
| @sonney2k | van51, well you can just head -n K file or shrink the vector (resize...) | 19:50 |
| -!- lisitsyn [~lisitsyn@83.234.169.218] has joined #shogun | 19:52 | |
| @HeikoS | lambday: I gotta go now, see you tomorrow! dont forget to sleep ;) | 19:53 |
| @HeikoS | votjakovr: going gome, see you tomorrow! | 19:55 |
| -!- HeikoS [~heiko@nat-189-68.internal.eduroam.ucl.ac.uk] has quit [Quit: Leaving.] | 19:55 | |
| @sonney2k | lisitsyn, wiking @c-base now | 20:37 |
| lisitsyn | sonney2k: nice | 20:37 |
| lisitsyn | sonney2k: equipment? | 20:38 |
| -!- zxtx [~zv@cpe-75-83-151-252.socal.res.rr.com] has quit [Read error: Operation timed out] | 20:45 | |
| -!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout] | 20:50 | |
| naywhayare | hello there, I think I've found a problem with the ./configure script | 20:53 |
| naywhayare | I haven't looked into it too deeply but I think the problem is still present in trunk | 20:53 |
| naywhayare | if I have lua5.2 installed, ./configure will detect that and try to build the lua interface; however, (I did not check with trunk, but I did with 2.1.0) shogun does not compile with lua5.2 | 20:53 |
| @sonney2k | lisitsyn, yes we can use the c-base cam \o/ | 20:56 |
| lisitsyn | sonney2k: heh nice finally | 20:57 |
| lisitsyn | naywhayare: hey | 20:57 |
| naywhayare | lisitsyn: it should be an easy fix around line 1008 or 1010 of the configure script (somewhere in there) | 20:57 |
| lisitsyn | naywhayare: thanks | 20:57 |
| @sonney2k | naywhayare, shogun develop should do lua5.2 | 20:58 |
| naywhayare | I should also note -- I know nothing about lua and have no use for it. but I wanted to compile shogun with all features available :) | 20:58 |
| naywhayare | sonney2k: okay, then nevermind :) | 20:58 |
| @sonney2k | lisitsyn, any idea where gsomix is? | 20:59 |
| @sonney2k | wiking, awake? | 20:59 |
| lisitsyn | sonney2k: no | 20:59 |
| @sonney2k | lambday, hmmhh :/ | 20:59 |
| lisitsyn | naywhayare: okay let me try to compile it here with lua | 21:00 |
| @sonney2k | van51, any insights from valgrind? | 21:00 |
| van51 | sonney2k: I have some fixes to send | 21:00 |
| van51 | sonney2k: but nothing final yet | 21:00 |
| @sonney2k | van51, fixes for what? | 21:01 |
| van51 | sonney2k: some simple stuff, like a SG_REF in the converter | 21:01 |
| van51 | sonney2k: and a minor change in the copy constructos of the tokenizers | 21:01 |
| @sonney2k | van51, found by valgrind? | 21:01 |
| van51 | sonney2k: no :P | 21:02 |
| van51 | sonney2k: the SG_REF I had it in my mind from when you told me that it's a "rule" to sg-ref objects you save for later | 21:02 |
| van51 | sonney2k: the others I found an abnormality in some debugging messages and thought that maybe it was that the cause | 21:02 |
| van51 | sonney2k: when a copy constructor was called on a Tokenizer it didn't also copy the position of the last_idx | 21:03 |
| van51 | sonney2k: actually I think it wasn't even setting it to 0 | 21:03 |
| van51 | it could be trash | 21:04 |
| van51 | sonney2k: anyway, I was planning to make a PR now about those, you can see the changes there | 21:04 |
| @sonney2k | van51, well the copy constructor is not really used | 21:06 |
| van51 | sonney2k: yea it didn't fix the issue, but since it's something that I noticed, I guess it can be changed | 21:09 |
| -!- gsomix [~gsomix@109.188.124.219] has joined #shogun | 21:13 | |
| gsomix | good evening again | 21:13 |
| @sonney2k | hey gsomix! | 21:14 |
| @sonney2k | gsomix, all happy animals? | 21:14 |
| gsomix | sonney2k, yep. and Moscow's zoo is free for students. | 21:16 |
| lambday | sonney2k: hi.. sorry I was away | 21:16 |
| lisitsyn | sonney2k: btw is it worth to visit berlin one? | 21:17 |
| gsomix | sonney2k, preparing PR. | 21:18 |
| @sonney2k | lambday, whats up? | 21:19 |
| @sonney2k | lisitsyn, berline one? | 21:20 |
| lisitsyn | sonney2k: yes zoo | 21:20 |
| lambday | sonney2k: going good so far.. been assigned with a lot of stuff at the insti.. gotta manage time :( | 21:20 |
| lisitsyn | you were talking about zoo | 21:20 |
| lisitsyn | :0 | 21:20 |
| lisitsyn | :) | 21:20 |
| @sonney2k | lisitsyn, well animals are animals :) | 21:21 |
| lisitsyn | sonney2k: that's true and people are animals too but still may be it is not cool | 21:21 |
| lisitsyn | sonney2k: so what made c-base guys get convinced? | 21:24 |
| @sonney2k | lisitsyn, from when is the viola jones paper? | 21:28 |
| lisitsyn | sonney2k: year? | 21:29 |
| @sonney2k | yes | 21:29 |
| lisitsyn | 2001 or so | 21:29 |
| @sonney2k | wow old | 21:29 |
| @sonney2k | lisitsyn, and local binary patterns | 21:29 |
| lisitsyn | yes 2001 | 21:29 |
| lisitsyn | lbp is around 2004 I guess | 21:29 |
| lisitsyn | oops | 21:29 |
| lisitsyn | :D | 21:29 |
| lisitsyn | sonney2k: LBP is 1994 | 21:30 |
| -!- iglesiasg [~iglesias@s83-179-44-135.cust.tele2.se] has joined #shogun | 21:30 | |
| -!- mode/#shogun [+o iglesiasg] by ChanServ | 21:30 | |
| @sonney2k | lisitsyn, you are around on thursday too right? | 21:53 |
| lisitsyn | sonney2k: yes | 21:53 |
| @sonney2k | lisitsyn, I will be in c-base in the evening for cam setup stuff so we might meet aswell | 21:53 |
| lisitsyn | sonney2k: oh why not! | 21:53 |
| @sonney2k | I will likely not have my talk ready though and be dead but hey why not :D | 21:54 |
| lisitsyn | sonney2k: btw how do we present things? with own notebooks? | 21:54 |
| lambday | sonney2k: lisitsyn CGSObject::clone won't work if the params registered are not CGSObject type as of now, right? | 21:57 |
| lambday | oops | 21:58 |
| lambday | SG* | 21:58 |
| lisitsyn | lambday: that's what heiko knows but I don't think it skips matrices and such stuff | 21:58 |
| lisitsyn | I see it clones all parameters | 21:58 |
| lisitsyn | lambday: why? | 21:59 |
| @sonney2k | lambday, no it should work for all registered params | 21:59 |
| @sonney2k | lisitsyn, own notebook yeah | 21:59 |
| lambday | sonney2k: lisitsyn its giving segfault at the line base/SGObject.cpp:1341 | 22:00 |
| lambday | which is | 22:00 |
| @sonney2k | lisitsyn, in worst case my notebook with .pdf or so | 22:00 |
| lambday | if (!m_parameters->get_parameter(i)->copy(copy->m_parameters->get_parameter(i))) | 22:00 |
| @sonney2k | lambday, cloning what? | 22:00 |
| lambday | SGReferencedData has copy? | 22:00 |
| lisitsyn | sonney2k: I have bad battery hope to have AC available directly from the place | 22:00 |
| @sonney2k | lisitsyn, sure | 22:00 |
| lambday | cloning a CSGObject type obj which has a SGMatrix param | 22:01 |
| lisitsyn | lambday: lets see valgrind! | 22:01 |
| lambday | wait I'm pasting you the debug msgs (gdb) | 22:01 |
| @sonney2k | lambday, no it doesn't need to - it gets the values of the matrix and then sets it again | 22:01 |
| lambday | I'm checking.. but it does give segfault for this line | 22:03 |
| lisitsyn | lambday: can you check what is uninitialized? | 22:03 |
| @sonney2k | lambday, then we still have a bug there | 22:06 |
| @sonney2k | lambday, it would help a lot to produce a minimal test case then HeikoS can easily fix this | 22:06 |
| lambday | sonney2k: lisitsyn please have a look at this - https://gist.github.com/lambday/5922327 | 22:06 |
| lambday | sonney2k: yes I was thinking the same | 22:06 |
| lisitsyn | lambday: we need to know what is NULL/uninitialized | 22:07 |
| lambday | lisitsyn: checking.. | 22:07 |
| lisitsyn | lambday: I guess it is either copy | 22:08 |
| lisitsyn | or copy->m_parameters | 22:08 |
| lambday | lisitsyn: how do I test that with gdb? :( | 22:12 |
| lisitsyn | lambday: I'd suggest to put some prints | 22:12 |
| lisitsyn | of copy and copy->m_parameters | 22:12 |
| lisitsyn | and copy->m_parameters->get_parameter(i) | 22:13 |
| lisitsyn | you will see what failed | 22:13 |
| lisitsyn | otherwise put a breakpoint | 22:13 |
| lisitsyn | and use 'print copy' | 22:13 |
| lisitsyn | and so on | 22:13 |
| lambday | okay | 22:13 |
| lisitsyn | lambday: cgdb can appear quite useful to manipulate breakpoints | 22:13 |
| lambday | lisitsyn: alright... checking | 22:14 |
| lambday | lisitsyn: seems like it doesn't entered TParameter::copy at all... otherwise that would have been printed | 22:17 |
| lisitsyn | lambday: yes | 22:18 |
| lisitsyn | that's why I think that's something with the expression inside () | 22:18 |
| lisitsyn | hmm something is wrong with lua indeed | 22:20 |
| lambday | lisitsyn: aha! | 22:22 |
| lambday | copy is nil | 22:22 |
| lisitsyn | lambday: put an assert here please | 22:23 |
| lambday | lisitsyn: okay | 22:24 |
| lisitsyn | but anyway we've got to do something with it :) | 22:24 |
| lambday | why would new_sgserializable(get_name(), this->m_generic) return nil | 22:26 |
| lambday | :- | 22:26 |
| lambday | :-/ | 22:26 |
| lisitsyn | lambday: what is name? | 22:34 |
| lambday | lisitsyn: CDenseMatrixOperator (its a bit modified than what I've pushed, I hadn't added the register_params stuff for that due to c++ template issues, now I did, and testing) | 22:35 |
| lisitsyn | lambday: is it template class? | 22:35 |
| lambday | yes | 22:35 |
| lambday | its like CSGObject <-- CLinearOperator<T> <---- CMatrixOperator<T> <---- CDenseMatrixOperator<T> | 22:36 |
| lambday | SG_ADD didn't work (said m_parameters and m_model_selection_parameters not declared), so used CSGObject::m_pamareters->add() directly | 22:37 |
| -!- zxtx [~zv@rrcs-74-62-200-195.west.biz.rr.com] has joined #shogun | 22:37 | |
| lambday | params are registered (clone shows the index and all) | 22:37 |
| lisitsyn | lambday: what is template type you use? | 22:39 |
| lambday | complex | 22:40 |
| lisitsyn | haha | 22:40 |
| lisitsyn | okay | 22:40 |
| lisitsyn | lambday: shogun/base/class_list.cpp.py:116 | 22:40 |
| lambday | lisitsyn: that's for the make, right? | 22:42 |
| lambday | lisitsyn: I tested with float64_t also and it fails there too | 22:43 |
| lisitsyn | lambday: no that's why it does return null | 22:43 |
| lisitsyn | hmm no idea but it is wrong | 22:43 |
| lambday | lisitsyn: okay.. trying removing that.. | 22:44 |
| lisitsyn | lambday: just check generated class_list.cpp | 22:44 |
| lisitsyn | and find CDenseMatrixOperator | 22:44 |
| lisitsyn | you will see it won't be created for complex | 22:44 |
| lisitsyn | just NULL | 22:44 |
| lambday | lisitsyn: yes.. but clone depends on that? | 22:45 |
| lisitsyn | lambday: yes that's what new_sgserializable does | 22:45 |
| lambday | lisitsyn: okayss | 22:46 |
| lambday | lisitsyn: but then why it fails for float64_t | 22:46 |
| lambday | :-/ | 22:46 |
| lisitsyn | lambday: I don't know but I am absolutely sure it should not return null | 22:47 |
| lisitsyn | so lets solve one problem :) | 22:47 |
| lambday | same for intxx_t | 22:47 |
| lambday | hmm... okay | 22:47 |
| lambday | lisitsyn: now I remember why I put it there.. | 22:49 |
| lisitsyn | lambday: why? | 22:49 |
| lambday | lisitsyn: commented that line and it fails at many places (complex doesn't overload +=, -= etc I guess) | 22:50 |
| lambday | like other ptypes | 22:50 |
| lisitsyn | oh | 22:50 |
| lisitsyn | lambday: then you've got to put some magic here | 22:50 |
| lambday | lisitsyn: I don't think I can use clone for complex at all then!! :( | 22:50 |
| lambday | lisitsyn: there is other way | 22:51 |
| lisitsyn | lambday: you can add it by your selection | 22:51 |
| lisitsyn | just need some code in class_list.cpp.py | 22:51 |
| lisitsyn | which excludes complex for anything but your classes | 22:51 |
| lambday | lisitsyn: for a selected few classes you mean | 22:51 |
| lambday | that we'll actually be using complex with?? | 22:52 |
| lisitsyn | yes | 22:52 |
| lisitsyn | yes | 22:52 |
| lambday | lisitsyn: that's an awesome idea!! | 22:52 |
| lambday | classic!! | 22:52 |
| lambday | alright... trying! | 22:52 |
| lambday | :D | 22:52 |
| lisitsyn | lambday: just add a list and some thing that handles it | 22:52 |
| lambday | yup | 22:52 |
| -!- kevin_ [~Kevin@d67-193-243-174.home3.cgocable.net] has joined #shogun | 23:11 | |
| -!- kevin_ [~Kevin@d67-193-243-174.home3.cgocable.net] has quit [Client Quit] | 23:11 | |
| -!- kevin_ [~Kevin@d67-193-243-174.home3.cgocable.net] has joined #shogun | 23:12 | |
| -!- kevin_ [~Kevin@d67-193-243-174.home3.cgocable.net] has quit [Client Quit] | 23:12 | |
| -!- votjakovr [~votjakovr@host-46-241-3-209.bbcustomer.zsttk.net] has left #shogun ["Fallen asleep!"] | 23:13 | |
| van51 | so I have a suspicion it happens when apply() is called on liblinear and num_threads > 1 | 23:14 |
| lisitsyn | van51: then we have a race condition ;) | 23:17 |
| lisitsyn | van51: helgrind may be? | 23:17 |
| van51 | lisitsyn: I can try it | 23:17 |
| van51 | lisitsyn: I'm guessing it's similar to valgrind | 23:17 |
| van51 | :p | 23:17 |
| van51 | lisitsyn: very imaginative names btw | 23:17 |
| lisitsyn | van51: it is a module of valgrind | 23:17 |
| lisitsyn | van51: yes very nordic and GRIND | 23:18 |
| van51 | lisitsyn: baah can't believe it's taking this long | 23:18 |
| lisitsyn | van51: it is run in a kind of sandbox where everything is counted and checked so no surprise | 23:19 |
| van51 | hopefully next time I'll narrow it down sooner | 23:19 |
| van51 | or more hopefully there won't be a similar next time :) | 23:19 |
| van51 | lisitsyn: ok sounds nice | 23:19 |
| lisitsyn | van51: does it happen with other type of features? | 23:19 |
| van51 | lisitsyn: I'll try it soon | 23:19 |
| van51 | lisitsyn: didn't check | 23:19 |
| van51 | lisitsyn: I'll see that first once valgrind finishes its run | 23:20 |
| lisitsyn | that may help to get suspect in custody | 23:20 |
| van51 | lisitsyn: I can't seem to reproduce it with DenseFeatures | 23:26 |
| lisitsyn | good | 23:26 |
| lisitsyn | then it is more likely that we have bug somewhere else ;) | 23:26 |
| van51 | lisitsyn: but it's leaking memory when apply() is called | 23:26 |
| van51 | no it's not :p | 23:27 |
| van51 | anyway, it's time for helgrind | 23:27 |
| @sonney2k | van51, ohh makes sense | 23:29 |
| @sonney2k | van51, I think your code is not thread safe | 23:29 |
| @sonney2k | van51, but it needs to be | 23:29 |
| @sonney2k | van51, liblinear trains on a single cpu | 23:29 |
| lambday | lisitsyn: okay that got solved | 23:29 |
| lambday | lisitsyn: but it still fails assert | 23:30 |
| @sonney2k | van51, however when calling apply() we will use all available cpu's | 23:30 |
| lisitsyn | lambday: the class_list thing/ | 23:30 |
| lisitsyn | ? | 23:30 |
| lambday | lisitsyn: yep | 23:30 |
| van51 | sonney2k: I see | 23:30 |
| @sonney2k | van51, so the dotfeatures you wrote need to be reentrant | 23:30 |
| lisitsyn | lambday: alright | 23:30 |
| van51 | sonney2k: so how do I start to make it thread-safe? | 23:30 |
| lisitsyn | lambday: copy is still null right? | 23:30 |
| van51 | sonney2k: is there a similar situation-class I can have a look at? | 23:30 |
| @sonney2k | van51, no member variables for status | 23:30 |
| @sonney2k | van51, let me check | 23:30 |
| lambday | manually added a separate list of classes for which we need complex to work and added a condition | 23:30 |
| lambday | lisitsyn: yep | 23:30 |
| lisitsyn | lambday: and they are in class_list.cpp? | 23:31 |
| lambday | lisitsyn: yep | 23:31 |
| @sonney2k | lambday, it is the tokenizer | 23:31 |
| @sonney2k | lambday, sry | 23:31 |
| @sonney2k | van51, it is the tokenizer | 23:32 |
| lambday | :D | 23:32 |
| lisitsyn | lambday: is m_generic set correclty? | 23:32 |
| lambday | sonney2k: no problem | 23:32 |
| @sonney2k | van51, you need a separate one in dense_dot etc | 23:32 |
| van51 | sonney2k: it's shared through the threads? | 23:32 |
| lambday | lisitsyn: checking | 23:32 |
| van51 | sonney2k: bc it's a pointer? | 23:32 |
| @sonney2k | van51, or the tokenizer is not allowed to keep local variables / or you need to pass it some status variable | 23:32 |
| @sonney2k | van51, just think of you call next() from several threads | 23:33 |
| lisitsyn | lambday: just check if it is PT_COMPLEX64 as required | 23:33 |
| van51 | sonney2k: I mean all the threads use the same object,right? | 23:33 |
| van51 | sonney2k: atm | 23:33 |
| @sonney2k | van51, yes | 23:33 |
| lambday | lisitsyn: alright | 23:33 |
| van51 | sonney2k: ok | 23:33 |
| @sonney2k | van51, and when they all call next() you have a race condition | 23:33 |
| van51 | sonney2k: that's why I was noticing a weird output | 23:34 |
| @sonney2k | van51, yes | 23:34 |
| @sonney2k | van51, copy constructor with shallow copies might help already | 23:34 |
| @sonney2k | van51, so you only have different next pointers etc | 23:34 |
| @sonney2k | van51, but share all the delimiter array etc | 23:35 |
| van51 | sonney2k: ok! I'll take a look :) | 23:36 |
| @sonney2k | van51, or the other solution would be to do tokenizer->has_next(last_end_index) | 23:36 |
| @sonney2k | van51, to keep it status free | 23:36 |
| @sonney2k | van51, that is probable even easier/better | 23:36 |
| @sonney2k | y | 23:36 |
| van51 | sonney2k: btw plain dot() is called | 23:38 |
| @sonney2k | van51, for what? | 23:38 |
| van51 | sonney2k: in the beggining it's called for every single example | 23:39 |
| van51 | to compute a dot with the same example | 23:39 |
| @sonney2k | van51, ahh ok diagonal of kernel matrix or sth | 23:40 |
| @sonney2k | van51, anyway my favourite solution is the has_next(last_index) one | 23:41 |
| lambday | lisitsyn: its coming out to be PT_SGOBJECT every time | 23:42 |
| van51 | sonney2k: the thing is that the tokenizer also has the text as a status | 23:42 |
| lambday | so, its not set! | 23:42 |
| van51 | sonney2k: so each call to dense_dot also changes the text | 23:42 |
| lisitsyn | lambday: you should call set_generic<T>(); | 23:44 |
| lisitsyn | somewhere | 23:44 |
| lisitsyn | in init may be | 23:44 |
| lambday | lisitsyn: okay.. I should do it for all template classes then | 23:45 |
| lisitsyn | lambday: exactly | 23:46 |
| @sonney2k | van51, yeah you have to return it in some function, e.g. you do t->has_next(last_index) and SGVector<char> next = t->next(last_index) will return it | 23:46 |
| lisitsyn | sleep time see you | 23:46 |
| lambday | lisitsyn: okies... good night :) | 23:46 |
| -!- lisitsyn [~lisitsyn@83.234.169.218] has quit [Quit: Leaving.] | 23:46 | |
| van51 | sonney2k: that would return a token? | 23:48 |
| van51 | sonney2k: but the text to be tokenized is stored inside the tokenizer object | 23:49 |
| van51 | sonney2k: and it's replaced on each call to dense_dot | 23:49 |
| @sonney2k | van51, anyway either copy constructor or some way of returning the status will work | 23:49 |
| @sonney2k | van51, jsut do whatever you find easier. | 23:49 |
| van51 | sonney2k: I think copy constructor would be better | 23:49 |
| van51 | sonney2k: I have one question though | 23:49 |
| van51 | sonney2k: do I have to find the class first to call the appropriate constructor? | 23:50 |
| @sonney2k | van51, btw if you do copy constructor please change the bool[256] array to SGVector<byte> so you can get refcounts for the array | 23:50 |
| van51 | constructors are not virtual, right? | 23:50 |
| @sonney2k | van51, just don't store an array | 23:50 |
| @sonney2k | van51, true they are not | 23:51 |
| van51 | sonney2k: clone() could work here, though | 23:51 |
| van51 | if I register the delimiters | 23:51 |
| van51 | now that it will be a sgvector | 23:51 |
| @sonney2k | van51, no don't do clone | 23:52 |
| @sonney2k | van51, you will need a copy constructor for each tokenizer | 23:52 |
| @sonney2k | then all good | 23:52 |
| van51 | sonney2k: won't that need multiple cases for the tokenizers, to call the appropriate one? | 23:54 |
| @sonney2k | van51, I don't understand the question | 23:55 |
| @sonney2k | IMHO you should just use CTokenizer tokenizer as member | 23:55 |
| @sonney2k | and then do a CTokenizer thread_local_tokenizer = tokenizer; in the dense_dot etc | 23:56 |
| van51 | sonney2k: ok, that's what I had in my mind as an idea | 23:58 |
| van51 | it seems easier to do this way | 23:58 |
| --- Log closed Thu Jul 04 00:00:16 2013 | ||
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!