--- Log opened Thu Jul 04 00:00:16 2013 | ||
@sonney2k | van51, might be that you dont' even need to write a copy constructor - the default copy constructor will just do a shallow copy anyway | 00:00 |
---|---|---|
@sonney2k | van51, ok I am off to bed now cool that you've found the issue so quickly | 00:04 |
@sonney2k | cu | 00:04 |
van51 | sonney2k: I wouldn't call it quickly :P | 00:04 |
van51 | cya | 00:04 |
@sonney2k | gsomix, I will look at your hopefully to be merged PR tomorrow morning! | 00:05 |
gsomix | sonney2k, yeah | 00:06 |
gsomix | sonney2k, I have fallen in problems with new interface, so now I try do it in easier way. :( | 00:06 |
gsomix | sonney2k, nite | 00:06 |
-!- lambday [67157f4c@gateway/web/freenode/ip.103.21.127.76] has quit [] | 00:30 | |
-!- zxtx [~zv@rrcs-74-62-200-195.west.biz.rr.com] has quit [Ping timeout: 245 seconds] | 00:56 | |
-!- zxtx [~zv@rrcs-76-79-81-162.west.biz.rr.com] has joined #shogun | 01:11 | |
-!- hushell [~hushell@8-92.ptpg.oregonstate.edu] has joined #shogun | 01:42 | |
van51 | sonney2k: I went with a clone approach after all.. hope you're not mad :p | 01:58 |
van51 | sonney2k: it just seems easier that way, because it maintains the easy functionality of the Tokenizers and also avoids some hassle with the fact that CTokenizer is abstract | 01:59 |
van51 | sonney2k: ofc it's not set in stone, we can discuss it tomorrow | 01:59 |
van51 | sonney2k: I'll make a PR | 02:00 |
van51 | cya guys | 02:00 |
-!- van51 [~van51@athedsl-408350.home.otenet.gr] has quit [Quit: Leaving.] | 02:00 | |
-!- hushell [~hushell@8-92.ptpg.oregonstate.edu] has quit [Ping timeout: 246 seconds] | 03:10 | |
shogun-buildbot | build #390 of nightly_none is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/nightly_none/builds/390 | 03:14 |
-!- hushell [~hushell@c-24-21-141-32.hsd1.or.comcast.net] has joined #shogun | 03:32 | |
shogun-buildbot | build #382 of nightly_all is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/nightly_all/builds/382 | 03:37 |
-!- zxtx [~zv@rrcs-76-79-81-162.west.biz.rr.com] has quit [Ping timeout: 276 seconds] | 03:57 | |
shogun-buildbot | build #447 of nightly_default is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/nightly_default/builds/447 | 04:00 |
-!- nube [~rho@49.244.83.95] has quit [Quit: Leaving.] | 04:44 | |
-!- iglesiasg [~iglesias@s83-179-44-135.cust.tele2.se] has quit [Ping timeout: 260 seconds] | 04:58 | |
-!- nube [~rho@116.90.239.3] has joined #shogun | 05:32 | |
-!- gsomix [~gsomix@109.188.124.219] has quit [Ping timeout: 246 seconds] | 05:50 | |
-!- gsomix [~gsomix@109.188.124.219] has joined #shogun | 05:52 | |
-!- nube [~rho@116.90.239.3] has quit [Quit: Leaving.] | 06:19 | |
-!- nube [~rho@116.90.239.3] has joined #shogun | 06:19 | |
-!- shogun-notifier- [~irker@7nn.de] has joined #shogun | 08:01 | |
shogun-notifier- | shogun: van51 :develop * bac4e76 / / (9 files): https://github.com/shogun-toolbox/shogun/commit/bac4e7648b9cb77e02351eb46b7d0c756fbcbcc7 | 08:01 |
shogun-notifier- | shogun: Multi-threaded dense_dot in HashedDocDotFeatures | 08:01 |
shogun-notifier- | shogun: Soeren Sonnenburg :develop * d14f7c8 / / (9 files): https://github.com/shogun-toolbox/shogun/commit/d14f7c828077129ce0ec623ff86ff76ed92aaa3e | 08:01 |
shogun-notifier- | shogun: Merge pull request #1207 from van51/feature/hashing | 08:01 |
shogun-notifier- | shogun: | 08:01 |
shogun-notifier- | shogun: Made HashedDocDotFeatures thread-safe (reentrant) | 08:01 |
shogun-buildbot | build #1183 of bsd1 - libshogun is complete: Failure [failed test_1] Build details are at http://www.shogun-toolbox.org/buildbot/builders/bsd1%20-%20libshogun/builds/1183 blamelist: Soeren Sonnenburg <sonne@debian.org> | 08:17 |
gsomix | sonney2k, sonne|work around? | 08:21 |
-!- travis-ci [~travis-ci@ec2-184-73-0-135.compute-1.amazonaws.com] has joined #shogun | 08:24 | |
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/8724003 | 08:24 |
-!- travis-ci [~travis-ci@ec2-184-73-0-135.compute-1.amazonaws.com] has left #shogun [] | 08:24 | |
-!- iglesiasg [~iglesias@s83-179-44-135.cust.tele2.se] has joined #shogun | 08:28 | |
shogun-buildbot | build #1184 of bsd1 - libshogun is complete: Failure [failed test_1] Build details are at http://www.shogun-toolbox.org/buildbot/builders/bsd1%20-%20libshogun/builds/1184 blamelist: van51 <vangelis_51@hotmail.com> | 08:28 |
gsomix | sonney2k, sonne|work I'm unhappy: there are some bugs in my code that uses Tokenizer. need little time to fix. | 08:30 |
sonne|work | gsomix: hey good morning | 08:30 |
gsomix | btw with Tokenizer reading empty string is not possible | 08:30 |
gsomix | is this necessary? | 08:31 |
sonne|work | gsomix: then we need to support it | 08:31 |
-!- iglesiasg [~iglesias@s83-179-44-135.cust.tele2.se] has quit [Client Quit] | 08:31 | |
sonne|work | gsomix: it may happen yes even though unlikely & stupid | 08:31 |
shogun-buildbot | build #1307 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/1307 blamelist: Soeren Sonnenburg <sonne@debian.org> | 08:33 |
gsomix | sonne|work, didn't get. support what? Tokenizer of reading of empty strings? | 08:34 |
gsomix | *or | 08:35 |
sonne|work | empty strings | 08:36 |
gsomix | sonne|work, I don't know how. DelimiterTokenizer thinks ['\n','\n'] is one delimiter in, for example, ['a', '\n', '\n', 'b'] line | 08:39 |
gsomix | need to go at one-hour lecture about theoretical cs. cu little later. | 08:41 |
sonne|work | gsomix: then we have to make it work with that - I can ask van51 to do that when he is back online | 08:42 |
shogun-buildbot | build #1308 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/1308 blamelist: van51 <vangelis_51@hotmail.com> | 08:51 |
-!- van51 [~van51@athedsl-408350.home.otenet.gr] has joined #shogun | 08:58 | |
-!- van51 [~van51@athedsl-408350.home.otenet.gr] has left #shogun [] | 09:01 | |
-!- van51 [~van51@athedsl-408350.home.otenet.gr] has joined #shogun | 09:01 | |
van51 | sonne|work: hey | 09:01 |
van51 | sonne|work: I went with that approach because I had problems calling a copy constructor or doing the = thing, as it was saying that CTokenizer is abstract | 09:04 |
van51 | sonne|work: and I figured that I would either have to take cases -depending on the subclass call the appropriate copy constr- | 09:05 |
sonne|work | van51: I see. If we figure out how to do it with a copy constructor later we should convert to that. Currently it is ok as is but it will confuse people. | 09:06 |
van51 | sonne|work: ok, sure :) | 09:07 |
sonne|work | van51: btw gsomix just said taht DelimiterTokenizer thinks ['\n','\n'] is one delimiter in, for example, ['a', '\n', '\n', 'b'] line | 09:07 |
sonne|work | van51: so you cannot have empty lines - which we should support too | 09:07 |
van51 | sonne|work: it was in the description that skips consecutive delimiters | 09:07 |
van51 | sonne|work: but I can change that | 09:08 |
-!- nube1 [~rho@116.90.239.3] has joined #shogun | 09:08 | |
-!- nube [~rho@116.90.239.3] has quit [Read error: Connection reset by peer] | 09:08 | |
sonne|work | yeah please don't skip | 09:09 |
van51 | sonne|work: btw, how much should I expect a run on the webspam dataset to take? | 09:09 |
sonne|work | van51: think about you have a .csv file and empty entries | 09:09 |
van51 | sonne|work: I used it on 5k examples last night | 09:09 |
sonne|work | van51: depends on a lot of factors, n-gram size, C, epsilon | 09:09 |
van51 | sonne|work: and it took well over two hours | 09:09 |
sonne|work | van51: yeah these documents are long so using the converter here would be much faster | 09:10 |
sonne|work | van51: btw enable progress output then you will at least see sth | 09:10 |
van51 | sonne|work: ok | 09:11 |
van51 | sonne|work: I g2g for now | 09:11 |
-!- zxtx [~zv@cpe-75-83-151-252.socal.res.rr.com] has joined #shogun | 09:11 | |
van51 | sonne|work: I'll make the changes in the tokenizer when I get back | 09:11 |
sonne|work | van51: thanks | 09:12 |
van51 | cya | 09:12 |
-!- van51 [~van51@athedsl-408350.home.otenet.gr] has left #shogun ["QUIT :Leaving."] | 09:12 | |
-!- votjakovr [~votjakovr@host-46-241-3-209.bbcustomer.zsttk.net] has joined #shogun | 09:37 | |
-!- lisitsyn [~lisitsin@mxs.kg.ru] has joined #shogun | 09:59 | |
-!- hushell [~hushell@c-24-21-141-32.hsd1.or.comcast.net] has quit [Quit: WeeChat 0.3.7] | 10:18 | |
-!- iglesiasg [~iglesias@n131-p244.kthopen.kth.se] has joined #shogun | 10:42 | |
-!- mode/#shogun [+o iglesiasg] by ChanServ | 10:42 | |
-!- iglesiasg [~iglesias@n131-p244.kthopen.kth.se] has quit [Client Quit] | 10:46 | |
-!- iglesiasg_ [~iglesias@n131-p244.kthopen.kth.se] has joined #shogun | 10:46 | |
-!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout] | 11:02 | |
-!- nube1 [~rho@116.90.239.3] has quit [Ping timeout: 256 seconds] | 11:12 | |
--- Log closed Thu Jul 04 11:27:02 2013 | ||
--- Log opened Thu Jul 04 11:27:11 2013 | ||
-!- shogun-t1olbox [~shogun@7nn.de] has joined #shogun | 11:27 | |
-!- Irssi: #shogun: Total of 16 nicks [1 ops, 0 halfops, 0 voices, 15 normal] | 11:27 | |
-!- Irssi: Join to #shogun was synced in 9 secs | 11:27 | |
-!- Netsplit *.net <-> *.split quits: wiking, shogun-toolbox | 11:32 | |
-!- HeikoS [~heiko@nat-178-25.internal.eduroam.ucl.ac.uk] has joined #shogun | 11:45 | |
-!- mode/#shogun [+o HeikoS] by ChanServ | 11:45 | |
-!- nube [~rho@116.90.239.3] has joined #shogun | 11:48 | |
sonne|work | gsomix: did you read the logs? | 11:48 |
sonne|work | wiking_: poing? | 11:48 |
-!- lambday [67157c4d@gateway/web/cgi-irc/kiwiirc.com/ip.103.21.124.77] has joined #shogun | 11:56 | |
lambday | HeikoS: hi | 11:56 |
@HeikoS | hi | 11:56 |
lambday | HeikoS: I am in the lab but I can talk a bit | 11:56 |
@HeikoS | lambday: ok, :) | 11:56 |
lambday | HeikoS: it was necessary to remove C | 11:56 |
@HeikoS | first question: why remove the C? | 11:56 |
lambday | wait let me show you | 11:56 |
lambday | and also regarding the IO/base param thing | 11:58 |
lambday | I made a small c++ code that shows it fails | 11:58 |
lambday | I'll paste it | 11:58 |
lambday | HeikoS: https://github.com/lambday/shogun/blob/feature/log_determinant/src/shogun/base/class_list.cpp.templ#L40 | 11:59 |
lambday | here it searches for the classes | 11:59 |
lambday | the class_list, however, contains class names without the C | 11:59 |
lambday | so if I use C, it can't find anything and fails | 11:59 |
lambday | returns NULL | 11:59 |
@HeikoS | lambday: why do the others work? | 12:01 |
@HeikoS | lambday: I mean, why are only your classes failing? | 12:02 |
lambday | HeikoS: I am not sure | 12:02 |
lambday | :( | 12:02 |
lambday | but others too shouldn't... cause the class name doesn't contain C, if get_name returns the classname with C, it should fail | 12:03 |
lambday | class_name in class list I mean | 12:03 |
@HeikoS | get_name never returns C | 12:03 |
@HeikoS | I tried clone for some, it works | 12:04 |
lambday | that's what I made the mistake | 12:04 |
lambday | I didn't change the class name but just changed get_name returns | 12:04 |
@HeikoS | explain | 12:04 |
lambday | what get_name return* | 12:04 |
lambday | umm.. | 12:04 |
@HeikoS | so get_name should always return the class name without the "C" | 12:05 |
lambday | CDenseMatrixOperator::get_name() const | 12:05 |
lambday | { | 12:05 |
lambday | ....return "DenseMatrixOperator"; | 12:05 |
lambday | } | 12:05 |
lambday | yes | 12:05 |
@HeikoS | but every subclass of CSGObject should have a C prefix in the class name | 12:05 |
sonne|work | gsomix: read the logs? | 12:05 |
sonne|work | gsomix: van51 will take care of the multiple delimiter case | 12:05 |
@HeikoS | sonne|work: maybe you can help out here? | 12:05 |
@HeikoS | lambday: could you explain again the issue to sonne|work? | 12:05 |
sonne|work | HeikoS: hey! whats up? | 12:05 |
lambday | how the class_list is populated? reading the directories | 12:05 |
lambday | ?? | 12:05 |
sonne|work | it takes all classes with C prefix | 12:06 |
lambday | okay | 12:06 |
sonne|work | that are not Abstract | 12:06 |
sonne|work | as in it tries to detect virtual foo() = 0; | 12:06 |
lambday | but when I see class_list.cpp, if strips the C from the name | 12:06 |
lambday | :( | 12:06 |
sonne|work | yes but? | 12:07 |
lambday | that's why it fails | 12:07 |
lambday | :( | 12:07 |
@HeikoS | lambday: explain the issue from the beginning, what the problem is | 12:07 |
lambday | alright | 12:07 |
sonne|work | sry going for lunch now. | 12:07 |
lambday | sonne|work: alright... | 12:07 |
sonne|work | explain it in the meantime I will read the logs | 12:07 |
lambday | okay :) | 12:07 |
lambday | so, CSGObject::clone() calls new_sgserializable.... takes class name and ptype as params... now, in that, it searches for class_list and tries to find the name that matches with it... | 12:08 |
lambday | since class_list strips "C", so it can't find it and returns NULL | 12:09 |
lambday | HeikoS: am I being able to explain it? :( | 12:09 |
@HeikoS | lambday: I suggest the following: write a small program which calls clone on a different class, i.e. GaussianKernel (I know that this one works) and debug it to see what happens and why it works for that | 12:10 |
lambday | HeikoS: alright.. | 12:11 |
@HeikoS | lambday: should be just 5 lines or so | 12:11 |
lisitsyn | lambday: yes you need to have get_name returning name w/o C | 12:11 |
lambday | lisitsyn: yes that's what I figured | 12:11 |
lambday | but then why GaussianKernel works | 12:12 |
lambday | HeikoS: I'll check it soon... and regarding that c++ thing I was talking about.. please have a look at this - https://gist.github.com/lambday/5926529#file-inherit_prob-cpp-L48 | 12:12 |
lambday | it explains the scenario that we have.. | 12:13 |
lambday | if you uncomment that line, it doesn't compile | 12:13 |
lisitsyn | lambday: what is wrong with GaussianKernel? | 12:13 |
lambday | lisitsyn: its working right, that's wrong :D | 12:13 |
lambday | lisitsyn: wait I'm checking | 12:14 |
lambday | HeikoS: https://github.com/lambday/shogun/blob/feature/log_determinant/src/shogun/kernel/GaussianKernel.h#L102 | 12:14 |
lambday | it returns without C | 12:14 |
lambday | lisitsyn: nothing is wrong apparently | 12:15 |
@HeikoS | lambday, lisitsyn I am confused :D | 12:15 |
lambday | HeikoS: me too :-/ | 12:15 |
@HeikoS | are there any problems? if yes what are they? :) | 12:15 |
lambday | HeikoS: there are not... get_name should return the class name w/o "C" prefix | 12:15 |
lambday | otherwise it won't work | 12:15 |
lambday | GaussianKernel does that, so it works | 12:16 |
@HeikoS | lambday: yep, but every class does that | 12:16 |
@HeikoS | this is how it should be done | 12:16 |
@HeikoS | wiking_: and this is why we need the clone unit tests! ;) | 12:16 |
lambday | HeikoS: I made a mistake and added "C" in its get_name, that was the mistake :( | 12:16 |
lambday | now I changed it | 12:16 |
gsomix | sonne|work, yeah, it's cool. | 12:16 |
@HeikoS | lambday: I see | 12:16 |
lambday | in the PR | 12:16 |
@HeikoS | lambday: but you also made some classes without the C | 12:17 |
@HeikoS | - return "CDenseExactLogJob";+ return "DenseExactLogJob"; | 12:17 |
@HeikoS | and others | 12:17 |
@HeikoS | and if you do that, you do not have m_parameters anymore | 12:17 |
lambday | its the get_name only, right? | 12:17 |
@HeikoS | yes | 12:19 |
lambday | I changed all the get_names where I used "C" prefix | 12:19 |
@HeikoS | later on there will be more confusion | 12:19 |
@HeikoS | when we add the modular interfaces | 12:19 |
@HeikoS | lambday: in facts in my fault not spotting the C :) | 12:19 |
@HeikoS | I will merge the PR now right? | 12:20 |
@HeikoS | lambday: ah wait | 12:20 |
@HeikoS | do we really need this additional list in the clasS_list.py? | 12:20 |
@HeikoS | I dont like that | 12:20 |
lambday | HeikoS: but all classes are supposed to return class names without "C", now I changed it for all... would it cause problem for modular interfaces? | 12:20 |
lambday | HeikoS: yes :( | 12:20 |
lambday | HeikoS: because.. | 12:20 |
@HeikoS | lambday: no modular interfaces are different | 12:21 |
@HeikoS | lambday: also this here cannot be done: | 12:21 |
@HeikoS | CSGObject::m_parameters->add(&m_operator, "dense_matrix", | 12:21 |
@HeikoS | ah wait | 12:21 |
@HeikoS | thats the c++ issue right? | 12:21 |
lambday | HeikoS: yep | 12:21 |
@HeikoS | so no problems with base class not there | 12:21 |
lambday | HeikoS: the gist I pasted | 12:21 |
@HeikoS | it will still add the parmeters to the base class? | 12:22 |
@HeikoS | we should think about that | 12:22 |
@HeikoS | maybe our c++ guru has an idea | 12:22 |
lambday | :D | 12:22 |
@HeikoS | lisitsyn: could you check this gist by lambday? | 12:22 |
lambday | lisitsyn: https://gist.github.com/lambday/5926529#file-inherit_prob-cpp-L48 | 12:22 |
lambday | HeikoS: and about that class_list thing, yes its ugly but I couldn't find other ways :( | 12:23 |
lambday | and its required, since we need new_sgserializable to work for PT_COMPLEX64 too... | 12:23 |
lambday | earlier, it just returned NULL... (that I added cause std::complex doesn't overload all the operators that other ptypes can handle, therefore make fails) | 12:24 |
lambday | now that we need complex to work for these template classes, I don't want them to return NULL but rather create an object | 12:24 |
lambday | (lol I am confused how to explain it properly :( ) | 12:25 |
lambday | so, for these particular classes, I create obj and for the rest return NULL... | 12:25 |
lambday | so, new_sgserializable works properly | 12:26 |
lambday | HeikoS: this is something that me and lisitsyn discussed last night.. | 12:26 |
lambday | :-/ | 12:26 |
@HeikoS | lambday: but cant we change something else? | 12:27 |
@HeikoS | I seems annoying to add all complex classes to this list in a secret python file | 12:27 |
lisitsyn | re | 12:27 |
@HeikoS | ah guru | 12:28 |
lambday | HeikoS: I think there should be better way to handle that.. our script should be able to handle that | 12:28 |
lambday | oh no | 12:28 |
lambday | no it can't :-/ | 12:28 |
@HeikoS | lisitsyn: do you have any ideas how to solve this? | 12:28 |
lambday | we can't see if the any method of that classes uses +=, -= etc.. | 12:28 |
lisitsyn | I am a bit lost | 12:28 |
lambday | (those are the main culprits why complex fails) | 12:28 |
lisitsyn | HeikoS: solve what? | 12:28 |
@HeikoS | man I really hope nobody reads this discussion, no-one will ever again develop for shogun ;) | 12:28 |
lambday | HeikoS: :( | 12:29 |
@HeikoS | lambday: could you elaborate again (you can do that better than me) | 12:29 |
lambday | HeikoS: :( :( okay I am trying again | 12:29 |
lisitsyn | just in a few words as I am bad in switching contexts :D | 12:29 |
lisitsyn | I see some gist | 12:29 |
lisitsyn | what's up with gist? | 12:29 |
lambday | lisitsyn: so its the class_list.cpp.py thing that we talked about last night | 12:29 |
lisitsyn | lambday: ok what's up with it? | 12:30 |
lambday | lisitsyn: I added a list of classes that we need new complex object in its _new_xxxx | 12:30 |
lisitsyn | yes | 12:30 |
lambday | but adding those classes manually to the script is ugly | 12:30 |
lambday | is there any alternative that's pretty :( | 12:31 |
lisitsyn | well you'd have to mark them some way | 12:32 |
lambday | point to note is that, complex fails only for +=, -=, /=, */ | 12:32 |
lambday | if our script can handle that, then we can automate it | 12:32 |
lisitsyn | no I wouldn't go for that | 12:32 |
lambday | that's even uglier isn't it :( | 12:33 |
lisitsyn | lambday: you can add a dummy typedef here | 12:33 |
lisitsyn | and search for it | 12:33 |
lambday | lisitsyn: like? | 12:34 |
lisitsyn | typedef bool SupportsComplex; | 12:34 |
lisitsyn | inside class | 12:34 |
lambday | inside the clas? | 12:34 |
lambday | oh | 12:34 |
lisitsyn | yes | 12:34 |
lisitsyn | either way you can add a static field | 12:34 |
lisitsyn | static bool SupportsComplex; | 12:35 |
lisitsyn | like that | 12:35 |
lambday | then, how about CGSObject has that, and initializes to false by default, and its subclasses that support sets it to true | 12:35 |
lambday | CSG* | 12:35 |
lisitsyn | you don't need inheritance here | 12:35 |
lisitsyn | you don't call methods you just need to have some mark | 12:35 |
lambday | okay... | 12:36 |
lambday | and in the script? | 12:36 |
lambday | I just check if that name is there?? | 12:36 |
lambday | that line | 12:36 |
lisitsyn | yes I think so | 12:36 |
lambday | ummm.... | 12:37 |
lisitsyn | lambday: just add 'typedef bool supports_complex_tag;' inside your classes | 12:37 |
lisitsyn | and search for it | 12:37 |
lambday | okay then... | 12:37 |
@HeikoS | guru has spoken :) | 12:37 |
@HeikoS | thanks a lot, lisitsyn! | 12:37 |
lisitsyn | haha HeikoS | 12:37 |
@HeikoS | sounds like this might work | 12:37 |
lambday | :D | 12:37 |
lisitsyn | lambday: other way you can do that with macroses | 12:38 |
lisitsyn | like IGNORE_IN_CLASSLIST | 12:38 |
lambday | yes... | 12:38 |
lambday | macro in this sense is better | 12:38 |
lisitsyn | but I like C++y things | 12:38 |
lisitsyn | :) | 12:38 |
lambday | #ifdef types | 12:38 |
lisitsyn | why? | 12:38 |
lisitsyn | it is less safe | 12:38 |
lambday | lisitsyn: umm.. why less safe? | 12:38 |
lisitsyn | macroses are defined in the whole compilation unit scope | 12:39 |
lisitsyn | so clashes may get it funny | 12:39 |
lambday | aha! | 12:39 |
lisitsyn | it is unlikely to get a clash with some internal typedef or internal structure definition | 12:39 |
lambday | lisitsyn: yes.. | 12:40 |
lisitsyn | lambday: furthermore one can use it later in C++ | 12:40 |
lisitsyn | through SFINAE for example | 12:40 |
lisitsyn | to check if class supports complex | 12:40 |
lisitsyn | lunch time be back in a bit | 12:40 |
lambday | lisitsyn: alright | 12:40 |
lambday | lisitsyn: thanks a lot :D | 12:41 |
lambday | HeikoS: this should work :D | 12:41 |
@HeikoS | yep sounds reasonable | 12:41 |
lambday | alright... I'll change | 12:42 |
lambday | oh about the c++ issue.. | 12:42 |
lambday | HeikoS: lisitsyn: if you uncomment this line it gives error : https://gist.github.com/lambday/5926529#file-inherit_prob-cpp-L49 | 12:43 |
lambday | HeikoS: brb | 12:46 |
-!- foulwall [~user@2001:da8:215:6100:79d6:1517:f4b8:d872] has joined #shogun | 12:48 | |
-!- iglesiasg_ [~iglesias@n131-p244.kthopen.kth.se] has quit [Quit: Ex-Chat] | 12:55 | |
-!- iglesiasg_ [~iglesias@2001:6b0:1:1041:7960:5f80:523d:4778] has joined #shogun | 12:56 | |
-!- iglesiasg_ is now known as iglesiasg | 12:56 | |
-!- mode/#shogun [+o iglesiasg] by ChanServ | 12:56 | |
lambday | back | 13:05 |
sonne|work | lambday: good to see everything is fine :) | 13:13 |
lambday | sonne|work: yes :) | 13:14 |
lambday | HeikoS: lisitsyn sonne|work: I'll modify the script at night | 13:14 |
@HeikoS | lambday: okay! thanks! | 13:15 |
lambday | HeikoS: man thanks for pointing out the clone thing :D otherwise I would never have found this bug | 13:15 |
@HeikoS | lambday: I did not really do anything :) | 13:16 |
lambday | HeikoS: you're the guru for me :) | 13:18 |
foulwall | Hi sonne|work, I'm rewriting the toy data uploader in django's file upload model, the code now is a little ugly, and there's not any security measure, I'll add some limit to it. | 13:18 |
lambday | HeikoS: lisitsyn sonne|work see you at night | 13:18 |
@HeikoS | lambday: see you! :) | 13:18 |
-!- lambday [67157c4d@gateway/web/cgi-irc/kiwiirc.com/ip.103.21.124.77] has quit [Quit: lambday] | 13:18 | |
-!- nube [~rho@116.90.239.3] has quit [Ping timeout: 264 seconds] | 13:19 | |
sonne|work | foulwall: why do you do any data uploader? | 13:19 |
sonne|work | foulwall: just reading fixed data from a certain directory is all we want for demos | 13:19 |
foulwall | no, just hd5 | 13:19 |
sonne|work | foulwall: not sure what you mean | 13:20 |
sonne|work | the idea was to just have a directory with .h5 files that one can select in the demo | 13:20 |
foulwall | Argh, I thought I need to implement a uploader. I got it. | 13:25 |
sonne|work | foulwall: no uploader at this stage no | 13:25 |
foulwall | ok. that's easy to roll back... | 13:26 |
sonne|work | foulwall: if we have time this can be done later | 13:28 |
foulwall | gotcha. I'll have a look at the data set list cheng suggests and make a convert. | 13:31 |
foulwall | :) | 13:31 |
-!- nube [~rho@116.90.239.3] has joined #shogun | 13:41 | |
sonne|work | foulwall: no just use this one data set that we have and make a list of files where just this one can be selected | 13:42 |
sonne|work | foulwall: once this basic infrastructure is there I can add reasonable files and we can extend examples | 13:43 |
foulwall | sonne|work: ah? you mean shogun-data? | 13:46 |
sonne|work | foulwall: yeah this one .h5 data set in there | 13:46 |
foulwall | ok | 13:47 |
foulwall | sonne|work: still not quite catch you, there's only a australian.libsvm.h5 in shogun-data, is that one? | 13:52 |
sonne|work | yeah | 13:58 |
-!- gsomix [~gsomix@109.188.124.219] has quit [Ping timeout: 256 seconds] | 13:58 | |
-!- foulwall [~user@2001:da8:215:6100:79d6:1517:f4b8:d872] has quit [Ping timeout: 264 seconds] | 14:02 | |
-!- foulwall` [~user@2001:da8:215:6100:2cc4:6e07:d549:4753] has joined #shogun | 14:05 | |
foulwall` | oh, http://foulwall.com:8000/svr/entrance , I have did a simple | 14:05 |
foulwall` | importer about one month ago, the data set seem not appropriate | 14:05 |
foulwall` | for svr, I'll add a directory to store h5s and do some simple | 14:05 |
foulwall` | refractoring. | 14:05 |
-!- foulwall` [~user@2001:da8:215:6100:2cc4:6e07:d549:4753] has quit [Remote host closed the connection] | 14:12 | |
-!- iglesiasg_ [~iglesias@n131-p244.kthopen.kth.se] has joined #shogun | 14:18 | |
-!- iglesiasg_ [~iglesias@n131-p244.kthopen.kth.se] has quit [Client Quit] | 14:18 | |
-!- iglesiasg__ [~iglesias@2001:6b0:1:1041:7960:5f80:523d:4778] has joined #shogun | 14:18 | |
-!- iglesiasg [~iglesias@2001:6b0:1:1041:7960:5f80:523d:4778] has quit [Read error: Connection reset by peer] | 14:20 | |
-!- foulwall [~user@2001:da8:215:6100:6891:dc16:b54:6ea7] has joined #shogun | 14:39 | |
-!- nube [~rho@116.90.239.3] has quit [Ping timeout: 245 seconds] | 14:45 | |
-!- gsomix [~gsomix@109.188.125.165] has joined #shogun | 14:49 | |
sonne|work | foulwall: yes it is not the best choice | 14:56 |
sonne|work | foulwall: but it is enough for proof of concept | 14:56 |
-!- lambday [67157d4c@gateway/web/freenode/ip.103.21.125.76] has joined #shogun | 15:06 | |
-!- foulwall [~user@2001:da8:215:6100:6891:dc16:b54:6ea7] has quit [Ping timeout: 245 seconds] | 15:07 | |
lambday | HeikoS: there? | 16:03 |
-!- iglesiasg__ [~iglesias@2001:6b0:1:1041:7960:5f80:523d:4778] has quit [Quit: Ex-Chat] | 16:12 | |
-!- gsomix [~gsomix@109.188.125.165] has quit [Quit: Leaving] | 16:16 | |
-!- kevin_ [~Kevin@d67-193-243-174.home3.cgocable.net] has joined #shogun | 16:36 | |
-!- kevin_ is now known as pickle27_home | 16:36 | |
-!- pickle27_home [~Kevin@d67-193-243-174.home3.cgocable.net] has quit [Ping timeout: 246 seconds] | 17:12 | |
-!- van51 [~van51@athedsl-408350.home.otenet.gr] has joined #shogun | 17:12 | |
-!- pickle27_home [~Kevin@d67-193-243-174.home3.cgocable.net] has joined #shogun | 17:12 | |
@HeikoS | lambday: now | 17:40 |
@HeikoS | sorry was in a meeting | 17:40 |
lambday | HeikoS: no problem... I am fixing the script | 17:41 |
lambday | HeikoS: by the way, for the unit-test for accuracy as per Hale's paper | 17:41 |
lambday | we have to do that for the operator function | 17:41 |
lambday | using trace samples we won't get that accuracy | 17:42 |
lambday | so, | 17:42 |
lambday | I should use const vectors for testing the accuracy, right | 17:42 |
lambday | ? | 17:42 |
@HeikoS | lambday: good point | 17:43 |
@HeikoS | lambday: yes constant vectors, just extract the trace | 17:43 |
@HeikoS | i.e. use all basis vectors | 17:43 |
@HeikoS | once | 17:43 |
lambday | yes that's what I thought of :) | 17:43 |
@HeikoS | lambday: good :) | 17:43 |
@HeikoS | votjakovr: how is the logit going? | 17:44 |
votjakovr | HeikoS: hi, sorry, didn't send a PR yesterday (find some bugs) :( | 17:45 |
-!- nube [~rho@49.244.93.13] has joined #shogun | 17:45 | |
@HeikoS | votjakovr: dont worry, just asking what the state is | 17:45 |
@HeikoS | bugs are happening where? | 17:46 |
votjakovr | HeikoS: in evaluating of predictive mean and variance | 17:46 |
votjakovr | HeikoS: i do that not correctly | 17:47 |
@HeikoS | votjakovr: ok, let me know if you have problems | 17:48 |
votjakovr | HeikoS: i mean i *did* that not correctly | 17:48 |
@HeikoS | votjakovr: so its working now? | 17:48 |
votjakovr | HeikoS: nope, i'm fixing | 17:48 |
pickle27_home | lisitsyn: Im walking to the lab now so I'll be talking from my reg irc name in about 15 mins if you want to discuss my latest PR | 17:49 |
-!- pickle27_home [~Kevin@d67-193-243-174.home3.cgocable.net] has quit [Quit: Leaving] | 17:49 | |
@HeikoS | votjakovr: ok, keep me updated on those things, its good for me to know what you are currently doing ... | 17:50 |
-!- foulwall [~user@2001:da8:215:c252:880e:eabd:c036:2b7] has joined #shogun | 17:51 | |
votjakovr | HeikoS: btw since we have p(y*=1|x*) and apply_binary(x*) method returns y=-1 or 1 for each feature x*, so i did that this method returns y*=1 if p(y*=1|x*)>=0.5, and y*=-1 otherwise for each feature x*. Is it good? | 17:54 |
@HeikoS | votjakovr: that is good | 17:55 |
@HeikoS | but it is also possible to get the probability scores right? | 17:56 |
@HeikoS | they should be stored in the results somewhere also | 17:56 |
votjakovr | HeikoS: sure, we can get predictive mean and predictive variance | 17:56 |
votjakovr | HeikoS: like in regression | 17:56 |
@HeikoS | votjakovr: ok good then | 17:57 |
@HeikoS | votjakovr: oh but does it work in the same way as the svm predictions? | 17:58 |
@HeikoS | because that would be good | 17:58 |
@HeikoS | svm's apply returns binary labels, which store the scores internally also | 17:58 |
votjakovr | HeikoS: for example: if we want to get scores, we call something like gpc.get_mean_vector(features); if we want to get labels, we call gpc.apply_binary(features) | 18:04 |
@HeikoS | votjakovr: I know, that is good, however, if you call svm->apply() you get binary labels, which internally also store the scores of the SVM, the GPC should do the same | 18:04 |
votjakovr | HeikoS: and will get_mean_vector() return that scores? | 18:07 |
@HeikoS | votjakovr: yes | 18:07 |
votjakovr | HeikoS: Ok :) | 18:07 |
van51 | sonney2k, sonne|work: made a PR for the delimiter | 18:17 |
-!- FSCV [~FSCV@50.7.50.60] has joined #shogun | 18:18 | |
pickle27 | lisitsyn: any comments on the latest JADiag PR? | 18:20 |
lisitsyn | pickle27: sorry got overloaded here | 18:21 |
lisitsyn | pickle27: I have seen you made a unit-test | 18:22 |
votjakovr | HeikoS: i've just sent a PR with log(normal_cdf(x)) function | 18:24 |
pickle27 | lisitsyn: no worries, whenever you get a chance! | 18:24 |
pickle27 | lisitsyn: looks like the unit test isn't totally perfect, it generates random data and its only working half the time | 18:25 |
votjakovr | HeikoS: i'm trying not to send big patches | 18:25 |
pickle27 | lisitsyn: it should use a chi square dist but there wasn't an easy way to do so, so I stuck with reg gaussian which might be why | 18:26 |
@HeikoS | votjakovr: cool Ill have a look | 18:26 |
@HeikoS | votjakovr: thanks for the typo fixes :) they were my fault | 18:27 |
pickle27 | lisitsyn: slash that travis fail is the only time I've seen it not work but I've only ran it a dozen or so times | 18:27 |
@HeikoS | votjakovr: I have put two minor comments | 18:28 |
@HeikoS | votjakovr: will merge anyway, please add them in the next PR :) | 18:28 |
-!- shogun-notifier- [~irker@7nn.de] has joined #shogun | 18:29 | |
shogun-notifier- | shogun: Roman Votyakov :develop * 2d8d5a2 / / (3 files): https://github.com/shogun-toolbox/shogun/commit/2d8d5a26f80cb930747227a8f4f427377e9e43c0 | 18:29 |
shogun-notifier- | shogun: add log(normal_cdf(x)) function | 18:29 |
shogun-notifier- | shogun: Heiko Strathmann :develop * 7f3ea0a / / (3 files): https://github.com/shogun-toolbox/shogun/commit/7f3ea0a4cf3ccab5dda3b3919db7093c86df14c1 | 18:29 |
shogun-notifier- | shogun: Merge pull request #1210 from votjakovr/feature/gp_binary_classification | 18:29 |
shogun-notifier- | shogun: | 18:29 |
shogun-notifier- | shogun: add log(normal_cdf(x)) function | 18:29 |
votjakovr | HeikoS: Ok, i'll fix documentation | 18:29 |
-!- foulwall [~user@2001:da8:215:c252:880e:eabd:c036:2b7] has quit [Ping timeout: 264 seconds] | 18:31 | |
votjakovr | HeikoS: btw i think that we should have something for approximation of integral of one variable or use external library for that | 18:35 |
@HeikoS | votjakovr: I agree | 18:41 |
@HeikoS | very good point, this should be in statistics | 18:41 |
@HeikoS | votjakovr: could you do that? | 18:41 |
lisitsyn | more code for the code god | 18:43 |
@HeikoS | lisitsyn: all hail the code god :D | 18:43 |
@HeikoS | votjakovr: maybe have a look around if you can find things for that, like alglib or so | 18:44 |
shogun-buildbot | build #1185 of bsd1 - libshogun is complete: Failure [failed test_1] Build details are at http://www.shogun-toolbox.org/buildbot/builders/bsd1%20-%20libshogun/builds/1185 blamelist: Roman Votyakov <votjakovr@gmail.com> | 18:44 |
@HeikoS | I would not use external libraries but rather copy/paste it, as it will be a very short fragment | 18:44 |
@HeikoS | obviously depends | 18:44 |
votjakovr | HeikoS: ok, i'll try to find something :) | 18:50 |
shogun-buildbot | build #1186 of bsd1 - libshogun is complete: Failure [failed test_1] Build details are at http://www.shogun-toolbox.org/buildbot/builders/bsd1%20-%20libshogun/builds/1186 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com> | 18:53 |
shogun-buildbot | build #1309 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/1309 blamelist: Roman Votyakov <votjakovr@gmail.com> | 19:07 |
-!- iglesiasg [~iglesias@2001:6b0:1:1041:39c0:6b00:3982:6d7e] has joined #shogun | 19:09 | |
-!- mode/#shogun [+o iglesiasg] by ChanServ | 19:09 | |
-!- travis-ci [~travis-ci@ec2-184-73-0-135.compute-1.amazonaws.com] has joined #shogun | 19:27 | |
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/8739743 | 19:27 |
-!- travis-ci [~travis-ci@ec2-184-73-0-135.compute-1.amazonaws.com] has left #shogun [] | 19:27 | |
lambday | HeikoS: I updated the PR | 19:29 |
lambday | please have a look.. I'll be back after dinner | 19:29 |
shogun-buildbot | build #1310 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/1310 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com> | 19:30 |
-!- lisitsyn [~lisitsin@mxs.kg.ru] has quit [Quit: Leaving.] | 19:45 | |
lambday | HeikoS: back | 20:20 |
@HeikoS | lambday: hi! | 20:21 |
@HeikoS | lambday: looking at the pr | 20:21 |
lambday | HeikoS: let me know if the script looks okay | 20:21 |
lambday | :-/ | 20:21 |
@HeikoS | lambday: looks good! | 20:22 |
-!- iglesiasg [~iglesias@2001:6b0:1:1041:39c0:6b00:3982:6d7e] has quit [Quit: Ex-Chat] | 20:22 | |
lambday | :) | 20:22 |
@HeikoS | lambday: one last question: why is this necessary for complex and not for the others? | 20:22 |
@HeikoS | sorry if I ask over an dover again, busy day, keep forgetting things ;) | 20:22 |
lambday | there are few more template classes that uses operators that std::complex doesn't support | 20:23 |
@HeikoS | class operators? | 20:23 |
@HeikoS | can you give an example? | 20:23 |
lambday | HeikoS: hehe don't worry about that :D I'll give you a tough competition about forgetting :D | 20:23 |
lambday | HeikoS: wait | 20:23 |
lambday | when I added it normally, many classes raised errors | 20:25 |
@HeikoS | what operators are that? | 20:25 |
lambday | I gotta check.. I'm checking | 20:26 |
lambday | http://www.cplusplus.com/reference/complex/complex/operators/ | 20:26 |
lambday | these are what complex supports | 20:26 |
@HeikoS | but what do we need and from where is it needed? | 20:27 |
lambday | HeikoS: yes checking that | 20:27 |
shogun-notifier- | shogun: lambday :develop * 503af31 / / (41 files): https://github.com/shogun-toolbox/shogun/commit/503af31b774042554f60ffab962f57e5484728f1 | 20:28 |
shogun-notifier- | shogun: bugfixes in log-det framework | 20:28 |
shogun-notifier- | shogun: Heiko Strathmann :develop * 218429e / / (41 files): https://github.com/shogun-toolbox/shogun/commit/218429e32aeb161b192ecae148c5e8656b530c55 | 20:28 |
shogun-notifier- | shogun: Merge pull request #1208 from lambday/feature/log_determinant | 20:28 |
shogun-notifier- | shogun: | 20:28 |
shogun-notifier- | shogun: bugfixes in log-det framework | 20:28 |
@HeikoS | lambday: merging for now so that we can continue, if sonney2k is fine with those changes, we can leave it as it is | 20:28 |
@HeikoS | lambday: what about those accuracy issues you talked about, are they gone now since memory errors are gone? | 20:29 |
@HeikoS | votjakovr: how are things with the integration and the logit bugs? | 20:29 |
lambday | HeikoS: accuracy now shows the behavior as the paper says | 20:29 |
@HeikoS | lambday: whooooo! :) | 20:29 |
lambday | increases with number of shifts and then becomes const | 20:29 |
lambday | I mean | 20:30 |
@HeikoS | very very good, this is a major step then | 20:30 |
lambday | I gotta do more checks but so far it seems | 20:30 |
lambday | yes :) | 20:30 |
@HeikoS | yes pls do intensive unit tests for that | 20:30 |
lambday | I'll add that unit-test (using base vectors) tonight only | 20:30 |
@HeikoS | since we will rely on it | 20:30 |
lambday | will reveal many things | 20:30 |
@HeikoS | good stuff | 20:30 |
lambday | yes yes! :D | 20:30 |
@HeikoS | so next steps? | 20:30 |
@HeikoS | cg methods? :) | 20:30 |
@HeikoS | should be pretty interesting those | 20:31 |
lambday | cocg | 20:31 |
lambday | oh and sparse matrix op | 20:31 |
lambday | cocg_m should work for both | 20:31 |
@HeikoS | oh yes | 20:31 |
@HeikoS | ok | 20:31 |
@HeikoS | I will go home soon | 20:31 |
lambday | HeikoS: okay :) | 20:31 |
@HeikoS | lambday: checking back tomorrow :) | 20:31 |
lambday | HeikoS: see you :) good night :) | 20:32 |
lambday | HeikoS: I'll list the problem that I was facing with complex.. I need some time to figure out exactly what is causing that | 20:32 |
lambday | comment in the PR itself may be | 20:33 |
@HeikoS | lambday: yeah ok, maybe sonney2k has some ideas, he wrote most of this stuff | 20:33 |
lambday | hmm | 20:33 |
votjakovr | HeikoS: i'm working on it (reading alglib)... i think will be ready tomorrow | 20:33 |
@HeikoS | votjakovr: does alglib have things? | 20:33 |
@HeikoS | if not you could also steal the gpml or gp_stuff code | 20:34 |
votjakovr | HeikoS: yep, but too hard to read it | 20:34 |
@HeikoS | votjakovr: yeah alglib is horror | 20:34 |
@HeikoS | votjakovr: I tool most functions in CStatistics from it | 20:34 |
@HeikoS | votjakovr: http://www.alglib.net/integration/gausskronrodquadratures.php | 20:34 |
@HeikoS | it has gauss kronrod | 20:34 |
@HeikoS | votjakovr: copying this stuff is a bit annoying: | 20:35 |
@HeikoS | votjakovr: all ==, <, <=, etc have to be replaces | 20:35 |
@HeikoS | and the std math function calls | 20:35 |
votjakovr | HeikoS: yep, i'm already looking at gauss-kronrod implementation | 20:35 |
votjakovr | HeikoS: Ok | 20:35 |
@HeikoS | votjakovr: have a look at the functions in CStatistics on how to do this | 20:35 |
@HeikoS | votjakovr: ok then, good luck, let me know how it goes, will go home now, see you tomorrow! | 20:36 |
votjakovr | HeikoS: good night, see you ;) | 20:36 |
-!- lisitsyn [~lisitsyn@46.20.65.245] has joined #shogun | 20:38 | |
lisitsyn | pickle27: alright I'm back | 20:39 |
lisitsyn | lets see your pr | 20:39 |
pickle27 | lisitsyn: sweet! | 20:39 |
lambday | HeikoS: found something! still here? | 20:43 |
@HeikoS | lambday: yes half :) | 20:43 |
lambday | += with complex and unsigned int | 20:43 |
lambday | for example | 20:43 |
shogun-buildbot | build #1187 of bsd1 - libshogun is complete: Failure [failed test_1] Build details are at http://www.shogun-toolbox.org/buildbot/builders/bsd1%20-%20libshogun/builds/1187 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com> | 20:43 |
lambday | CDenseFeatures.cpp | 20:43 |
lisitsyn | lambday: what's up? | 20:43 |
lambday | line 513 | 20:43 |
shogun-notifier- | shogun: Kevin :develop * ffb662e / src/shogun/mathematics/ajd/ (2 files): https://github.com/shogun-toolbox/shogun/commit/ffb662eb4d8572b73e6ccd64aa3d2066db27f6dd | 20:44 |
shogun-notifier- | shogun: added base class for AJD and an example of a derived class header | 20:44 |
shogun-notifier- | shogun: Kevin :develop * 3c3592a / src/shogun/mathematics/ajd/ (3 files): https://github.com/shogun-toolbox/shogun/commit/3c3592ae10b782195e5f8983259a05285415e4b8 | 20:44 |
shogun-notifier- | shogun: added JADiag.cpp and made some of the other suggested edits | 20:44 |
lambday | lisitsyn: it worked | 20:44 |
shogun-notifier- | shogun: Kevin :develop * 37cb7ba / src/shogun/mathematics/ajd/JADiag.cpp,src/shogun/mathematics/ajd/JADiag.h: https://github.com/shogun-toolbox/shogun/commit/37cb7ba3a8e423605ea3549163626e6458b6fd55 | 20:44 |
shogun-notifier- | shogun: fixed some minor mistakes so that it builds | 20:44 |
shogun-notifier- | shogun: Kevin :develop * f0abf7e / src/shogun/mathematics/ajd/ (3 files): https://github.com/shogun-toolbox/shogun/commit/f0abf7e4a4e803d8d2d05e45f48eae9fe6ed28c4 | 20:44 |
shogun-notifier- | shogun: swithed to cmath for machine eps and changed includes format | 20:44 |
shogun-notifier- | shogun: Kevin :develop * 8fb01ac / src/shogun/mathematics/ajd/ (3 files): https://github.com/shogun-toolbox/shogun/commit/8fb01accbf51ec1dcf10195b875494ce28a4e81d | 20:44 |
shogun-notifier- | shogun: changed pointer V0 to use an emtpy SGMatrix | 20:44 |
shogun-notifier- | shogun: Kevin :develop * cfb101a / / (4 files): https://github.com/shogun-toolbox/shogun/commit/cfb101a6811d805871350230bb66ee1106866c4b | 20:44 |
shogun-notifier- | shogun: added a unit test for JADiag and ifdefs for eigen3 | 20:44 |
shogun-notifier- | shogun: Sergey Lisitsyn :develop * 2664590 / / (4 files): https://github.com/shogun-toolbox/shogun/commit/26645905424e53272b20196fd623d66bcc076db3 | 20:44 |
shogun-notifier- | shogun: Merge pull request #1205 from pickle27/develop | 20:44 |
shogun-notifier- | shogun: | 20:44 |
shogun-notifier- | shogun: added base class for AJD and an example of a derived class header | 20:44 |
-!- gsomix [~gsomix@109.188.126.210] has joined #shogun | 20:44 | |
lisitsyn | pickle27: lets move on then ;) | 20:44 |
pickle27 | lisitsyn: sweet! | 20:44 |
gsomix | van51, thanks for PR | 20:45 |
gsomix | good evening | 20:45 |
pickle27 | lisitsyn: build bot might freak out for the next bit because I didn't have a chance to rebase before the merge | 20:46 |
lisitsyn | pickle27: oops | 20:46 |
lisitsyn | pickle27: let it be | 20:46 |
pickle27 | lisitsyn: all righty | 20:49 |
van51 | gsomix: np :) | 20:49 |
pickle27 | lisitsyn: I've got a quick meeting with my supervisor, Im submitting my thesis tomorrow! then I'll be back | 20:49 |
lisitsyn | pickle27: sure take your time | 20:49 |
pickle27 | lisitsyn: should have a PR for FFDiag pretty soon | 20:49 |
@HeikoS | lambday: | 20:52 |
@HeikoS | but that should be working not? | 20:52 |
lambday | https://gist.github.com/lambday/5929600 | 20:52 |
@HeikoS | these operators can be defined | 20:53 |
@HeikoS | and then the error is gone without this complex busyness in class_list? | 20:53 |
shogun-buildbot | build #1188 of bsd1 - libshogun is complete: Failure [failed test_1] Build details are at http://www.shogun-toolbox.org/buildbot/builders/bsd1%20-%20libshogun/builds/1188 blamelist: lambday <heavensdevil6909@gmail.com> | 20:53 |
@HeikoS | lambday: or am I wrong? | 20:53 |
-!- travis-ci [~travis-ci@ec2-54-224-215-138.compute-1.amazonaws.com] has joined #shogun | 20:53 | |
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/8742778 | 20:53 |
-!- travis-ci [~travis-ci@ec2-54-224-215-138.compute-1.amazonaws.com] has left #shogun [] | 20:53 | |
lambday | HeikoS: I didn't get you :( | 20:53 |
@HeikoS | uint8 a=1; complex64_t b=(2,1); a+b should return complex64_t(3,1) | 20:54 |
lambday | yes | 20:54 |
lambday | but there is const | 20:54 |
@HeikoS | lambday: so why not define these operators? | 20:54 |
lisitsyn | oh please not define such operators | 20:54 |
lambday | :-s | 20:55 |
@HeikoS | lisitsyn: reasons? | 20:55 |
@HeikoS | haha :D | 20:55 |
@HeikoS | I am just asking and trying to understand whats going on | 20:55 |
lambday | we won't be needing that anyway :-s | 20:55 |
lambday | yes :D | 20:55 |
lisitsyn | HeikoS: everything that could be casted to uint8 and complex64_t here | 20:55 |
lisitsyn | will use it | 20:55 |
@HeikoS | lisitsyn: so? | 20:55 |
lisitsyn | HeikoS: it may shoot ya leg ;) | 20:55 |
@HeikoS | ok then | 20:55 |
@HeikoS | already merged the class_list solution | 20:56 |
lisitsyn | struct p { p(int i) { ... } } | 20:56 |
lisitsyn | p operator+(const p& a, const p& b) { ... } | 20:56 |
lisitsyn | 2 + 3 | 20:56 |
lisitsyn | guess what may be called | 20:56 |
lisitsyn | :D | 20:56 |
-!- van51 [~van51@athedsl-408350.home.otenet.gr] has quit [Quit: Leaving.] | 20:57 | |
@HeikoS | lisitsyn: yep, good that I asked you ;) | 20:58 |
lisitsyn | HeikoS: not in case of 2 + 3 | 20:58 |
lisitsyn | but in case of | 20:58 |
lisitsyn | int a = 2; | 20:58 |
lisitsyn | int b = 3; | 20:58 |
lisitsyn | IIRC it could really be called | 20:58 |
lisitsyn | because your overloaded thing has some priority indeed | 20:58 |
lisitsyn | and types are cast'able | 20:59 |
lisitsyn | so why not? | 20:59 |
lisitsyn | :D | 20:59 |
* lambday faints | 20:59 | |
lisitsyn | HeikoS: that's why such operators should be member functions | 20:59 |
lisitsyn | they are of much more limited scope | 20:59 |
@HeikoS | I see, thanks! :) | 21:00 |
lisitsyn | HeikoS: but we can't extend complex64_t | 21:01 |
shogun-buildbot | build #1311 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/1311 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com> | 21:01 |
lisitsyn | HeikoS: and it slows down compilation (may be) :) | 21:04 |
@HeikoS | lisitsyn: you convinced me | 21:05 |
lisitsyn | HeikoS: hehe I am just thinking loudly | 21:05 |
shogun-buildbot | build #1176 of deb2 - static_interfaces is complete: Failure [failed compile libshogun] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb2%20-%20static_interfaces/builds/1176 blamelist: Kevin <kevinhughes27@gmail.com> | 21:06 |
@HeikoS | ok guys, really going now :) | 21:07 |
lambday | HeikoS: see you :) | 21:07 |
lambday | I too am sleepy.. :( | 21:07 |
@HeikoS | lambday: sleeping is important! :) | 21:07 |
@HeikoS | bye! | 21:07 |
lambday | bye :) | 21:07 |
-!- HeikoS [~heiko@nat-178-25.internal.eduroam.ucl.ac.uk] has quit [Quit: Leaving.] | 21:08 | |
shogun-buildbot | build #1189 of bsd1 - libshogun is complete: Failure [failed test_1] Build details are at http://www.shogun-toolbox.org/buildbot/builders/bsd1%20-%20libshogun/builds/1189 blamelist: Kevin <kevinhughes27@gmail.com> | 21:13 |
-!- travis-ci [~travis-ci@ec2-184-73-0-135.compute-1.amazonaws.com] has joined #shogun | 21:17 | |
travis-ci | [travis-ci] it's Sergey Lisitsyn'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/8743155 | 21:17 |
-!- travis-ci [~travis-ci@ec2-184-73-0-135.compute-1.amazonaws.com] has left #shogun [] | 21:17 | |
-!- lisitsyn [~lisitsyn@46.20.65.245] has left #shogun [] | 21:19 | |
shogun-buildbot | build #1190 of bsd1 - libshogun is complete: Failure [failed test_1] Build details are at http://www.shogun-toolbox.org/buildbot/builders/bsd1%20-%20libshogun/builds/1190 blamelist: Sergey Lisitsyn <lisitsyn.s.o@gmail.com> | 21:22 |
shogun-buildbot | build #1313 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/1313 blamelist: Sergey Lisitsyn <lisitsyn.s.o@gmail.com>, Kevin <kevinhughes27@gmail.com> | 21:23 |
shogun-buildbot | build #1312 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/1312 blamelist: lambday <heavensdevil6909@gmail.com> | 21:30 |
shogun-buildbot | build #1177 of deb2 - static_interfaces is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb2%20-%20static_interfaces/builds/1177 | 21:31 |
shogun-notifier- | shogun: van51 :develop * 98dbd98 / / (3 files): https://github.com/shogun-toolbox/shogun/commit/98dbd9853e72432b7ed5cf482170e981d71e0adb | 22:00 |
shogun-notifier- | shogun: Changed CDelimiterTokenizer behavior on consecutive delimiters | 22:00 |
shogun-notifier- | shogun: Soeren Sonnenburg :develop * ded6e97 / / (3 files): https://github.com/shogun-toolbox/shogun/commit/ded6e973a11d4cb7b7e023cc80c90f6efc65810b | 22:00 |
shogun-notifier- | shogun: Merge pull request #1209 from van51/feature/hashing | 22:00 |
shogun-notifier- | shogun: | 22:00 |
shogun-notifier- | shogun: Changed CDelimiterTokenizer behavior on consecutive delimiters | 22:00 |
@sonney2k | evening gents | 22:01 |
@sonney2k | gsomix, all good? | 22:01 |
@sonney2k | wiking_, around? | 22:03 |
shogun-buildbot | build #1178 of deb2 - static_interfaces is complete: Failure [failed test octave_static] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb2%20-%20static_interfaces/builds/1178 blamelist: Soeren Sonnenburg <sonne@debian.org> | 22:13 |
lambday | sonney2k: there? | 22:17 |
shogun-buildbot | build #1191 of bsd1 - libshogun is complete: Failure [failed test_1] Build details are at http://www.shogun-toolbox.org/buildbot/builders/bsd1%20-%20libshogun/builds/1191 blamelist: Soeren Sonnenburg <sonne@debian.org> | 22:17 |
@sonney2k | lambday, hey! | 22:18 |
lambday | sonney2k: hi :) | 22:18 |
@sonney2k | lambday, I have to leave train soon | 22:18 |
@sonney2k | wassup? | 22:18 |
@sonney2k | lambday, no time to sleep? | 22:18 |
lambday | sonney2k: okay... could you please have a look at my last PR and check if the changes I made with class_list.cpp.py are okay | 22:18 |
lambday | sonney2k: yes apparently :( | 22:18 |
lambday | 15-16 hours working daily :( | 22:19 |
shogun-notifier- | shogun: Soeren Sonnenburg :develop * 0ac043b / src/shogun/lib/external/libocas.cpp: https://github.com/shogun-toolbox/shogun/commit/0ac043b75386152ffca7e7ad985a86c1a6c9d905 | 22:19 |
shogun-notifier- | shogun: don't use reserverd keyword _C | 22:19 |
@sonney2k | lambday, checking | 22:19 |
@sonney2k | lambday, don't kill yourself | 22:19 |
lambday | *sigh* | 22:20 |
lambday | my insti :'( | 22:20 |
@sonney2k | lambday, where is your PR? | 22:20 |
lambday | its merged already | 22:20 |
@sonney2k | lambday, very good! | 22:20 |
lambday | sonney2k: for complex, we needed to handle it separately | 22:20 |
@sonney2k | lambday, shall I check nevertheless? | 22:20 |
@sonney2k | lambday, what is wrong with complex | 22:20 |
lambday | so, I modified class_list | 22:20 |
lambday | sonney2k: few template classes use operators that complex doesn't support | 22:21 |
@sonney2k | lambday, as in sgvector/matrix etc? | 22:21 |
lambday | so can't create new object for them for complex, I kept them as null.. and those that works, I added a typedef bool supports_compelx64_t, | 22:22 |
lambday | sonney2k: no, like DenseFeatures etc | 22:22 |
@sonney2k | lambday, it is not possible to have densefeatures of complex? | 22:22 |
@sonney2k | hmmhh | 22:22 |
@sonney2k | that is pretty stupid then | 22:23 |
@sonney2k | I think we have to find some solution for that to work at least long term wise | 22:23 |
lambday | sonney2k: what would be a better way to handle it? | 22:23 |
@sonney2k | lambday, no idea I don't yet know what the problem is | 22:23 |
@sonney2k | I guess dotfeatures? | 22:23 |
lambday | sonney2k: okay, if you're leaving then we can discuss it tomorrow in more detail may be? | 22:24 |
@sonney2k | sitting outside already | 22:24 |
@sonney2k | getting eaten by mosquitos alive | 22:24 |
lambday | errr... | 22:24 |
-!- travis-ci [~travis-ci@ec2-184-73-0-135.compute-1.amazonaws.com] has joined #shogun | 22:24 | |
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/8744995 | 22:24 |
-!- travis-ci [~travis-ci@ec2-184-73-0-135.compute-1.amazonaws.com] has left #shogun [] | 22:24 | |
lambday | the problem is with a few operators.. complex doesn't overload them all, that other ptypes support | 22:25 |
lambday | so, either we have to add support for them like I did for SGMatrix etc... or leave it as it is | 22:26 |
lambday | cause currently if I try to create new CDenseFeature<complex64_t>, compiler complains | 22:26 |
@sonney2k | lambday, IMHO it is rather a waste to not support the complex type in the C*Features | 22:27 |
@sonney2k | even as sole data containers it makes sense | 22:28 |
-!- iglesiasg [~nando@s83-179-44-135.cust.tele2.se] has joined #shogun | 22:28 | |
-!- mode/#shogun [+o iglesiasg] by ChanServ | 22:28 | |
@sonney2k | e.g. octave or so support complex data types too so | 22:28 |
@sonney2k | lambday, but not urgent | 22:28 |
shogun-buildbot | build #1192 of bsd1 - libshogun is complete: Failure [failed test_1] Build details are at http://www.shogun-toolbox.org/buildbot/builders/bsd1%20-%20libshogun/builds/1192 blamelist: van51 <vangelis_51@hotmail.com> | 22:28 |
lambday | sonney2k: so, I should add these supports later you're saying? | 22:29 |
lambday | and then we can get rid of this thing in class_list | 22:29 |
@sonney2k | lambday, yeah - or SG_NOTIMPLEMENTED even | 22:29 |
lambday | yes at least it should compile | 22:29 |
@sonney2k | lambday, maybe file a bug report so we don't forget | 22:29 |
lambday | alright.. I'll do it | 22:29 |
lambday | okay | 22:29 |
lambday | well, its not a bug :-/ | 22:30 |
lambday | but yeah, I'll create an issue with it | 22:30 |
@sonney2k | lambday, well lets call it a task then :) | 22:30 |
lambday | :) | 22:30 |
lambday | :D | 22:30 |
@sonney2k | we should then also add typemaps to support complex i/o from python/octave/R etc | 22:31 |
lambday | sonney2k: yes.. that is also pending | 22:31 |
@sonney2k | lambday, are you using any complex types that you want to pass around between languages? | 22:31 |
shogun-buildbot | build #1314 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/1314 blamelist: Soeren Sonnenburg <sonne@debian.org> | 22:31 |
@sonney2k | lambday, or do you need complex types just internally? | 22:32 |
lambday | its all internal for our project | 22:32 |
@sonney2k | ok then it is not prime priority but some simple thing to do later | 22:32 |
lambday | alright :) | 22:32 |
shogun-buildbot | build #1179 of deb2 - static_interfaces is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb2%20-%20static_interfaces/builds/1179 | 22:35 |
gsomix | sonney2k, dunno. working. | 22:36 |
shogun-notifier- | shogun: Soeren Sonnenburg :develop * 7062837 / src/interfaces/modular/modshogun_ignores.i: https://github.com/shogun-toolbox/shogun/commit/7062837ed457c6765530e430620b2615549d0dfe | 22:36 |
shogun-notifier- | shogun: ignore evaluate_means to fix csharp compile error | 22:36 |
@sonney2k | gsomix, ok I hope you are close to have this working with the delimitertokenizer? It would be great if we could move on tomorrow. | 22:37 |
@sonney2k | alright out of battery | 22:37 |
@sonney2k | brb | 22:37 |
shogun-buildbot | build #1315 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/1315 blamelist: van51 <vangelis_51@hotmail.com> | 22:49 |
lambday | good night people | 22:54 |
-!- lambday [67157d4c@gateway/web/freenode/ip.103.21.125.76] has quit [] | 22:54 | |
@sonney2k | gsomix, re | 22:56 |
shogun-buildbot | build #1193 of bsd1 - libshogun is complete: Failure [failed test_1] Build details are at http://www.shogun-toolbox.org/buildbot/builders/bsd1%20-%20libshogun/builds/1193 blamelist: Soeren Sonnenburg <sonne@debian.org> | 22:59 |
-!- travis-ci [~travis-ci@ec2-184-73-0-135.compute-1.amazonaws.com] has joined #shogun | 23:04 | |
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/8745367 | 23:04 |
-!- travis-ci [~travis-ci@ec2-184-73-0-135.compute-1.amazonaws.com] has left #shogun [] | 23:04 | |
gsomix | sonney2k, I'm close. | 23:07 |
shogun-buildbot | build #1194 of bsd1 - libshogun is complete: Failure [failed test_1] Build details are at http://www.shogun-toolbox.org/buildbot/builders/bsd1%20-%20libshogun/builds/1194 blamelist: Soeren Sonnenburg <sonne@debian.org> | 23:08 |
shogun-buildbot | build #1316 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/1316 blamelist: Soeren Sonnenburg <sonne@debian.org> | 23:09 |
-!- votjakovr [~votjakovr@host-46-241-3-209.bbcustomer.zsttk.net] has left #shogun ["Fallen asleep!"] | 23:16 | |
@sonney2k | gsomix, ok I am still wrestling with travis | 23:19 |
* sonney2k wins | 23:24 | |
shogun-notifier- | shogun: Soeren Sonnenburg :develop * e726a47 / src/interfaces/modular/modshogun_ignores.i: https://github.com/shogun-toolbox/shogun/commit/e726a470fe9a9592fc6a8d6f1a74934027efcb32 | 23:25 |
shogun-notifier- | shogun: blacklist also evaluate_variance | 23:25 |
shogun-notifier- | shogun: Soeren Sonnenburg :develop * bceddcf / applications/ocr/data/ocr.svm.gz: https://github.com/shogun-toolbox/shogun/commit/bceddcf2fa3173b3cb5a2b3a1724d165e39413cb | 23:25 |
shogun-notifier- | shogun: update ocr example for new serializtion | 23:25 |
shogun-buildbot | build #1317 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/1317 blamelist: Soeren Sonnenburg <sonne@debian.org> | 23:26 |
-!- travis-ci [~travis-ci@ec2-54-224-215-138.compute-1.amazonaws.com] has joined #shogun | 23:26 | |
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/8745766 | 23:26 |
-!- travis-ci [~travis-ci@ec2-54-224-215-138.compute-1.amazonaws.com] has left #shogun [] | 23:26 | |
shogun-buildbot | build #1195 of bsd1 - libshogun is complete: Failure [failed test_1] Build details are at http://www.shogun-toolbox.org/buildbot/builders/bsd1%20-%20libshogun/builds/1195 blamelist: Soeren Sonnenburg <sonne@debian.org> | 23:38 |
@sonney2k | wiking_, I need the address for the videofeed otherwise I cannot announce it | 23:43 |
shogun-buildbot | build #1196 of bsd1 - libshogun is complete: Failure [failed test_1] Build details are at http://www.shogun-toolbox.org/buildbot/builders/bsd1%20-%20libshogun/builds/1196 blamelist: Soeren Sonnenburg <sonne@debian.org> | 23:48 |
-!- travis-ci [~travis-ci@ec2-184-73-0-135.compute-1.amazonaws.com] has joined #shogun | 23:51 | |
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/8746955 | 23:51 |
-!- travis-ci [~travis-ci@ec2-184-73-0-135.compute-1.amazonaws.com] has left #shogun [] | 23:51 | |
--- Log closed Fri Jul 05 00:00:18 2013 |
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!