| --- Log opened Thu Mar 07 00:00:04 2013 | ||
| -!- n4nd0 [~nando@s83-179-44-135.cust.tele2.se] has quit [Quit: leaving] | 00:02 | |
| -!- FSCV_ [~FSCV@173.254.212.46] has quit [Quit: Leaving] | 01:03 | |
| -!- eduvfsilva [~eduvfsilv@189-25-47-127.user.veloxzone.com.br] has joined #shogun | 02:27 | |
| shogun-buildbot | build #314 of nightly_default is complete: Failure [failed test] Build details are at http://www.shogun-toolbox.org/buildbot/builders/nightly_default/builds/314 | 03:41 |
|---|---|---|
| -!- eduvfsilva [~eduvfsilv@189-25-47-127.user.veloxzone.com.br] has quit [] | 05:45 | |
| -!- sumit [ca4eaca2@gateway/web/freenode/ip.202.78.172.162] has joined #shogun | 06:58 | |
| -!- n4nd0 [~nando@n145-p185.kthopen.kth.se] has joined #shogun | 07:53 | |
| -!- zxtx [~zv@cpe-75-83-151-252.socal.res.rr.com] has joined #shogun | 08:04 | |
| -!- hoijui [~hoijui@dslb-092-078-043-220.pools.arcor-ip.net] has joined #shogun | 08:09 | |
| -!- sumit [ca4eaca2@gateway/web/freenode/ip.202.78.172.162] has quit [Ping timeout: 245 seconds] | 09:05 | |
| -!- n4nd0 [~nando@n145-p185.kthopen.kth.se] has quit [Ping timeout: 248 seconds] | 10:05 | |
| -!- n4nd0 [~nando@n145-p185.kthopen.kth.se] has joined #shogun | 10:31 | |
| -!- n4nd0 [~nando@n145-p185.kthopen.kth.se] has quit [Quit: leaving] | 11:27 | |
| -!- blackburn [~blackburn@85.114.170.181] has quit [Quit: Leaving.] | 11:29 | |
| -!- blackburn [~blackburn@85.114.170.181] has joined #shogun | 11:37 | |
| -!- n4nd0 [~nando@n145-p185.kthopen.kth.se] has joined #shogun | 11:54 | |
| n4nd0 | blackburn: indeed, from 0.98 to 0.958 seems a quite large | 12:20 |
| n4nd0 | I hope float precission is better than that :) | 12:20 |
| blackburn | n4nd0: heiko fixed something about custom kernel - I hope that | 12:20 |
| -!- n4nd0 [~nando@n145-p185.kthopen.kth.se] has quit [Quit: leaving] | 13:01 | |
| -!- hoijui [~hoijui@dslb-092-078-043-220.pools.arcor-ip.net] has quit [Read error: Operation timed out] | 13:39 | |
| wiking | booojaaaah | 13:50 |
| -!- n4nd0 [~nando@n145-p185.kthopen.kth.se] has joined #shogun | 13:55 | |
| blackburn | wiking: welcome back | 13:57 |
| wiking | shitfucky ;) <phdwritingsessionon> | 14:09 |
| wiking | and even my ssh is lagging | 14:24 |
| blackburn | wiking: so working on a thesis? | 14:25 |
| wiking | yeps | 14:25 |
| wiking | somethinglikethat | 14:25 |
| wiking | or at least tyring | 14:25 |
| wiking | *trying | 14:25 |
| blackburn | I see | 14:26 |
| n4nd0 | wiking: what's the name of your thesis? | 14:27 |
| n4nd0 | something latent :) ? | 14:27 |
| blackburn | hah I know a few latent gays (I suspect so) | 14:27 |
| blackburn | sorry couldn't resist :D | 14:27 |
| wiking | :) | 14:28 |
| n4nd0 | hehe | 14:28 |
| wiking | nice one | 14:28 |
| wiking | :) | 14:28 |
| blackburn | wiking: I remember you were curious about t-SNE | 14:35 |
| blackburn | wiking: I arranged with laurens to GPL his Barnes-Hut-SNE and will push it very soon | 14:36 |
| wiking | \o/ | 14:55 |
| wiking | woah cool | 14:55 |
| -!- FSCV [~FSCV@173.254.212.46] has joined #shogun | 15:09 | |
| -!- heiko [~heiko@nat-164-89.internal.eduroam.ucl.ac.uk] has joined #shogun | 15:25 | |
| -!- ashar799 [4e61ecae@gateway/web/freenode/ip.78.97.236.174] has joined #shogun | 15:34 | |
| -!- n4nd0 [~nando@n145-p185.kthopen.kth.se] has quit [Quit: leaving] | 15:38 | |
| -!- hoijui [~hoijui@141.23.80.177] has joined #shogun | 15:43 | |
| ashar799 | Hi I was wondering if there are any plans to incorporate Gaussian Process Latent Variable Model (by Neil Lawrence) and Gaussian Process Dynamical Variable Model (Wang) for Dimensionality reduction | 16:49 |
| ashar799 | I am doing my MS thesis on implementing these two models for different data sets | 16:50 |
| ashar799 | and have seen that having more Dimensionality reduction techniques is one of the proposals for GSoc 2013 | 16:52 |
| blackburn | ashar799: we've got no concrete plans yet but we will consider that too! | 17:16 |
| -!- hoijui [~hoijui@141.23.80.177] has quit [Ping timeout: 252 seconds] | 17:23 | |
| @sonney2k | blackburn, wiking, heiko - can any of you reproduce the custom kernel issue? | 17:45 |
| @sonney2k | (because I dont'...) | 17:45 |
| blackburn | sonney2k: I can't | 17:45 |
| heiko | sonney2k: nope | 17:45 |
| @sonney2k | must be some very old version of shogun | 17:45 |
| @sonney2k | or even numpy.... | 17:45 |
| heiko | sonney2k: I suspect she just downloaded and compiled shogun but has an old version installed from the repository or so | 17:46 |
| @sonney2k | heiko, blackburn because it seems to me that the matrix' values are somehow shuffled in memory | 17:46 |
| @sonney2k | some kind of fortran/c order issue | 17:46 |
| heiko | yeah, lets wait for her version :) | 17:47 |
| @sonney2k | so the 0.958 (that appears in the orginal numpy matrix) is at the wrong position | 17:47 |
| blackburn | popular issue :) | 17:47 |
| @sonney2k | we had such bug but years ago... | 17:47 |
| @sonney2k | not even sure blackburn was still around :D | 17:47 |
| blackburn | haha | 17:48 |
| heiko | hehe :) | 17:48 |
| blackburn | sonney2k: I have two years anniversary soon | 17:48 |
| @sonney2k | so before the dawn of the ages | 17:48 |
| @sonney2k | I can hardly remember the time before you were part of the team | 17:48 |
| @sonney2k | actually same holds for heiko... | 17:48 |
| heiko | yeah, it has been a while :) | 17:49 |
| blackburn | sonney2k: 2011-03-29 is the day I joined #shogun on a sleepless night to show my broken english | 17:49 |
| blackburn | :D | 17:49 |
| heiko | sonney2k: blackburn btw I am currently writing my gsoc project description | 17:52 |
| blackburn | nice, I should do the same | 17:53 |
| blackburn | and proposal | 17:53 |
| heiko | proposal? | 17:53 |
| blackburn | heiko: yes we should make a gsoc proposal | 17:55 |
| heiko | blackburn: I see :) | 17:55 |
| heiko | let me know where I can help | 17:55 |
| blackburn | heiko: I'll create google doc for that I think | 17:55 |
| heiko | good idea | 17:55 |
| heiko | blackburn: for the project, I think I will create a pdf since I need some math, and then post the abstract on the page along with the pdf | 17:56 |
| blackburn | heiko: maybe mathjax? | 17:56 |
| blackburn | http://lisitsyn.github.com/tapkee/methods/lle.html like that | 17:56 |
| heiko | blackburn: agreed! | 17:56 |
| blackburn | sonney2k: heiko: I received 'yes' from laurens - this means we can add t-SNE | 17:58 |
| blackburn | the question is - should I put it to latest shogun before release? | 17:58 |
| heiko | blackburn: what? :) | 17:58 |
| blackburn | heiko: I was convincing him to GPL his code | 17:58 |
| heiko | blackburn: I would not add anything right now, better fix bugs :) | 17:58 |
| heiko | blackburn: Ah nice work! | 17:58 |
| blackburn | heiko: yeah I would do the same | 17:58 |
| blackburn | sonney2k: heiko: question two | 18:00 |
| blackburn | I got jedi macros skills | 18:00 |
| heiko | ? | 18:00 |
| heiko | blackburn: thats good :) I hate macros | 18:00 |
| blackburn | I think I can replace fields of our classes | 18:00 |
| blackburn | and its getters/setters/sgadds | 18:00 |
| blackburn | with just one macro may be | 18:00 |
| blackburn | not for that version of course | 18:00 |
| heiko | blackburn: example? | 18:02 |
| blackburn | heiko: field(float64_t,width) | 18:03 |
| heiko | blackburn: the they got registered automatically? | 18:04 |
| blackburn | yes and getters/setters are generated | 18:04 |
| heiko | sounds nice | 18:04 |
| blackburn | heiko: or even | 18:04 |
| heiko | but, also a lot of work | 18:04 |
| blackburn | field(float64_t,width,positive) | 18:04 |
| heiko | positive? | 18:04 |
| blackburn | yeah, means it will be checked | 18:05 |
| blackburn | to be positive | 18:05 |
| blackburn | heiko: take a look - I did somewhat simplified version of that in tapkee: https://github.com/lisitsyn/tapkee/blob/master/tapkee/tapkee_methods.hpp#L491 | 18:05 |
| heiko | that is cool stuff | 18:07 |
| blackburn | heiko: I have >20 methods with 2-7 parameters each so macroses appeared as the only way to handle this without megaLoC | 18:07 |
| heiko | blackburn: but do you think its a good idea to do this for shogun? | 18:07 |
| blackburn | heiko: I don't know - that's why I am asking | 18:07 |
| heiko | blackburn: I would be afraid that everything will be broken for quite some time | 18:08 |
| blackburn | heiko: yes that's '-' | 18:08 |
| heiko | and that it is infinite work to apply this to all existing classes | 18:09 |
| heiko | and that many bugs slip through our fingers | 18:09 |
| heiko | since these things are usually a bit unpredictable | 18:09 |
| heiko | also, doesnt it make debugging a bit complicated since you are not reading the code anymore? | 18:09 |
| heiko | especially when mixed in | 18:09 |
| heiko | blackburn: you will like this: | 18:12 |
| heiko | http://googleblog.blogspot.co.uk/2012/06/using-large-scale-brain-simulations-for.html | 18:13 |
| blackburn | heiko: getters/setters is a pure evil | 18:16 |
| -!- ashar799 [4e61ecae@gateway/web/freenode/ip.78.97.236.174] has quit [Quit: Page closed] | 18:24 | |
| blackburn | heiko: they ~never have bugs | 18:26 |
| blackburn | heiko: and if they have - automagic resolve that | 18:26 |
| heiko | blackburn: I like the part about reference counting for SGOs :) | 18:28 |
| heiko | but I am a bit afraid of this, the code you see will not be the code that the compiler sees anymore | 18:29 |
| blackburn | heiko: that's good I can't see what compiler sees | 18:29 |
| blackburn | I'd really like to not see new/delete and indexes | 18:30 |
| blackburn | it is a great misconception such level means performance | 18:31 |
| blackburn | I hope you don't think so :) | 18:31 |
| heiko | blackburn: agreed, I hope you know what I meant | 18:37 |
| heiko | blackburn: I like the idea | 18:37 |
| heiko | blackburn: so you think we should move on to a modern language for shogun? :D | 18:37 |
| blackburn | heiko: it is kind of exceptional for me as I never debugged getters and setters | 18:38 |
| blackburn | but they take so much space | 18:38 |
| heiko | blackburn: true, but sometimes you dont want to have them | 18:38 |
| heiko | eclipse can do them for you btw | 18:38 |
| blackburn | heiko: no, it is different | 18:38 |
| blackburn | generating and code folding is a halfway | 18:39 |
| blackburn | heiko: well modern language is C++ | 18:40 |
| blackburn | I see no other alternative :) | 18:41 |
| blackburn | even if I had resources to translate all the code - no idea which language could it be | 18:41 |
| heiko | same | 18:41 |
| heiko | probably google-go :D | 18:41 |
| heiko | or my favourite: brainfuck | 18:42 |
| blackburn | heiko: shakespeare | 18:42 |
| heiko | haha :) | 18:43 |
| blackburn | heiko: last year we were thinking about chef interface | 18:44 |
| heiko | chef? | 18:44 |
| blackburn | heiko: yeah there is a language | 18:44 |
| heiko | i see | 18:44 |
| heiko | btw interfaces: | 18:44 |
| heiko | blackburn: matlab is the most important one and it is static only | 18:45 |
| heiko | that is a shame | 18:45 |
| blackburn | http://www.dangermouse.net/esoteric/chef.html heiko | 18:45 |
| heiko | so much potential lost | 18:45 |
| heiko | We should have a gsoc project to implement matlab for swig | 18:45 |
| blackburn | heiko: I have nothing to say about that :) we should push it in swig | 18:45 |
| heiko | (and shogun afterwards) | 18:45 |
| heiko | same with R | 18:45 |
| blackburn | but I guess matlab is quite shitty in that sense | 18:45 |
| heiko | Matlab and R are the main languages used by the people who could use shogun | 18:46 |
| heiko | blackburn: really? | 18:46 |
| heiko | I think it should be ok, the new matlab has object orientation and everything | 18:46 |
| blackburn | heiko: I guess SWIG people just can't get some required info | 18:46 |
| blackburn | proprietary stuff | 18:46 |
| heiko | blackburn: reading a bit through the mailing lists, I understood that just nobody is doing it | 18:46 |
| blackburn | really? I see | 18:47 |
| heiko | there even was a student who did his project on this | 18:47 |
| heiko | but sonney2k should know more about this | 18:47 |
| blackburn | heiko: there is a SwigJS, huh! | 18:49 |
| blackburn | heiko: I understand matlab is important but I do not know how to proceed | 18:56 |
| heiko | blackburn: same, I hoped maybe sonney2k has an idea | 18:56 |
| heiko | there also was this MSC project | 18:56 |
| heiko | let me find the link | 18:56 |
| heiko | initial code | 18:57 |
| heiko | https://github.com/twiho/Matlab-in-SWIG | 18:57 |
| heiko | thesis 1 | 18:57 |
| heiko | http://is.muni.cz/th/256412/fi_b/thesis.pdf | 18:57 |
| heiko | thesis 2 | 18:57 |
| heiko | http://is.muni.cz/th/256594/fi_m/thesis.pdf | 18:57 |
| heiko | blackburn: that is a lot of stuff to start with :) | 18:57 |
| blackburn | heiko: it doesn't sound like a something easy | 18:58 |
| blackburn | we should discuss it with swig guys | 18:58 |
| heiko | blackburn: indeed | 19:05 |
| -!- hoijui [~hoijui@dslb-092-078-043-220.pools.arcor-ip.net] has joined #shogun | 19:05 | |
| heiko | blackburn: would be so good to have | 19:05 |
| heiko | blackburn: you once mentioned something about openmp? | 19:06 |
| blackburn | heiko: well, yes | 19:06 |
| heiko | or was that openmpi? | 19:07 |
| blackburn | heiko: no, openmpi is not really interesting for me | 19:07 |
| blackburn | it is just implementation :) | 19:07 |
| blackburn | of mpi standard | 19:07 |
| heiko | my question is: | 19:07 |
| heiko | if I have some parts of my algorithm that should be parallelised | 19:07 |
| heiko | and the number of parallel parts is large | 19:07 |
| heiko | is there anything I can do in shogun=? | 19:08 |
| blackburn | heiko: pthreads is our traditional way | 19:08 |
| heiko | but pthreads is restricted to one computer | 19:08 |
| heiko | blackburn: do you have any idea how hard it would be to add the possibility that these "threads" are distributed within a cluster of computers? | 19:09 |
| blackburn | heiko: MPI is the only way to do that | 19:10 |
| heiko | blackburn: have you used that? | 19:10 |
| blackburn | yes | 19:10 |
| heiko | blackburn: tell me your feelings about it | 19:10 |
| blackburn | heiko: w/o some additional routines to send/recv messages I think the code would look like a mess | 19:11 |
| heiko | ok | 19:11 |
| blackburn | heiko: the thing I am mostly worried is that I am totally unsure it is possible to use SWIG+MPI | 19:12 |
| heiko | so thats not a good idea | 19:12 |
| heiko | blackburn: its just: parallelisation is fine. But if one wants to do somethign really large scale, one needs more than one computer | 19:12 |
| blackburn | heiko: actually we should transform to client/server | 19:12 |
| heiko | blackburn: maybe shogun is not the right boat for this | 19:13 |
| blackburn | I think it would be awesome | 19:13 |
| heiko | also most methods inside shogun dont really scale | 19:13 |
| blackburn | heiko: bindings could stay but creating SVM would be to send a packet over a network | 19:13 |
| heiko | blackburn: I see | 19:14 |
| blackburn | and then master shogun could create workers on cluster machines | 19:14 |
| heiko | so you want to create kind of stub objects | 19:14 |
| blackburn | yes | 19:14 |
| blackburn | I feel 'eureka' in my head now | 19:14 |
| blackburn | I didn't think about that in that mean before | 19:14 |
| heiko | which methods could use this? | 19:14 |
| heiko | svm certainly not :) | 19:14 |
| blackburn | heiko: well it doesn't mean we should always work on cluster | 19:15 |
| blackburn | if method supports that thing - run it on cluster | 19:15 |
| heiko | yeah that would be sexy | 19:15 |
| blackburn | heiko: even shogun name makes a lot of sense now for me :D | 19:15 |
| heiko | so in the code, you just allocate workers | 19:15 |
| blackburn | as if shogun takes the rule of workers | 19:15 |
| heiko | and they are either distributed automatically, or executed locally | 19:16 |
| blackburn | yes | 19:16 |
| blackburn | shogun server + shogun bindings | 19:16 |
| heiko | blackburn: that should not be too hard to implement in fact | 19:16 |
| blackburn | they are loose coupled over a network | 19:16 |
| blackburn | uh | 19:17 |
| blackburn | heiko: isn't that a great idea? I get driven by it | 19:17 |
| heiko | blackburn: yeah, I just wonder whether there is no framework for this, since it has certainly been done before | 19:17 |
| blackburn | heiko: framework for what exactly? | 19:17 |
| heiko | this structure | 19:18 |
| heiko | of allocating workers | 19:18 |
| heiko | for your tasks | 19:18 |
| blackburn | heiko: MPI/MapReduce :) | 19:18 |
| blackburn | a lot of | 19:18 |
| blackburn | I believe it should be generalized | 19:18 |
| heiko | yes, this is what I mean, why not use MPI? | 19:19 |
| blackburn | heiko: I didn't say we shouldn't use MPI | 19:19 |
| blackburn | shogun client (bindings) <-> shogun server <-> MPI backend | 19:19 |
| blackburn | OR | 19:20 |
| blackburn | shogun client (bindings) <-> shogun server <-> map reduce backend | 19:20 |
| blackburn | anything you like :D | 19:20 |
| blackburn | hmm should I left my job and do that ? :D | 19:20 |
| heiko | blackburn: haha :) | 19:20 |
| heiko | blackburn: so say we had that working. Which methods would be able to properly use it? | 19:20 |
| blackburn | heiko: I do not know about machine learning | 19:21 |
| heiko | blackburn: my linear time MMD would, it is X times faster for X additional workers | 19:21 |
| heiko | but apart from that? | 19:21 |
| blackburn | but I realize it could be a great framework | 19:21 |
| heiko | if I implemented statistics stuff then this would also be great | 19:21 |
| blackburn | heiko: even having everything in one worker *with capabilities* of doing that cluster later is just great | 19:22 |
| blackburn | heiko: algorithms will come I think | 19:22 |
| heiko | blackburn: thats true, but also very easy to achieve without the need to mess around with client/server/mpi stuff | 19:22 |
| blackburn | heiko: with your own boilerplate code? | 19:23 |
| blackburn | it is not a solution | 19:23 |
| heiko | I run stuff on clusters all the time, thats very easy if you just use one process | 19:23 |
| heiko | just upload program, write a 5 line allocation script and submit | 19:23 |
| heiko | I agree it would be easier with a framework, but not that much that its worth to put all the effort into that | 19:24 |
| blackburn | heiko: ha! | 19:24 |
| heiko | But I really like the idea anyway | 19:24 |
| blackburn | it is worth as some things are impossibru | 19:24 |
| heiko | since you are right: algorithms can come then once this exists | 19:24 |
| blackburn | you can't make MMD faster now, right? | 19:24 |
| heiko | what do you mean? | 19:24 |
| blackburn | heiko: with cluster | 19:25 |
| heiko | with the shogun implementation, no | 19:25 |
| blackburn | you'd be able to do that with proper framework | 19:25 |
| heiko | yes | 19:25 |
| heiko | thats why I asked, which methods would benefit | 19:25 |
| heiko | since MMD is not so important for practical problems :D | 19:25 |
| blackburn | heiko: main thing - you can write your script on your laptop but run somewhere else | 19:25 |
| heiko | blackburn: agreed | 19:26 |
| heiko | so how would this work | 19:26 |
| blackburn | heiko: just stubs | 19:26 |
| heiko | I have some interface class to the server | 19:26 |
| heiko | and I can submit workers | 19:26 |
| heiko | which have an interface to start/stop/result/bla | 19:26 |
| blackburn | you don't care about workers | 19:26 |
| blackburn | you mean internally? | 19:27 |
| heiko | yes | 19:27 |
| heiko | from implementation side of view | 19:27 |
| blackburn | yeah something like that | 19:27 |
| heiko | and with that I can implement my new SVM | 19:27 |
| heiko | for example | 19:27 |
| heiko | lets say multiclass svm | 19:27 |
| heiko | with one against all | 19:27 |
| blackburn | you define how workers should act | 19:27 |
| blackburn | and how data should be distributed | 19:27 |
| heiko | so I package all the different problems into one worker and submit | 19:28 |
| heiko | wait | 19:28 |
| heiko | and return locally | 19:28 |
| heiko | and the server distributs them on any kind of machine | 19:28 |
| blackburn | why one worker? | 19:28 |
| heiko | either with shared memory or completely separate | 19:29 |
| blackburn | yeah | 19:29 |
| heiko | no each problem into one worker | 19:29 |
| heiko | each classification task of the many | 19:29 |
| blackburn | heiko: if we go crazy it could be even heterogeneous in means of technology | 19:29 |
| @sonney2k | heiko, blackburn about interfaces & swig... | 19:29 |
| blackburn | 5 MPI workers and some MapReduce farm and a GPU here | 19:29 |
| heiko | blackburn: that would be certainly crazy :D | 19:30 |
| blackburn | heiko: it sounds like a crazy dream but | 19:30 |
| @sonney2k | the issue I am having with swig & R is that the refcounting doesn't work | 19:30 |
| @sonney2k | which means one gets crashes or memory leaks | 19:30 |
| blackburn | heiko: imagine speedups you can get | 19:30 |
| blackburn | sonney2k: yeah I know about R | 19:30 |
| heiko | sonney2k: I see, what do the swig people say to that? | 19:30 |
| blackburn | sonney2k: the main concern is matlab | 19:30 |
| heiko | blackburn, so this would be like matlab's parfor, even cooler would be if the workers could communicate, but maybe this is a bit too much for now. even the independent jobs on a cluster would help massively | 19:31 |
| blackburn | heiko: no they *should* be able to communicate from the very beginning | 19:31 |
| @sonney2k | heiko, I reported that 2(3?) years ago but this one R maintainer did not really care. we would need to craft a minimal example showing the problem | 19:31 |
| @sonney2k | blackburn, mine is not matlab is *crap* | 19:32 |
| @sonney2k | I can easily live w/o matlab | 19:32 |
| @sonney2k | use octave | 19:32 |
| @sonney2k | same syntax same everything | 19:32 |
| @sonney2k | and blackburn what you are describing is e.g. http://graphlab.org/ | 19:32 |
| heiko | sonney2k: I agree, but we would reach a much bigger audience with a modular matlab binding | 19:33 |
| blackburn | sonney2k: haha | 19:34 |
| blackburn | sonney2k: invented a wheel again | 19:34 |
| @sonney2k | heiko, I don't see a problem doing it (no more than doing that for octave) but it needs someone with deep swig skills. if you look at the mailinglist archive of swig you would see that there was a guy Xavier sth (who wrote the octave bindings) with whom I tried to start this maybe 4-5 years back | 19:35 |
| @sonney2k | but then he left (also no longer maintaining the octave part) | 19:35 |
| heiko | sonney2k: I see | 19:35 |
| blackburn | sonney2k: well graphlab with language bindings :D | 19:36 |
| @sonney2k | heiko, I understand that some researchers still use matlab but that is not really my focus any longer at least | 19:36 |
| @sonney2k | haven't been using matlab for years and I am much happier with python ... | 19:37 |
| @sonney2k | it is fast has tons of bindings and free software | 19:37 |
| blackburn | sonney2k: researchers are lame with real programming languages for some reason | 19:38 |
| heiko | sonney2k: I like python too, but I cannot send it to people. | 19:38 |
| heiko | sonney2k: even worse, the number of people who are using mac grows like crazy here | 19:38 |
| blackburn | heiko: why? mac is ok for me | 19:39 |
| blackburn | well I never used it :D | 19:39 |
| @sonney2k | heiko, but python and osx go well together | 19:39 |
| heiko | sonney2k: blackburn: about that parallel thing. graphlab has its focus a bit different. I think having some kind of independent parallel engine would be really helpful | 19:39 |
| blackburn | sonney2k: idea is: objects in our bindings become stubs to represent objects in the serverspace | 19:40 |
| heiko | sonney2k: I really dont want to get into this python-matlab or X-Y discussion, I just think it would be great to properly support it. But it seems tricky | 19:41 |
| blackburn | server could run it as is or with some other backend | 19:41 |
| @sonney2k | blackburn, the issue with going massively parallel is that I don't have access to such cluster park | 19:41 |
| blackburn | sonney2k: I'd like to keep this idea in mind and implement and prototype | 19:41 |
| blackburn | and then see if it is nice | 19:41 |
| heiko | blackburn: maybe we could have a separate branch or so | 19:42 |
| blackburn | no | 19:42 |
| blackburn | well client part yes | 19:42 |
| blackburn | :) | 19:42 |
| blackburn | but server-side should be from the blank I am afraid | 19:42 |
| heiko | so? | 19:43 |
| @sonney2k | blackburn, well I am stuck on many core machines | 19:43 |
| blackburn | okay my idea - I will try to implement the whole stack | 19:43 |
| blackburn | with one distributable algorithm | 19:43 |
| blackburn | but it would take months I think | 19:43 |
| blackburn | sonney2k: we don't use either multicore or cluster machines | 19:44 |
| heiko | blackburn, I dont know whether this should be so massive due to the lack of algorithms that exploit this | 19:44 |
| heiko | I think if we had something that could handle independent jobs, this would help a lot | 19:44 |
| blackburn | heiko: jobs should not really be independent | 19:44 |
| blackburn | they should be independent as possible | 19:45 |
| @sonney2k | heiko, yeah sure I understand. I don't care about matlab though and it is >5 years since I've seen a really talented guy with whom one could have done this within 1-2 months | 19:45 |
| @sonney2k | and I don't have the time nor will to do it | 19:45 |
| @sonney2k | if at some point swig perfectly supports R / matlab we can easily switch to using it | 19:46 |
| heiko | sonney2k: do you know the swig people? | 19:46 |
| heiko | well? | 19:46 |
| @sonney2k | the only question that remains is what do we do with all the static interfaces? | 19:46 |
| heiko | maybe we could push them to do something in gsoc | 19:46 |
| @sonney2k | heiko, not well enough | 19:46 |
| @sonney2k | I met some of them at gsoc mentor summit | 19:46 |
| heiko | what are their current goals? | 19:47 |
| @sonney2k | heiko, no idea | 19:47 |
| @sonney2k | heiko, they just switched over to using github | 19:47 |
| blackburn | oh finally :D | 19:47 |
| heiko | sonney2k: I saw that :) | 19:48 |
| @sonney2k | https://github.com/swig | 19:48 |
| @sonney2k | (and git) | 19:48 |
| blackburn | I see no reason to use anything else | 19:48 |
| @sonney2k | they were on svn for years | 19:48 |
| heiko | gsoc 2012 had a new module for java script | 19:49 |
| @sonney2k | so heiko blackburn - what do we do with the static interfaces? | 19:49 |
| blackburn | https://dl.dropbox.com/u/10139213/shogun/tsne.png t-sne unrolls swissroll in a strange way :D | 19:49 |
| @sonney2k | these are becoming more and more obsolete... | 19:49 |
| heiko | sonney2k: I dont know, I never added something until shortly. Wanted to add some MMD stuff and found it rather painful | 19:50 |
| blackburn | sonney2k: drop :D | 19:50 |
| heiko | l | 19:50 |
| @sonney2k | and the danger is that people think this is shogun | 19:50 |
| @sonney2k | I mean all shogun can do | 19:50 |
| blackburn | haha yeah | 19:50 |
| @sonney2k | blackburn, yeah I would love to drop them | 19:50 |
| blackburn | is sg('set_shit') | 19:50 |
| @sonney2k | or at least hide them | 19:50 |
| heiko | sonney2k: hide | 19:50 |
| heiko | many people are using shogun as an libsvm interface | 19:50 |
| heiko | from matlab/R | 19:50 |
| @sonney2k | so there will be no (documented) configure option | 19:50 |
| blackburn | sonney2k: could we separate them to another project? | 19:50 |
| @sonney2k | blackburn, yes sure | 19:50 |
| blackburn | then lets do it this way | 19:51 |
| @sonney2k | heiko, but libsvm has a matlab interface too | 19:51 |
| blackburn | sonney2k: 'sorry we can't support it, it is an outdated project' | 19:51 |
| blackburn | haha shogun as a libsvm interface, really? | 19:51 |
| heiko | sonney2k: I know, but there are not all those kernels right? | 19:51 |
| blackburn | hehe! | 19:52 |
| blackburn | heiko: if they are still willing to use it this way we just tell them to install that different thing | 19:52 |
| heiko | blackburn: sonney2k agreed! | 19:53 |
| heiko | sonney2k: blackburn, btw I will probably soon implement a little module into graphlab, and I am thinking of linking against shogun for kernel/feature implementations | 19:53 |
| @sonney2k | heiko, why not | 19:54 |
| @sonney2k | heiko, blackburn - we should release shogun 2.1 | 19:54 |
| blackburn | hah sure | 19:54 |
| @sonney2k | too bad wiking didn't push it :( | 19:55 |
| heiko | sonney2k: have you seen this mkl bug? | 19:55 |
| @sonney2k | heiko, ? | 19:56 |
| heiko | I updated the issue | 19:56 |
| heiko | added an example | 19:56 |
| heiko | to reproduce | 19:56 |
| heiko | sonney2k: blackburn what is missing for 2.1? | 19:56 |
| heiko | apart from removing warnings? | 19:56 |
| blackburn | heiko: I am working on tapkee still.. no idea where to stop | 19:57 |
| heiko | blackburn: just stop adding new things :) | 19:57 |
| blackburn | I can't | 19:57 |
| blackburn | heiko: chris added 'including more recent' algorithms to the paper | 19:57 |
| blackburn | and I had to add a new algorithm because of that | 19:57 |
| blackburn | :D | 19:57 |
| heiko | blackburn: but that does not have to be in shogun2.1 right? | 19:58 |
| blackburn | heiko: yes and now I am in trouble | 19:58 |
| heiko | sonney2k: blackburn I got my MMD stuff finally ready, also tutorial updated, new tests/examples, and I commented on all the bugs and solved some, so from my side, we can go for it | 19:59 |
| @sonney2k | blackburn, heiko so waht is missing for shogun 2.1? | 19:59 |
| @sonney2k | I am under the impression we are in good shape for a release... | 19:59 |
| blackburn | hahah guys have you seen that? http://www.youtube.com/watch?feature=player_detailpage&v=CL3jvaq-VO4 | 20:00 |
| heiko | sonney2k: I agree | 20:00 |
| heiko | blackburn: no | 20:00 |
| heiko | not yet :) | 20:00 |
| heiko | sonney2k: have you heard something from the guy who impolemented the streaming basics? | 20:00 |
| blackburn | it is not required to watch all 15 mins but the more you listen to it the more normal it becomes | 20:01 |
| @sonney2k | blackburn, terminate called after throwing an instance of 'tapkee::eigendecomposition_error' | 20:01 |
| @sonney2k | what(): eigendecomposition failed | 20:01 |
| blackburn | sonney2k: cool! where? | 20:01 |
| @sonney2k | we have some failing examples blocking the release... | 20:01 |
| @sonney2k | http://shogun-toolbox.org/buildbot/builders/nightly_default/builds/314/steps/test/logs/stdio | 20:01 |
| wiking | sonney2k: i was just about to tell that maybe it'd be a good idea to switch on the bsd bot to clang instead of gcc | 20:01 |
| heiko | wiking, hi ! | 20:02 |
| blackburn | sonney2k: how did that appear after perceptron? | 20:02 |
| heiko | wiking, could you change the unit-tests to all be compiled/executed seperately? this would make things much easier | 20:02 |
| wiking | heiko: whatyamean? | 20:02 |
| wiking | heiko: aaaah | 20:03 |
| blackburn | sonney2k: I don't mind to fix it but where it is.. | 20:03 |
| @sonney2k | heiko, btw I wanted to comment on how examples are written in shogun and how they are documented | 20:03 |
| heiko | wiking, so currently if you run make unit-tests | 20:03 |
| wiking | heiko: why's that good? | 20:03 |
| heiko | verything runs at once | 20:03 |
| heiko | sonney2k: yes? | 20:03 |
| @sonney2k | heiko, you write your example in the undocumented/<lang>/ folder | 20:03 |
| wiking | heiko: yeah that's the purpose of unit test | 20:03 |
| wiking | heiko: i mean now i get waht you want | 20:03 |
| wiking | heiko: each unit test is a separate executable | 20:03 |
| heiko | wiking yes | 20:03 |
| wiking | it's doable imho | 20:03 |
| wiking | but still i dont see why's that good | 20:04 |
| heiko | sonney2k: so since the unit-tests finally arrived the examples (at least mine) will change. less testing things, more illustration | 20:04 |
| @sonney2k | heiko, then you write the description of the example separetely in examples/descriptions | 20:04 |
| heiko | wiking, if I add a new test and it fails I cannot run it isolated | 20:04 |
| heiko | sonney2k: under the same name? | 20:04 |
| @sonney2k | it is then prepended to each example of the same name for each $LANG | 20:04 |
| wiking | heiko: what if i make you selectable? | 20:04 |
| wiking | heiko: so there's still only one executable | 20:04 |
| wiking | heiko: but you can specify which test u wanna ran on command like | 20:05 |
| wiking | like | 20:05 |
| wiking | make unit-tests SGVector | 20:05 |
| wiking | or something like that? | 20:05 |
| heiko | sonney2k: I see | 20:05 |
| heiko | wiking, yes that would be good | 20:05 |
| wiking | and make unit-test would be doing the whole test by default | 20:05 |
| heiko | wiking, also compile shogun with --enable-trace-mallocs and run the tests | 20:05 |
| wiking | heiko: mmmm | 20:05 |
| heiko | wiking: this will show loads of loads of memeory leaks | 20:05 |
| wiking | where? | 20:06 |
| heiko | wiking: in configure | 20:06 |
| @sonney2k | heiko, so that is how it has been for a few years - now there is one exception: the examples in $lang/graphical | 20:06 |
| wiking | or you mean it would be good to have tests runnning --enable-trace-mallocs ? | 20:06 |
| heiko | sonney2k: ok, thats good to know | 20:06 |
| @sonney2k | these are not documented | 20:06 |
| @sonney2k | heiko, examples should be written as functions and called | 20:07 |
| wiking | heiko: bcoz the thing is the unit test flags really depends on ./configure flags... and that is pretty much up to the user... | 20:07 |
| heiko | wiking: no, I just use trace-mallocs by default, and it creates this annoying output at the end | 20:07 |
| wiking | heiko: ok i'll check | 20:07 |
| @sonney2k | heiko, this way we get integration tests for free! | 20:07 |
| heiko | sonney2k: ok! I changed one of mine recently to that | 20:07 |
| heiko | sonney2k: btw the graphical examples are a problem: the get outdated quite quickly | 20:07 |
| heiko | since not detected by make tests | 20:07 |
| heiko | but we cannot run them since they dont terminate alone | 20:08 |
| heiko | any ideas for that? | 20:08 |
| @sonney2k | heiko, unfortunately no one is taking care of examples/integration tests | 20:08 |
| heiko | sonney2k: these big tests? | 20:08 |
| @sonney2k | heiko, yes - very useful to know that the svm actually still produces the same result with this particular kernel and data :) | 20:10 |
| blackburn | sonney2k: I will test it w/o arpack now | 20:11 |
| heiko | sonney2k: indeed! | 20:11 |
| @sonney2k | heiko, and it is testing all the serialization stuff too btw | 20:11 |
| heiko | sonney2k: what is the state of that? | 20:11 |
| @sonney2k | for each and every method | 20:11 |
| heiko | sonney2k: I have to admit that I never looked at this | 20:12 |
| @sonney2k | heiko, look at http://shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/869/steps/test%20python_modular/logs/stdio | 20:12 |
| heiko | sonney2k: so how does it work? | 20:12 |
| blackburn | OOOOOOOOOPS | 20:13 |
| heiko | how is each an every method tested? | 20:13 |
| heiko | sonney2k: I added similar things to my unit-tests | 20:14 |
| heiko | like the result on this fixed data has to be that | 20:14 |
| @sonney2k | heiko, go to shogun/tests/integration/python_modular | 20:14 |
| @sonney2k | there is tester.py | 20:14 |
| @sonney2k | and generator.py | 20:14 |
| @sonney2k | *very* small scripts | 20:15 |
| @sonney2k | generator.py does nothing more than run one example with the parameters specified in that example | 20:16 |
| @sonney2k | and write the output to a file | 20:16 |
| heiko | sonney2k: I see thats why some examples have parameters | 20:16 |
| @sonney2k | tester loads that output and runs the example and really 1:1 compares the stuff | 20:16 |
| @sonney2k | like binary comparison | 20:16 |
| heiko | sonney2k: so this is to ensure that methods do not change | 20:17 |
| @sonney2k | for this to to work you need deterministic algorithms | 20:17 |
| @sonney2k | that is no parallel stuff | 20:17 |
| @sonney2k | and init random number generator | 20:17 |
| @sonney2k | exactly | 20:17 |
| heiko | I see | 20:17 |
| @sonney2k | and if they change | 20:17 |
| @sonney2k | just run generator.py with the example name that needs updating | 20:18 |
| heiko | so I added a lot of assertions in the unit-tests for similar things: fixed seed, fixed data, assert result | 20:18 |
| heiko | do you think its a bad idea to have two separate places where this is happening? | 20:18 |
| @sonney2k | heiko, yes | 20:19 |
| @sonney2k | just return the stuff in the function you want to see asserted | 20:19 |
| heiko | sonney2k: but how do I add the results | 20:20 |
| blackburn | sonney2k: found a bug, soon to come | 20:20 |
| heiko | sonney2k: I mean its not enough to just return it right? I need to specify the truth somewhere | 20:20 |
| @sonney2k | heiko, well you just run generator.py with that example once | 20:20 |
| heiko | sonney2k: ok I see, this generates the files | 20:21 |
| heiko | sonney2k: but there is one difference: I am comparing against matlab | 20:21 |
| heiko | the tester compares against the program against itself | 20:21 |
| @sonney2k | the tester compares against what the generator has once witten out | 20:22 |
| heiko | so the procedure would be, write example that works , compare with other implementation by hand, when correct, add integration test | 20:22 |
| @sonney2k | heiko, exactly | 20:23 |
| @sonney2k | that was my idea | 20:23 |
| heiko | sonney2k: so then unit-tests should be more implementation things | 20:23 |
| heiko | rather than results of numerical methods | 20:24 |
| heiko | well, this goes hand in hand | 20:24 |
| heiko | I think I will just add the integration tests additionally | 20:24 |
| heiko | doesnt hurt to have the others | 20:24 |
| heiko | sonney2k, blackburn, wiking I will go home now, long day, have a good evening! | 20:24 |
| blackburn | heiko: see you | 20:24 |
| -!- heiko [~heiko@nat-164-89.internal.eduroam.ucl.ac.uk] has left #shogun [] | 20:26 | |
| -!- n4nd0 [~nando@s83-179-44-135.cust.tele2.se] has joined #shogun | 20:48 | |
| -!- shogun-notifier- [~irker@7nn.de] has joined #shogun | 20:56 | |
| shogun-notifier- | shogun: Soeren Sonnenburg :master * b837e0e / tests/integration/python_modular/ (2 files): https://github.com/shogun-toolbox/shogun/commit/b837e0e589b2ecd67385532d7a9b0bcdae3cf327 | 20:56 |
| shogun-notifier- | shogun: fix integration test directory | 20:56 |
| shogun-buildbot | build #870 of deb3 - modular_interfaces is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/870 | 21:49 |
| -!- heiko [~heiko@5ac1f59a.bb.sky.com] has joined #shogun | 21:56 | |
| -!- sumit [ca4eaca2@gateway/web/freenode/ip.202.78.172.162] has joined #shogun | 22:10 | |
| -!- heiko [~heiko@5ac1f59a.bb.sky.com] has left #shogun [] | 22:13 | |
| -!- hoijui [~hoijui@dslb-092-078-043-220.pools.arcor-ip.net] has quit [Ping timeout: 264 seconds] | 22:26 | |
| -!- sumit [ca4eaca2@gateway/web/freenode/ip.202.78.172.162] has quit [Quit: Page closed] | 23:44 | |
| -!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout] | 23:56 | |
| -!- n4nd0 [~nando@s83-179-44-135.cust.tele2.se] has quit [Quit: leaving] | 23:57 | |
| --- Log closed Fri Mar 08 00:00:04 2013 | ||
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!
