| --- Log opened Tue May 01 00:00:47 2018 | ||
| -!- HeikoS [~heiko@host86-128-122-53.range86-128.btcentralplus.com] has joined #shogun | 00:32 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 00:32 | |
| -!- HeikoS [~heiko@host86-128-122-53.range86-128.btcentralplus.com] has quit [Ping timeout: 248 seconds] | 00:44 | |
| -!- tctara_ [~quassel@irc.redcorelinux.org] has quit [Read error: Connection reset by peer] | 08:30 | |
| -!- tctara [~quassel@irc.redcorelinux.org] has joined #shogun | 08:30 | |
| -!- HeikoS [~heiko@host86-128-122-53.range86-128.btcentralplus.com] has joined #shogun | 10:12 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 10:12 | |
| -!- lambday [31cf37b6@gateway/web/freenode/ip.49.207.55.182] has joined #shogun | 10:42 | |
| -!- mode/#shogun [+o lambday] by ChanServ | 10:42 | |
| @HeikoS | lambday: jojo | 10:49 |
|---|---|---|
| @lambday | HeikoS: hey | 10:51 |
| @lambday | HeikoS: gonna try with native python one more time... if it doesn't work this time I'm gonna switch to docker | 10:51 |
| @HeikoS | ok! | 10:51 |
| @lambday | just upgraded my system | 10:51 |
| -!- lambday [31cf37b6@gateway/web/freenode/ip.49.207.55.182] has quit [] | 11:02 | |
| -!- lambday [31cf37b6@gateway/web/freenode/ip.49.207.55.182] has joined #shogun | 11:06 | |
| -!- mode/#shogun [+o lambday] by ChanServ | 11:06 | |
| @lambday | HeikoS: so, for starters, I was thinking I'm gonna drop all the convenient ctors in the testing framework... put a global factory method, say, mmd(...) | 11:16 |
| @lambday | next step can be to drop all specialized methods from the impl classes... and replace them with get/put ... | 11:17 |
| -!- HeikoS [~heiko@host86-128-122-53.range86-128.btcentralplus.com] has quit [Ping timeout: 260 seconds] | 12:00 | |
| -!- HeikoS [~heiko@host86-128-122-53.range86-128.btcentralplus.com] has joined #shogun | 12:03 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 12:04 | |
| -!- lambday [31cf37b6@gateway/web/freenode/ip.49.207.55.182] has quit [Ping timeout: 260 seconds] | 12:04 | |
| -!- lambday [31cf37b6@gateway/web/freenode/ip.49.207.55.182] has joined #shogun | 12:11 | |
| -!- mode/#shogun [+o lambday] by ChanServ | 12:12 | |
| @HeikoS | lambday: hi, sorry was out for a moment | 12:18 |
| @HeikoS | I say yes to droppeing the ctors | 12:18 |
| @HeikoS | factory should be hypothesis test I think | 12:18 |
| @HeikoS | that can be a base class next to CMachine | 12:18 |
| @HeikoS | so it would be | 12:18 |
| @HeikoS | mmd = hypothesis_test("QuadraticTimeMMD") | 12:19 |
| @HeikoS | lambday: btw | 12:19 |
| @HeikoS | you dont need to drop the ctors for now | 12:19 |
| @HeikoS | keep them | 12:19 |
| @HeikoS | just add the factory and change the examples | 12:19 |
| @HeikoS | lambday: minimal code edit changes | 12:19 |
| @HeikoS | makes things faster and we can do more important stuff (dropping can be done later) | 12:19 |
| @HeikoS | lisitsyn: any news on those lazy get calls? | 12:19 |
| @HeikoS | lambday: let me know if that makes sense | 12:21 |
| @HeikoS | lambday: btw | 12:25 |
| @HeikoS | you can also work on hedosimnbot if that helps | 12:25 |
| @HeikoS | we have et installed there, so might help a potentially unstable connection | 12:26 |
| @lambday | HeikoS: I already dropped the ctors... unit-tests and the meta examples work without them | 12:54 |
| @lambday | I mean, they compile.... | 12:54 |
| @lambday | running them now | 12:54 |
| @lambday | HeikoS: yeah hypothesis_test makes more sense than mmd.... | 12:54 |
| @HeikoS | lambday: you can keep on having them removed, was just sayinfg to save you some work | 12:55 |
| @HeikoS | lambday: yeah its a mindset shift: no more spedcialised classes in the API | 12:55 |
| @HeikoS | I think introducing a "test" class makes sense | 12:55 |
| @lambday | HeikoS: I was also thinking, maybe we can remove 'set_p', 'set_q' things and use put('features_p', features_p) instead... then we won't need different classes for tests invoking 1-2-3-more distributions | 12:55 |
| @HeikoS | though we can simplify this even further later | 12:56 |
| @HeikoS | lambday: yes absolutely | 12:56 |
| @HeikoS | these methods should go, no setters in the api | 12:56 |
| @HeikoS | again, no need to remove them | 12:56 |
| @HeikoS | just make the .put work | 12:56 |
| @HeikoS | the user will just do | 12:56 |
| @HeikoS | mmd.put("features_p" ,bla) | 12:56 |
| @lambday | yeah | 12:57 |
| @HeikoS | and if he tries to set soething that is not registered, he will get an error | 12:57 |
| @HeikoS | so this will cover all cases of 1,2,3 distribution tests | 12:57 |
| @lambday | yeah that's what I was thinking | 12:57 |
| @HeikoS | lambday: furthermore, I am currently working on a method "add" | 12:57 |
| @HeikoS | for repeated parameters that are stored in an array | 12:57 |
| @HeikoS | like the multiple kernels | 12:57 |
| @HeikoS | so it will be | 12:58 |
| @HeikoS | mm=test("multikernelMMDBLA") | 12:58 |
| @HeikoS | mm.add("kernels", kernel("GaussianKernel")) | 12:58 |
| @HeikoS | see the point? | 12:58 |
| @HeikoS | this will be useful for your stuff as well | 12:58 |
| @HeikoS | what you can do to prepare is to register the kernel array | 12:59 |
| @lambday | HeikoS: yeah this sounds pretty neat | 12:59 |
| @HeikoS | std::vector should be ok | 12:59 |
| @HeikoS | you can register that using "watch_param" | 12:59 |
| @HeikoS | at least I think so | 12:59 |
| @HeikoS | as it is not done yet (the add method), leave the setters in for now | 12:59 |
| @HeikoS | all thats needed is to make put work via registering all parameters | 13:00 |
| @HeikoS | and you can test using the meta examples | 13:00 |
| @HeikoS | very non-invasive changes | 13:00 |
| @lambday | HeikoS: let me first send the ctor patch... then in a separate patch I'm gonna push the setter/getter changes | 13:00 |
| @HeikoS | lambday: sure | 13:01 |
| @HeikoS | lambday: again, no need to touch the getter/setters | 13:01 |
| @HeikoS | lambday: all thats needed is to use put/get in the example | 13:01 |
| @lambday | ya ya.. | 13:01 |
| @HeikoS | and for that to work, you need to inherit from CSGObject and register | 13:01 |
| @HeikoS | lambday: sorry for being repetitive, it took me a while to get it myself :D | 13:01 |
| @lambday | HeikoS: haha I need some time as well.. dw :) | 13:03 |
| @lambday | brb | 13:03 |
| -!- HeikoS [~heiko@host86-128-122-53.range86-128.btcentralplus.com] has quit [Ping timeout: 256 seconds] | 13:08 | |
| -!- HeikoS [~heiko@host86-128-122-53.range86-128.btcentralplus.com] has joined #shogun | 13:09 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 13:09 | |
| @lambday | HeikoS: there? | 13:45 |
| @HeikoS | y | 13:45 |
| @lambday | HeikoS: for the two-distro tests that I have, I am not storing the features directory in a member attributes... I'm storing them directly inside the data manager | 13:46 |
| @HeikoS | yes I know | 13:46 |
| @lambday | HeikoS: I can make it lazy but it then would require some sort of init(...) call | 13:46 |
| @HeikoS | not sure what you mean by lazy | 13:47 |
| @HeikoS | you will need to register them somehow in the CSGObject API class | 13:47 |
| @HeikoS | watch_param | 13:47 |
| @lambday | HeikoS: I mean, I store them in member attrib... those would be registered.... then when the computation starts, I populate them in data_mgr and do the job.. | 13:48 |
| @HeikoS | ah | 13:48 |
| @HeikoS | yeah thats an idea | 13:48 |
| @lambday | data_mgr uses a vector to store those guys | 13:48 |
| @lambday | so, can't use the locations until I populate in there | 13:48 |
| @HeikoS | you can register things in vectors | 13:49 |
| @HeikoS | but then you cannot change the vector anymore | 13:49 |
| @HeikoS | that that doesnt make sense | 13:49 |
| @lambday | ya | 13:49 |
| @HeikoS | yeah so you could make those things members or the API class | 13:49 |
| @HeikoS | initialised and registered in constructor | 13:49 |
| @HeikoS | and then pass them on in the train methods | 13:49 |
| @HeikoS | or compute or how it is called | 13:50 |
| @HeikoS | lambday: think that works? | 13:50 |
| @lambday | HeikoS: thinking... there are multiple 'compute' methods.. compute_statistic, compute_variance, sample_null .... | 13:51 |
| @lambday | if I need to pass them on to one, I'd need to pass to every one of them | 13:52 |
| @HeikoS | yeah thats an issue of lazy | 13:52 |
| @HeikoS | I guess there could be a "prepare" method or something? | 13:52 |
| @lambday | HeikoS: yeah that's easiest but that would change the API | 13:53 |
| @HeikoS | it's the de-tached design of those classes that bites back now | 13:53 |
| @HeikoS | change the API? | 13:53 |
| @HeikoS | no I mean an internal method | 13:53 |
| @HeikoS | and all the API methods call this before they start | 13:53 |
| @lambday | HeikoS: yeah that's an idea... | 13:54 |
| @HeikoS | some machines do this as well | 13:54 |
| @HeikoS | see my big PR | 13:54 |
| @lambday | that's what I was also thinking... prepare(...) or init(...) method | 13:54 |
| @HeikoS | there was something on multiclass machines | 13:54 |
| @HeikoS | init_strategy | 13:54 |
| @HeikoS | can only be called once we have training features | 13:54 |
| @lambday | I see | 13:55 |
| @HeikoS | but those are only available within the training call | 13:55 |
| @HeikoS | so have to be lazy | 13:55 |
| @HeikoS | and every multiclass machine needs to call this in train_machine | 13:55 |
| @HeikoS | otherwise it segfaults | 13:55 |
| @HeikoS | init_strategy was called in ctor before | 13:55 |
| @HeikoS | (the ctor where features were available) | 13:55 |
| @HeikoS | so it is the same kind of problem | 13:55 |
| @HeikoS | lambday: i think it should work | 13:56 |
| @lambday | HeikoS: yeah that would work... another, a bit cleaner design IMO would be so introduce a TestConfiguration class and register that... every subclass of HypothesisTest would register its own config... the 'compute_stuff' methods would then pass this immutable instance to a compute module.. which would put it in whatever and it its job... and sends the result back | 13:59 |
| @HeikoS | lambday: I think that would be nicer, however | 13:59 |
| @HeikoS | this would not be shogun-like design | 13:59 |
| @HeikoS | we actually dont want to do this kind of stuff, as it creates all these bridging problems | 14:00 |
| @HeikoS | instead, we would prefer to operate within the framework itself | 14:00 |
| @HeikoS | using the same patterns everywhere | 14:00 |
| @lambday | HeikoS: yeah I see the point... would be better to understand and change | 14:00 |
| @lambday | let me go by the init thing then | 14:00 |
| @HeikoS | even though maybe the design patterns are not the nicest, things then are a bit more general, and we dont need to introduce all these classes/code for every part of the framework | 14:01 |
| @HeikoS | lambday: I think it is also possible to do with via an abstract base class and specialised methods | 14:01 |
| @HeikoS | i.e. you force that the init method is called | 14:01 |
| @HeikoS | but I think for this case here, we wanna minimise the number of code changes (it is just some rerfactoring) | 14:01 |
| @HeikoS | so simple works :) | 14:02 |
| @lambday | HeikoS: yeah let me think how to achieve this with minimal code changes | 14:02 |
| @HeikoS | imo, an init method that sets up the data structures of your testing code should do it | 14:03 |
| @HeikoS | another option might be | 14:03 |
| @HeikoS | to actually register the contents of those data-structures, and not allow the user to change them after | 14:03 |
| @HeikoS | but that might be more risky that initialisig them everytime | 14:03 |
| @HeikoS | and also I think the API methods are not called in high throughput loops anyways | 14:04 |
| @HeikoS | so re-initialising is ok | 14:04 |
| @HeikoS | just liek "train" | 14:04 |
| @lambday | HeikoS: yeah that can also be done | 14:06 |
| @HeikoS | lambday: are the vectors changed at any point? | 14:06 |
| @HeikoS | or did you just make it a vector to use the same manager for all cases? | 14:06 |
| @HeikoS | or is there a user interaction going on? idr this | 14:07 |
| @HeikoS | because if the number of features in the vector are fixed per test class, why not put the member pointers into the vector in the ctor? | 14:07 |
| @HeikoS | and then put just changes the poiner, which is stored in your data manager vector | 14:08 |
| @HeikoS | lambday: ? | 14:08 |
| -!- lambday [31cf37b6@gateway/web/freenode/ip.49.207.55.182] has quit [Ping timeout: 260 seconds] | 14:10 | |
| -!- witness [uid10044@gateway/web/irccloud.com/x-kcvicylabzhbudpt] has quit [] | 14:16 | |
| -!- lambday [31cf37b6@gateway/web/freenode/ip.49.207.55.182] has joined #shogun | 14:23 | |
| -!- mode/#shogun [+o lambday] by ChanServ | 14:23 | |
| @sukey | [https://github.com/shogun-toolbox/shogun] Pull Request https://github.com/shogun-toolbox/shogun/pull/4268 opened by lambday | 14:35 |
| @sukey | [https://github.com/shogun-toolbox/shogun] Pull Request https://github.com/shogun-toolbox/shogun/pull/4268 | 14:35 |
| wuwei | hi heiko, I'm refactoring ipython notebook, as said in email, features should be created via factory method, how about others like distance, machine, should I update them with factories? | 14:50 |
| @HeikoS | wuwei: let's start with features | 16:05 |
| @HeikoS | since it is a lot of changes otherwise | 16:05 |
| @HeikoS | where needed or easy, you can update the others as well | 16:05 |
| @HeikoS | but we are aiming for features first | 16:06 |
| @HeikoS | wuwei: thanks for getting into tit | 16:06 |
| wuwei | ok, great! | 16:06 |
| @sukey | [https://github.com/shogun-toolbox/shogun] Pull Request https://github.com/shogun-toolbox/shogun/pull/4268 merged by karlnapf | 16:15 |
| @sukey | [https://github.com/shogun-toolbox/shogun] New commit https://github.com/shogun-toolbox/shogun/commit/b85020ce3cf7f441e356227dc11c01042948d87c by karlnapf | 16:15 |
| @sukey | [https://github.com/shogun-toolbox/shogun] Pull Request https://github.com/shogun-toolbox/shogun/pull/4269 opened by vinx13 | 17:06 |
| wuwei | heiko: could you review this pr before I proceed furthur. the problem is, there are many irrevalent changes when contents are automically converted to the new notebook format, which can make it hard to review | 17:09 |
| -!- travis-ci [~travis-ci@ec2-54-242-251-1.compute-1.amazonaws.com] has joined #shogun | 17:15 | |
| travis-ci | it's Soumyajit De's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: https://travis-ci.org/shogun-toolbox/shogun/builds/373484332 | 17:15 |
| -!- travis-ci [~travis-ci@ec2-54-242-251-1.compute-1.amazonaws.com] has left #shogun [] | 17:15 | |
| -!- durovo1 [~durovo@37.8f.559e.ip4.static.sl-reverse.com] has quit [Remote host closed the connection] | 17:30 | |
| -!- durovo [~durovo@37.8f.559e.ip4.static.sl-reverse.com] has joined #shogun | 17:30 | |
| -!- travis-ci [~travis-ci@ec2-54-242-251-1.compute-1.amazonaws.com] has joined #shogun | 17:36 | |
| travis-ci | it's Soumyajit De's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: https://travis-ci.org/shogun-toolbox/shogun/builds/373484332 | 17:36 |
| -!- travis-ci [~travis-ci@ec2-54-242-251-1.compute-1.amazonaws.com] has left #shogun [] | 17:36 | |
| @sukey | [https://github.com/shogun-toolbox/shogun] Pull Request https://github.com/shogun-toolbox/shogun/pull/4270 opened by karlnapf | 18:29 |
| @sukey | [https://github.com/shogun-toolbox/shogun] Pull Request https://github.com/shogun-toolbox/shogun/pull/4270 | 18:29 |
| -!- travis-ci [~travis-ci@ec2-54-92-229-93.compute-1.amazonaws.com] has joined #shogun | 18:45 | |
| travis-ci | it's Soumyajit De's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: https://travis-ci.org/shogun-toolbox/shogun/builds/373484332 | 18:45 |
| -!- travis-ci [~travis-ci@ec2-54-92-229-93.compute-1.amazonaws.com] has left #shogun [] | 18:45 | |
| @sukey | [https://github.com/shogun-toolbox/shogun] Pull Request https://github.com/shogun-toolbox/shogun/pull/4270 synchronized by karlnapf | 18:56 |
| -!- lambday [31cf37b6@gateway/web/freenode/ip.49.207.55.182] has quit [Ping timeout: 260 seconds] | 20:15 | |
| -!- HeikoS [~heiko@host86-128-122-53.range86-128.btcentralplus.com] has quit [Ping timeout: 255 seconds] | 20:16 | |
| -!- HeikoS [~heiko@host86-128-122-53.range86-128.btcentralplus.com] has joined #shogun | 20:21 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 20:21 | |
| -!- travis-ci [~travis-ci@ec2-54-92-229-93.compute-1.amazonaws.com] has joined #shogun | 20:45 | |
| travis-ci | it's Shubham Shukla's turn to pay the next round of drinks for the massacre he caused in shubham808/shogun: https://travis-ci.org/shubham808/shogun/builds/373594694 | 20:45 |
| -!- travis-ci [~travis-ci@ec2-54-92-229-93.compute-1.amazonaws.com] has left #shogun [] | 20:45 | |
| @sukey | [https://github.com/shogun-toolbox/shogun] Pull Request https://github.com/shogun-toolbox/shogun/pull/4236 synchronized by shubham808 | 20:52 |
| -!- travis-ci [~travis-ci@ec2-54-157-240-91.compute-1.amazonaws.com] has joined #shogun | 22:12 | |
| travis-ci | it's Shubham Shukla's turn to pay the next round of drinks for the massacre he caused in shubham808/shogun: https://travis-ci.org/shubham808/shogun/builds/373599086 | 22:12 |
| -!- travis-ci [~travis-ci@ec2-54-157-240-91.compute-1.amazonaws.com] has left #shogun [] | 22:12 | |
| -!- travis-ci [~travis-ci@ec2-54-242-251-1.compute-1.amazonaws.com] has joined #shogun | 22:37 | |
| travis-ci | it's Shubham Shukla's turn to pay the next round of drinks for the massacre he caused in shubham808/shogun: https://travis-ci.org/shubham808/shogun/builds/373599086 | 22:37 |
| -!- travis-ci [~travis-ci@ec2-54-242-251-1.compute-1.amazonaws.com] has left #shogun [] | 22:37 | |
| --- Log closed Wed May 02 00:00:49 2018 | ||
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!