--- Log opened Thu Jul 05 00:00:17 2012 | ||
-!- shogun-buildbot [~shogun-bu@7nn.de] has quit [Remote host closed the connection] | 00:02 | |
-!- shogun-buildbot [~shogun-bu@7nn.de] has joined #shogun | 00:02 | |
-!- shogun-buildbot [~shogun-bu@7nn.de] has quit [Remote host closed the connection] | 00:11 | |
-!- shogun-buildbot [~shogun-bu@7nn.de] has joined #shogun | 00:12 | |
shogun-buildbot | build #9 of nightly_none started, including [] | 00:14 |
---|---|---|
shogun-buildbot | build #9 of nightly_none is complete: Exception [exception interrupted] Build details are at http://www.shogun-toolbox.org/buildbot/builders/nightly_none/builds/9 | 00:14 |
shogun-buildbot | build #10 of nightly_none started, including [] | 00:16 |
gsomix | sonney2k, I see | 00:18 |
gsomix | good night guys | 00:18 |
n4nd0 | good night gsomix | 00:23 |
-!- gsomix [~gsomix@109.169.225.254] has quit [Ping timeout: 246 seconds] | 00:26 | |
shogun-buildbot | build #10 of nightly_none is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/nightly_none/builds/10 | 00:28 |
shogun-buildbot | build #65 of deb3 - modular_interfaces started, including [] | 00:28 |
shogun-buildbot | build #65 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/65 | 00:57 |
-!- n4nd0 [~nando@s83-179-44-135.cust.tele2.se] has quit [Quit: leaving] | 01:30 | |
alexlovesdata | I am the last active here :) | 02:02 |
shogun-buildbot | build #13 of nightly_default started, including [] | 03:00 |
shogun-buildbot | build #13 of nightly_default is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/nightly_default/builds/13 | 03:40 |
shogun-buildbot | build #8 of nightly_all started, including [] | 03:40 |
-!- alexlovesdata [55b20f06@gateway/web/freenode/ip.85.178.15.6] has quit [Quit: Page closed] | 03:59 | |
shogun-buildbot | build #8 of nightly_all is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/nightly_all/builds/8 | 04:06 |
shogun-buildbot | build #11 of nightly_none started, including [] | 04:06 |
shogun-buildbot | build #11 of nightly_none is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/nightly_none/builds/11 | 04:11 |
-!- uricamic [~uricamic@89.13.broadband14.iol.cz] has joined #shogun | 08:09 | |
-!- gsomix [~gsomix@109.169.246.7] has joined #shogun | 08:19 | |
-!- gsomix [~gsomix@109.169.246.7] has quit [Client Quit] | 08:23 | |
-!- uricamic [~uricamic@89.13.broadband14.iol.cz] has quit [Read error: Operation timed out] | 08:57 | |
-!- gsomix [~gsomix@109.169.246.7] has joined #shogun | 10:00 | |
gsomix | good morning | 10:00 |
-!- uricamic [~uricamic@89.13.broadband14.iol.cz] has joined #shogun | 10:09 | |
gsomix | sonney2k, ok, you are right. documentation for python is not good. | 10:27 |
gsomix | headers are better :) | 10:38 |
-!- blackburn [~blackburn@81.28.187.0] has joined #shogun | 10:50 | |
@sonney2k | gsomix, heh | 11:11 |
@sonney2k | gsomix, btw I hope we didn't have a misunderstanding yesterday - matplotlib is not essential for shogun | 11:12 |
@sonney2k | gsomix, however numpy is | 11:12 |
@sonney2k | and numpy supports python3 | 11:12 |
gsomix | sonney2k, but is essential for users I think | 11:13 |
@sonney2k | if they need gfx output yes | 11:14 |
gsomix | sonney2k, it's strange that there are not references to new buffer protocol in python2.7 docs. | 11:18 |
gsomix | except new C API functions. like GetBuffer() | 11:20 |
-!- blackburn [~blackburn@81.28.187.0] has quit [Quit: Leaving.] | 11:25 | |
-!- blackburn [~blackburn@81.28.187.0] has joined #shogun | 12:07 | |
@sonney2k | gsomix, yeah it is not well documented | 12:13 |
@sonney2k | gsomix, however I know that numpy implements it and also in python 3 the arrays | 12:13 |
gsomix | sonney2k, I just downloaded their code. | 12:30 |
-!- nietpiet [52ad81c6@gateway/web/freenode/ip.82.173.129.198] has joined #shogun | 12:39 | |
nietpiet | I'm sorry to bother anyone, but i tried to send my MKL issue to the mailing list, but my subscription email bounced, and thus i cannot post there. | 12:42 |
blackburn | nietpiet: bounced? why? | 12:44 |
blackburn | nietpiet: is you Jan? if so we have received your mail | 12:45 |
nietpiet | Ah! | 12:45 |
nietpiet | Sorry to be so impatient :) | 12:45 |
blackburn | heh no problem | 12:46 |
nietpiet | I sent it last night and got a delayed till 4 days mail :) | 12:46 |
blackburn | nietpiet: okay one question before - did you try latest shogun? | 12:46 |
nietpiet | yes.. downloaded it for the first time on tuesday | 12:46 |
nietpiet | (it is very nice!) | 12:46 |
blackburn | nietpiet: I actually can't remember whether we fixed something about MKL after 1.1.0 but it is worth to try | 12:49 |
nietpiet | True. I can make the kernel and labels of my post available for reproducability of course. | 12:49 |
nietpiet | But maybe i should just step away from the keyboard and patiently wait till the message hits the email list :) | 12:50 |
blackburn | nietpiet: there are two messages of you in the mailing list now | 12:51 |
nietpiet | ai.. they are probably the same. (Although I do not see any of them on the list) | 12:52 |
blackburn | hmm | 12:52 |
blackburn | strange | 12:53 |
nietpiet | The latest post I see is " GSoC weekly report - Latent SVM" from 2012-06-26 10:29:03 | 12:53 |
blackburn | yeah I see | 12:53 |
blackburn | nietpiet: could you please try the same with latest git of shogun? | 12:54 |
nietpiet | OK, i will try that. | 12:55 |
blackburn | nietpiet: feel free to ask anything | 12:55 |
nietpiet | About the list, maybe it is because of: "Delivery is delayed to these recipients or groups: shogun-list-subscribe@shogun-toolbox.org (shogun-list-subscribe@shogun-toolbox.org) Subject: This message hasn't been delivered yet. Delivery will continue to be attempted. The server will keep trying to deliver this message for the next 3 days, 19 hours and 59 minutes. You'll be notified if the message can't be delivered by that time." | 12:55 |
blackburn | huh | 12:55 |
nietpiet | Well.. about the MKL, i was thinking that maybe i made a silly mistake somewhere. | 12:57 |
nietpiet | Also, i'm not sure if libSVM will also use the kernel weights that are learned by the MKL, (and probably put in the CombinedKernel?) | 12:58 |
blackburn | random results look strange for me | 12:58 |
blackburn | yes it will use any kernel that you provide | 12:58 |
blackburn | mkl training modifies CombinedKernel with setting learned weights | 12:59 |
nietpiet | Ah.. i thought so. But in the example i posted i only use 1 kernel. Perhaps that is a problem for MKL? | 12:59 |
blackburn | ahh only one | 13:00 |
blackburn | but why only one? | 13:00 |
nietpiet | Cause the others take long to load from disk :) | 13:00 |
nietpiet | I did try with multiple kernels, but strangely results got worse.. | 13:01 |
blackburn | nietpiet: did you compare weights itself? | 13:01 |
blackburn | learned kernel weights I mean | 13:01 |
nietpiet | Yes, they were very low. | 13:01 |
blackburn | something e-19? | 13:02 |
nietpiet | ah.. no.. For one kernel like e-5, and the other two e-1 | 13:02 |
nietpiet | I will try the latest git first, but will prob. lose this connection, since i have to start a vpn. | 13:05 |
nietpiet | So thank you very much for your time! | 13:06 |
* wiking brb | 13:07 | |
-!- wiking [~wiking@huwico/staff/wiking] has quit [Quit: leaving] | 13:07 | |
-!- wiking [~wiking@mobile-out-229-70.siminn.is] has joined #shogun | 13:07 | |
-!- wiking [~wiking@mobile-out-229-70.siminn.is] has quit [Changing host] | 13:07 | |
-!- wiking [~wiking@huwico/staff/wiking] has joined #shogun | 13:07 | |
blackburn | nietpiet: sure - let me know if it become better or worse | 13:09 |
-!- nietpiet [52ad81c6@gateway/web/freenode/ip.82.173.129.198] has quit [Ping timeout: 245 seconds] | 13:10 | |
gsomix | sonney2k, wow! it works. | 13:18 |
-!- wiking [~wiking@huwico/staff/wiking] has quit [Quit: wiking] | 13:20 | |
-!- wiking [~wiking@huwico/staff/wiking] has joined #shogun | 13:21 | |
-!- n4nd0 [~nando@s83-179-44-135.cust.tele2.se] has joined #shogun | 13:37 | |
-!- wiking [~wiking@huwico/staff/wiking] has quit [Quit: wiking] | 13:42 | |
-!- wiking [~wiking@huwico/staff/wiking] has joined #shogun | 13:42 | |
-!- blackburn [~blackburn@81.28.187.0] has quit [Quit: Leaving.] | 13:45 | |
-!- blackburn [~blackburn@81.28.187.0] has joined #shogun | 13:47 | |
-!- blackburn [~blackburn@81.28.187.0] has quit [Quit: Leaving.] | 14:13 | |
-!- blackburn [~blackburn@81.28.187.0] has joined #shogun | 14:15 | |
@sonney2k | wiking, ACTION??? | 15:00 |
@sonney2k | gsomix, now with --verbose please - what works? | 15:01 |
gsomix | huh :) I have enabled buffer and sequence protocol for my vector3d class - works. memoryview may look a buffer, and vector3d+numpy.array also works | 15:03 |
gsomix | sonney2k, http://pastebin.com/E3pZXmQE my draft | 15:08 |
gsomix | sonney2k, http://pastebin.com/h5kjg8W1 output | 15:11 |
@sonney2k | gsomix, coool! | 15:15 |
@sonney2k | excellent work | 15:16 |
blackburn | sonney2k: can you git pull? | 15:17 |
@sonney2k | gsomix, so the next step would be to use swig to overload these slots - I would again attempt this on some toy data not shogun | 15:17 |
@sonney2k | blackburn, I cannot visit this page -> hang | 15:17 |
@sonney2k | gsomix, err not toy data - I meant toy example | 15:17 |
blackburn | sonney2k: could you please git pull google && [git push to all 3 .gits]? | 15:18 |
gsomix | sonney2k, I see | 15:18 |
blackburn | sonney2k: both github and shogun-toolbox repo deny me to push | 15:20 |
@sonney2k | gsomix, in the example will a+=b work? | 15:20 |
@sonney2k | b+=a would surely | 15:20 |
@sonney2k | or? | 15:20 |
@sonney2k | blackburn, ? | 15:20 |
gsomix | sonney2k, b+=a works, but a+=b returns numpy.array as result. | 15:21 |
@sonney2k | did you pull / rebase | 15:21 |
blackburn | sonney2k: argh sorry | 15:21 |
blackburn | I was setting up HW params and was root :D | 15:21 |
blackburn | hmm still | 15:22 |
blackburn | Permission denied (publickey). | 15:22 |
blackburn | fatal: The remote end hung up unexpectedly | 15:22 |
@sonney2k | blackburn, what does not work | 15:22 |
@sonney2k | pull? | 15:22 |
blackburn | sonney2k: both | 15:22 |
gsomix | sonney2k, I think I need to overload += and + for vector. right? hmmm, will look in the numpy code | 15:23 |
@sonney2k | blackburn, pull works fine here | 15:23 |
@sonney2k | gsomix, I am not so sure | 15:23 |
@sonney2k | gsomix, but most important for now is that a + b works | 15:23 |
@sonney2k | but maybe you should initialize a[0]=1 | 15:23 |
@sonney2k | a[1]=2 | 15:23 |
@sonney2k | a[2]=2 | 15:23 |
@sonney2k | a[2]=3 | 15:24 |
@sonney2k | in your example | 15:24 |
@sonney2k | otherwise it is not 100% clear if it really works :D | 15:24 |
-!- n4nd0 [~nando@s83-179-44-135.cust.tele2.se] has quit [Ping timeout: 265 seconds] | 15:24 | |
gsomix | sonney2k, http://pastebin.com/0tDLWjS2 | 15:27 |
@sonney2k | gsomix, perfect | 15:27 |
@sonney2k | gsomix, do you know where to look in swig docs for overloading tp_ * stuff? | 15:28 |
gsomix | sonney2k, --builtin? | 15:28 |
@sonney2k | gsomix, uhh look at this http://www.swig.org/Doc2.0/SWIGDocumentation.html#Python_nn75 | 15:29 |
CIA-18 | shogun: Sergey Lisitsyn master * ra75088e / (28 files in 5 dirs): Moved task structures out of multitask submodule - http://git.io/jRJFvA | 15:29 |
CIA-18 | shogun: Sergey Lisitsyn master * reea1b33 / (64 files in 19 dirs): Merge remote-tracking branch 'upstream/master' into slep - http://git.io/CbTqQA | 15:29 |
@sonney2k | gsomix, yes -builtin | 15:31 |
@sonney2k | like %feature("python:slot", "tp_hash", functype="hashfunc") Cheese::cheeseHashFunc; | 15:31 |
blackburn | argh lame merge | 15:31 |
blackburn | of me | 15:32 |
gsomix | sonney2k, thanks! | 15:32 |
shogun-buildbot | build #56 of deb1 - libshogun started, including [a75088e961e4e1cd8e6515a1653b0f852da6cfca] | 15:32 |
shogun-buildbot | build #57 of deb1 - libshogun started, including [eea1b33dde2297ed53d2c35ab4f46183bd761fd8] | 15:32 |
@sonney2k | uhh now two of them build at the same time! | 15:32 |
shogun-buildbot | build #57 of deb1 - libshogun is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb1%20-%20libshogun/builds/57 | 15:33 |
shogun-buildbot | build #66 of deb3 - modular_interfaces started, including [eea1b33dde2297ed53d2c35ab4f46183bd761fd8] | 15:33 |
@sonney2k | gsomix, what I would do is define the type again, wrap it with swig and override all the needed slots | 15:34 |
@sonney2k | gsomix, then check in the generated source code if these are really set | 15:34 |
@sonney2k | and try your numpy example again :) | 15:34 |
gsomix | ok, it's clear | 15:35 |
* sonney2k is pretty excited to see if this works | 15:36 | |
gsomix | sonney2k, I should to water my plants in garden. | 15:37 |
gsomix | see you later, ok? | 15:37 |
@sonney2k | gsomix, sure - and good work! | 15:38 |
gsomix | tnx | 15:38 |
shogun-buildbot | build #56 of deb1 - libshogun is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb1%20-%20libshogun/builds/56 | 15:38 |
shogun-buildbot | build #67 of deb2 - static_interfaces started, including [eea1b33dde2297ed53d2c35ab4f46183bd761fd8] | 15:38 |
shogun-buildbot | build #67 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/67 | 15:47 |
shogun-buildbot | build #67 of deb3 - modular_interfaces started, including [a75088e961e4e1cd8e6515a1653b0f852da6cfca] | 15:47 |
shogun-buildbot | build #67 of deb3 - modular_interfaces is complete: Failure [failed configure] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/67 blamelist: Sergey Lisitsyn <lisitsyn.s.o@gmail.com> | 15:49 |
shogun-buildbot | build #68 of deb2 - static_interfaces started, including [a75088e961e4e1cd8e6515a1653b0f852da6cfca] | 15:49 |
shogun-buildbot | build #68 of deb2 - static_interfaces is complete: Failure [failed configure] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb2%20-%20static_interfaces/builds/68 blamelist: Sergey Lisitsyn <lisitsyn.s.o@gmail.com> | 15:49 |
shogun-buildbot | build #66 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/66 | 16:11 |
CIA-18 | shogun: Sergey Lisitsyn master * r9c4e1d8 / (4 files in 2 dirs): Added FeatureBlockLogisticRegression - http://git.io/7R4MpQ | 16:54 |
shogun-buildbot | build #58 of deb1 - libshogun started, including [9c4e1d826fa8fb2b193f4ce344d6116c1b3a8b00] | 16:57 |
shogun-buildbot | build #58 of deb1 - libshogun is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb1%20-%20libshogun/builds/58 | 16:58 |
shogun-buildbot | build #68 of deb3 - modular_interfaces started, including [9c4e1d826fa8fb2b193f4ce344d6116c1b3a8b00] | 16:58 |
shogun-buildbot | build #69 of deb2 - static_interfaces started, including [9c4e1d826fa8fb2b193f4ce344d6116c1b3a8b00] | 16:58 |
-!- alexlovesdata_ [82955843@gateway/web/freenode/ip.130.149.88.67] has joined #shogun | 17:02 | |
shogun-buildbot | build #69 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/69 | 17:06 |
-!- heiko [~heiko@host86-174-148-28.range86-174.btcentralplus.com] has joined #shogun | 17:07 | |
CIA-18 | shogun: Heiko Strathmann master * r7418b63 / examples/undocumented/libshogun/statistics_quadratic_time_mmd.cpp : removed forgotten asserts to prevent fails - http://git.io/BHbzZw | 17:19 |
CIA-18 | shogun: Heiko Strathmann master * r50f3d0e / examples/undocumented/libshogun/statistics_quadratic_time_mmd.cpp : Merge pull request #624 from karlnapf/master - http://git.io/ZYWKXg | 17:19 |
-!- nietpiet [92329062@gateway/web/freenode/ip.146.50.144.98] has joined #shogun | 17:22 | |
shogun-buildbot | build #59 of deb1 - libshogun started, including [7418b6368ba7e6bb369c108a2c96c07cd686da7d] | 17:22 |
shogun-buildbot | build #59 of deb1 - libshogun is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb1%20-%20libshogun/builds/59 | 17:27 |
shogun-buildbot | build #60 of deb1 - libshogun started, including [50f3d0ed93148e5b957d8a1a14d8bfb014aa50b7] | 17:27 |
nietpiet | Hi Blackburn: I tried the latest git, but now i get a: " terminate called after throwing an instance of 'shogun::ShogunException', and a dumped core. ". At the .apply() step of the MKL, but the same for the .apply() step for libSVM.. I had to change my code a bit to include BinaryLabel. The mkl_binary documented example still works though.. strange.. maybe my beforehand and hand-created test kernel is fishy.. Although in the prev. v | 17:30 |
shogun-buildbot | build #60 of deb1 - libshogun is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb1%20-%20libshogun/builds/60 | 17:31 |
shogun-buildbot | build #69 of deb3 - modular_interfaces started, including [7418b6368ba7e6bb369c108a2c96c07cd686da7d] | 17:31 |
blackburn | nietpiet: it means there are some internal error - could you please try to do svm.io.set_loglevel(MSG_DEBUG) and paste the output somewhere? | 17:33 |
nietpiet | um.. sorry.. do i have to import something from the shogun package to be able to run that command? | 17:35 |
blackburn | nietpiet: to ease imports just do 'from modshogun import *' | 17:35 |
shogun-buildbot | build #68 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/68 | 17:36 |
shogun-buildbot | build #70 of deb2 - static_interfaces started, including [7418b6368ba7e6bb369c108a2c96c07cd686da7d, 50f3d0ed93148e5b957d8a1a14d8bfb014aa50b7] | 17:36 |
nietpiet | blackburn: um.. i did that import, but still: "NameError: name 'svm' is not defined" | 17:37 |
blackburn | nietpiet: [svm] is any shogun object you use | 17:38 |
blackburn | mkl classifier or anything else | 17:38 |
nietpiet | blackburn: i'm further, but still: AttributeError: 'getset_descriptor' object has no attribute 'set_loglevel' | 17:39 |
nietpiet | with MKLClassification.io.set_loglevel(MSG_DEBUG) | 17:39 |
blackburn | nietpiet: why mklclassification? | 17:40 |
blackburn | mkl itself | 17:40 |
-!- puffin444 [62e3926e@gateway/web/freenode/ip.98.227.146.110] has joined #shogun | 17:41 | |
shogun-buildbot | build #70 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/70 | 17:41 |
shogun-buildbot | build #70 of deb3 - modular_interfaces started, including [50f3d0ed93148e5b957d8a1a14d8bfb014aa50b7] | 17:41 |
nietpiet | blackburn: Sorry.. i'm a new to this. Still no go: MKL.io.set_loglevel(MSG_DEBUG) AttributeError: 'getset_descriptor' object has no attribute 'set_loglevel' with doing MKL.io.set_loglevel(MSG_DEBUG) | 17:42 |
blackburn | nietpiet: MKL should be an object | 17:42 |
blackburn | not a class | 17:42 |
nietpiet | ahaaaa.. let me try that. | 17:42 |
blackburn | in your example before you were using mkl so try that | 17:42 |
nietpiet | Blackburn: shall i just paste it here? (risk of polluting the log?) | 17:44 |
blackburn | nietpiet: no please rather use pastebin.com or so | 17:44 |
nietpiet | Blackburn: nice, never used that before: http://pastebin.com/jJMZqbUk | 17:46 |
blackburn | nietpiet: can you paste the code as well? | 17:47 |
blackburn | nietpiet: what I can say is weight seems to be correct - 1.0 | 17:49 |
nietpiet | Blackburn: Haha, yes, with one kernel. I can also try with 3 if you like. But libSVM also crashed with this single kernel. This is (a bit more) of the code: http://pastebin.com/mkQQ10wS | 17:50 |
nietpiet | Blackburn: One thing i had to do, is to transpose my test kernel, cause i had the training samples as the columns, wheras Shogun seems to see the training samples as the rows. | 17:53 |
nietpiet | (i think i used libSVM format for the precomputed kernel) | 17:53 |
blackburn | strange error is not being displayed | 17:53 |
nietpiet | Blackburn: and also strange that the mkl_binary example works, but this does not. | 17:56 |
blackburn | nietpiet: okay I think I know | 17:57 |
nietpiet | Great!! | 17:59 |
blackburn | nietpiet: are you able to recompile it now? | 17:59 |
nietpiet | yes. | 17:59 |
blackburn | nietpiet: could you please try to comment out /* ... */ lines 257-266 of src/shogun/machine/KernelMachine.cpp | 18:00 |
blackburn | then reinstall it and try your example again | 18:00 |
blackburn | basically problem is that you use no features | 18:00 |
blackburn | and it checks for features | 18:00 |
nietpiet | Aha.. yes, i did not store the features. | 18:01 |
nietpiet | Thank you! | 18:01 |
nietpiet | I will try that now. | 18:01 |
blackburn | if it works I will commit some quickfix | 18:04 |
nietpiet | Yes! it worked! I can apply it now. But, still a small error in the evaluation, so i can't yet tell if the random output problem is solved. ( evaluatorAP.evaluate( BinaryLabels(predSVM), labelsTE) NameError: global name 'evaluatorAP' is not defined ) will try and fix that now. | 18:05 |
shogun-buildbot | build #70 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/70 | 18:10 |
nietpiet | Blackburn: hmm.. My problem is still there. And now it seems the performance is really bad (close to random?) | 18:18 |
nietpiet | Average Precision MKL: run 1: 0.0385349355437, run 2: 0.0401661553578; libSVM: run 1: 0.03731640282, run 2: 0.037999599527 | 18:18 |
blackburn | nietpiet: is kernel weight still 1? | 18:19 |
nietpiet | Yes, | 18:19 |
nietpiet | Maybe something i do with the labels is wrong? Now it seems like random noise | 18:20 |
shogun-buildbot | build #69 of deb3 - modular_interfaces is complete: Failure [failed test python_modular] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/69 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com> | 18:20 |
heiko | ehm | 18:21 |
heiko | wtf? | 18:21 |
heiko | command timed out: 1200 seconds without output, attempting to kill | 18:21 |
heiko | running modelselection_grid_search_krr_modular.py .. | 18:21 |
blackburn | heiko: he fell asleep | 18:21 |
blackburn | nietpiet: yeah that looks strange | 18:22 |
heiko | blackburn, does this happen at your machine? | 18:23 |
blackburn | heiko: no I don't think so | 18:23 |
heiko | any idea why the bot does this? | 18:23 |
heiko | too slow computer | 18:23 |
heiko | ? | 18:23 |
blackburn | heiko: I would like to know too :D | 18:23 |
blackburn | no it is not slow I think | 18:23 |
heiko | mmh | 18:25 |
heiko | runs here in <2secs | 18:25 |
heiko | Ill just pretend the buildbot has gone crazy :D | 18:25 |
nietpiet | Blackburn: if I run the exact same problem 2x, then the nr of predicted +1 labels of mkl.apply().get_labels() with np.sum(predLabels==1) for the first run is 2102 and the 2nd run is 1176.. this seems close to random. With the prev. version of Shogun I got around 96% accuracy. quite strange.. | 18:37 |
blackburn | is apply random?? | 18:40 |
nietpiet | well.. haha. i hope not :). I will do the same test for the documented mkl_binary example now. | 18:41 |
blackburn | thanks | 18:43 |
nietpiet | for the mkl example it is constantly 73. | 18:44 |
puffin444 | Hey heiko, can I ask something about parameter hashing? | 18:45 |
heiko | hej puffin444, sure | 18:45 |
puffin444 | Instead of writing a new wrapper in CHash, do you think it makes sense just to use the full MurmurHash2() function. | 18:46 |
puffin444 | And use the hashed value of previous parameters as the seed for the next parameters to be hashed. | 18:47 |
heiko | dont know, Ill check the function | 18:48 |
blackburn | nietpiet: could you please check alphas? get_alphas() | 18:48 |
heiko | mmh when you look at the functions, it seems to be something different | 18:48 |
heiko | If the result is the same, sure | 18:49 |
heiko | but the operations are not the same, are they? | 18:49 |
puffin444 | Yes they are slightly different. It looks like the full function takes chunks of 4 bytes at a time. | 18:49 |
heiko | Also, there is something menioned about that data has to be aligned | 18:49 |
heiko | I think a new wrapper would be better then | 18:50 |
heiko | put "bytewise" in the name :) | 18:50 |
puffin444 | Oh now I see that. | 18:50 |
puffin444 | yeah I think a wrapper makes sense. | 18:50 |
heiko | yes, will make the code even easier to understand, and faster | 18:50 |
heiko | mmh | 18:51 |
heiko | I mean, the chunk wise thing is of course faster since fewer iterations ..... | 18:51 |
puffin444 | Yes but things could get really messy if there needs to be alignment | 18:52 |
nietpiet | Blackburn: Maybe something with precomputed kernels? If i do apply().get_labels() on the Training set, the nr of positives for 3 runs is: 14, 67, 70. Alphas for 2 runs are: http://pastebin.com/UuKthgWm | 18:53 |
heiko | yes, I actually dont know what that exactly means :D | 18:53 |
heiko | do you? | 18:53 |
heiko | the modulo is handled in the full hash method | 18:54 |
heiko | so perhaps it might be ok to use it | 18:54 |
puffin444 | I have a vague recollection from my comp. architecture class. It means that the memory has to divisible by four I think | 18:54 |
blackburn | nietpiet: I do not understand why alphas are changed :D | 18:54 |
heiko | mmh, same here, thats some time ago :) | 18:55 |
heiko | Perhaps you could compare the speed of the chunk wise hashing with the byte wise hashing for a reasonable matrix size? | 18:55 |
heiko | say 1000x1000 | 18:55 |
heiko | of float64_t | 18:55 |
heiko | and if there is a significant difference, we can think of it some more, maybe ask s?ren or whoever wrote the hashing code | 18:55 |
heiko | and if not, just use byte-wise | 18:56 |
heiko | (but for bytewise the loop has to be inside the function, otherwise it will definately loose) | 18:56 |
puffin444 | Who is Austin Appleby | 18:58 |
puffin444 | he wrote the murmur code | 18:58 |
heiko | puffin444, lol :) never heard that name :) | 19:01 |
puffin444 | Looks like this was code not directly written by someone with shogun. | 19:02 |
heiko | yes, its MIT license also, we usually dont do that | 19:02 |
puffin444 | Apparently Austin Appleby is the author of the murmur algorithm. | 19:02 |
heiko | lol really? :) | 19:02 |
heiko | well, then it proabably works correctly :) | 19:03 |
heiko | I would say just compare runtimes and then well decide (also compare if results are the same) | 19:03 |
nietpiet | Blackburn: here is the debug output for 3 runs.. http://pastebin.com/t02kUD8v maybe it is helpful. | 19:03 |
nietpiet | Blackburn: I can also make the Train and Test kernel available if that is helpful? | 19:05 |
blackburn | nietpiet: I can see objective values are very different | 19:05 |
puffin444 | heiko, things are a little more complicated. I don't think the IncrementalMurmurHash2 is a "real" implementation of the true murmur has function. | 19:09 |
heiko | puffin444, oh, thats bad, ...or wait: is it still a hashing function? thats the only thing that matters | 19:10 |
puffin444 | I don't know. I googled the name of the function and the only thing that comes up is Shogun. | 19:10 |
puffin444 | someone in shogun might have written that function. | 19:11 |
heiko | we can check on github, wait | 19:11 |
heiko | puffin444, | 19:12 |
heiko | https://github.com/shogun-toolbox/shogun/commit/022b47a562d8675f0db447ef2c1bc87bccc26026 | 19:12 |
heiko | it was ?ren :) | 19:12 |
heiko | s?ren | 19:12 |
heiko | you can ask him why he did that | 19:13 |
puffin444 | "Murmur-like" | 19:13 |
heiko | but the function should in my eyes do exactly do the same as the real hash | 19:13 |
heiko | only that you can bytewise pass data | 19:13 |
puffin444 | hey sonney2k, what's the purpose of IncrementalMurmurHash2() ? | 19:13 |
puffin444 | heiko, take a look at this: http://pyfasthash.googlecode.com/svn-history/r19/trunk/src/MurmurHash/MurmurHash2A.cpp | 19:14 |
puffin444 | This is a variant by the author which he claims is better for incremental hashes | 19:14 |
heiko | mmh | 19:15 |
heiko | looks good | 19:15 |
heiko | I dont know :) | 19:15 |
puffin444 | hey heiko what do you mean when you say "mmh"? | 19:15 |
heiko | it is an expression of thinking :D | 19:15 |
heiko | my fingers do their own stuff if the brain is busy with something else ;) | 19:16 |
puffin444 | It looks like the author has written a third version that is optimized for 64 bit architectures | 19:16 |
puffin444 | I was thinking you were always saying "meet me halfway" | 19:16 |
heiko | we could add all of this and check architecture before | 19:16 |
heiko | meet me halfway? :) | 19:16 |
heiko | no did not even know that one | 19:16 |
puffin444 | yes I was confused | 19:17 |
blackburn | puffin444: I tend to say hmm - would you think I say hidden markov model? ;) | 19:17 |
puffin444 | depends on the context | 19:17 |
heiko | funny :) | 19:17 |
puffin444 | I was asking about solutions to an ML problem and you responded with hmm.... | 19:18 |
puffin444 | Then maybe yes :) | 19:18 |
heiko | hehe ;) | 19:18 |
puffin444 | Another issue I see is that the murmur hashing function is non-cryptographic | 19:20 |
puffin444 | Although I don't know how important that is for parameter hashing or not. Technically I think murmur could create the same hash for two different param combinations. | 19:21 |
puffin444 | Although this would be exceedingly rare | 19:21 |
-!- uricamic [~uricamic@89.13.broadband14.iol.cz] has left #shogun [] | 19:23 | |
heiko | puffin444, that is not important | 19:24 |
puffin444 | okay | 19:24 |
heiko | any hashing function does that btw. | 19:24 |
heiko | there is no bijective map between the set of all hashs of a finite length and say all real numbers | 19:24 |
puffin444 | Yes but I would think that something like MD5 would be stronger, but it may be overkill for this situation. | 19:24 |
heiko | I think most important here is speed | 19:24 |
heiko | since you will call that a few times | 19:25 |
CIA-18 | shogun: Heiko Strathmann master * r7e96849 / (8 files in 2 dirs): Merge pull request #625 from karlnapf/master (+6 more commits...) - http://git.io/S2OhSA | 19:26 |
heiko | guys, I will head off now, bye bye | 19:26 |
puffin444 | Okay see you heiko. | 19:27 |
heiko | see you! :) | 19:27 |
shogun-buildbot | build #61 of deb1 - libshogun started, including [ff91003d710f377a8707f41c1ec4c52ef814c4b0] | 19:27 |
shogun-buildbot | build #62 of deb1 - libshogun started, including [2bb5cdfb3043a3dcaa7c4378098850a42cf06db6, 4832dd40d53836b660bbd266566028b701552c97] | 19:27 |
shogun-buildbot | build #61 of deb1 - libshogun is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb1%20-%20libshogun/builds/61 | 19:28 |
shogun-buildbot | build #63 of deb1 - libshogun started, including [6d9ce338d5bf1be8bce90a5a12324086294789a8, 1b7374b4ec518307aad3c837a7e752fc3a40b6a3, e913b8ade1cad5654fd1c77470891ba45381f501, 7e9684929e8506d4f4fab6b7969c6edc8c7ce5eb] | 19:28 |
-!- heiko [~heiko@host86-174-148-28.range86-174.btcentralplus.com] has left #shogun [] | 19:28 | |
shogun-buildbot | build #63 of deb1 - libshogun is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb1%20-%20libshogun/builds/63 | 19:29 |
shogun-buildbot | build #71 of deb3 - modular_interfaces started, including [ff91003d710f377a8707f41c1ec4c52ef814c4b0] | 19:29 |
shogun-buildbot | build #62 of deb1 - libshogun is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb1%20-%20libshogun/builds/62 | 19:32 |
shogun-buildbot | build #71 of deb2 - static_interfaces started, including [ff91003d710f377a8707f41c1ec4c52ef814c4b0, 6d9ce338d5bf1be8bce90a5a12324086294789a8, 1b7374b4ec518307aad3c837a7e752fc3a40b6a3, e913b8ade1cad5654fd1c77470891ba45381f501, 7e9684929e8506d4f4fab6b7969c6edc8c7ce5eb] | 19:32 |
@sonney2k | puffin444, whats wrong with the incremental murmurhash2? | 19:40 |
shogun-buildbot | build #71 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/71 | 19:40 |
shogun-buildbot | build #72 of deb3 - modular_interfaces started, including [6d9ce338d5bf1be8bce90a5a12324086294789a8, 1b7374b4ec518307aad3c837a7e752fc3a40b6a3, e913b8ade1cad5654fd1c77470891ba45381f501, 7e9684929e8506d4f4fab6b7969c6edc8c7ce5eb, 2bb5cdfb3043a3dcaa7c4378098850a42cf06db6, 4832dd40d53836b660bbd266566028b701552c97] | 19:40 |
puffin444 | Is it a true implementation of murmur hash? | 19:40 |
puffin444 | Because the author notes on his website that the murmur hash function is not incremental without special modifications. | 19:41 |
@sonney2k | puffin444, even though I wrote this code I don't remember exactly but I *think* that it will give the exact same result as murmurhash | 19:43 |
@sonney2k | 2 | 19:43 |
@sonney2k | puffin444, you of course need to pass the old seed - but I guess that is clear | 19:44 |
puffin444 | yes | 19:44 |
@sonney2k | puffin444, but maybe you just try on some small example (some string of length 10000 or so) | 19:44 |
puffin444 | I'll go and try that really quickly | 19:47 |
CIA-18 | shogun: Soeren Sonnenburg master * rb20223c / src/shogun/statistics/TwoSampleTestStatistic.cpp : fix typo -> distribution - http://git.io/8FToUQ | 19:47 |
puffin444 | Is library_hash supposed to yield the same result? | 19:49 |
CIA-18 | shogun: Sergey Lisitsyn master * r2cf3002 / (11 files in 5 dirs): Fixed FeatureBlockLogisticRegression solver and added Task and TaskTree - http://git.io/SurCuQ | 19:50 |
blackburn | whoa | 19:50 |
puffin444 | sonney2k, library_hash gives different results for murmur and incremental murmur hash. Is this supposed to happen? | 19:52 |
@sonney2k | puffin444, what is library_hash? | 19:52 |
puffin444 | in the examples folder for libshogun | 19:53 |
shogun-buildbot | build #71 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/71 | 19:57 |
shogun-buildbot | build #72 of deb2 - static_interfaces started, including [2bb5cdfb3043a3dcaa7c4378098850a42cf06db6, 4832dd40d53836b660bbd266566028b701552c97] | 19:57 |
puffin444 | sonney2k, if you are comfortable with it I found an updated version of murmur hash on the author's repro that does not require alignment and supports incremental processing. | 19:58 |
puffin444 | I could use this instead. | 19:59 |
puffin444 | http://smhasher.googlecode.com/svn/trunk/PMurHash.c | 19:59 |
nietpiet | Blackburn: Although i've not been able to use shogun yet, and i hope i can post to the list sometime soon too. But i'd like to thank you very much for your help. I'm gonna eat something now, and the VPN connection may time out in a while. | 20:02 |
blackburn | nietpiet: post what? :) | 20:02 |
blackburn | nietpiet: I'll check MKL example a little later | 20:02 |
shogun-buildbot | build #72 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/72 | 20:03 |
shogun-buildbot | build #64 of deb1 - libshogun started, including [b20223ce963c643fe7c47edb2fd6596db65d7fb8, 2cf3002942ef891c9993959a8861878654018fae] | 20:03 |
nietpiet | oh i noticed that my question is still not online here http://news.gmane.org/gmane.comp.ai.machine-learning.shogun | 20:03 |
blackburn | that's strange | 20:03 |
shogun-buildbot | build #64 of deb1 - libshogun is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb1%20-%20libshogun/builds/64 | 20:04 |
shogun-buildbot | build #73 of deb2 - static_interfaces started, including [b20223ce963c643fe7c47edb2fd6596db65d7fb8] | 20:04 |
nietpiet | So i guess the list is still waiting for my subscription email that i sent last night :) | 20:04 |
blackburn | nietpiet: IIRC it usually works without subscription | 20:05 |
nietpiet | Blackburn: I first got this: You have sent a message to be posted on the gmane.comp.ai.machine-learning.shogun newsgroup. This is a non-public mailing list, which means that you have to subscribe to the list to post to it. If you're already subscribed to the list, Gmane can forward the message you sent to the list if you respond to this message. If not, you should sign up to the mailing list first, and then respond to this mess | 20:06 |
nietpiet | So i sent an email to subscribe | 20:06 |
blackburn | right | 20:06 |
nietpiet | to here: shogun-list-subscribe@shogun-toolbox.org | 20:06 |
nietpiet | But that one gave: Delivery is delayed to these recipients or groups: shogun-list-subscribe@shogun-toolbox.org (shogun-list-subscribe@shogun-toolbox.org) Subject: This message hasn't been delivered yet. Delivery will continue to be attempted. The server will keep trying to deliver this message for the next 3 days, 19 hours and 59 minutes. You'll be notified if the message can't be delivered by that time. | 20:07 |
@sonney2k | puffin444, really? is this from the original author or somebody else | 20:07 |
nietpiet | So i guess it is still waiting :) | 20:07 |
puffin444 | This is technically not from the original author, but it is on the original author's repro. | 20:07 |
puffin444 | This particular version has been written to be platform independent, incrementable, and easily integrable into other projects. | 20:09 |
nietpiet | Blackburn: If ur interested, the kernels are here: http://staff.science.uva.nl/~jvgemert/shogun/ and thanks again for your help so far! | 20:09 |
shogun-buildbot | build #73 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/73 | 20:09 |
shogun-buildbot | build #73 of deb3 - modular_interfaces started, including [b20223ce963c643fe7c47edb2fd6596db65d7fb8, 2cf3002942ef891c9993959a8861878654018fae] | 20:09 |
blackburn | pretty big heh | 20:09 |
nietpiet | Haha.. yes.. and i have a few more that i'd like to combine :) | 20:10 |
nietpiet | oh.. i set all 0 labels to -1, but that is not that important. (those are the "hard" examples, i guess i can leave them out) | 20:15 |
blackburn | nietpiet: all labels should be either -1 or +1 | 20:16 |
-!- gsomix [~gsomix@109.169.246.7] has quit [Remote host closed the connection] | 20:19 | |
nietpiet | Blackburn: yeah, that is why i set the 0 labels beforehand to -1 :) | 20:19 |
@sonney2k | blackburn, nietpiet strange with gmane - I am asking the administor maybe it is related to the change of shogun servers | 20:21 |
@sonney2k | puffin444, well sounds good then | 20:21 |
puffin444 | sonney2k, I am going to test this out now | 20:22 |
@sonney2k | puffin444, there might be very few applications that potentially depend on this function but I don't expect too many so go ahead. | 20:23 |
-!- n4nd0 [~nando@s83-179-44-135.cust.tele2.se] has joined #shogun | 20:29 | |
shogun-buildbot | build #72 of deb3 - modular_interfaces is complete: Failure [failed test python_modular] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/72 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com> | 20:30 |
shogun-buildbot | build #74 of deb2 - static_interfaces started, including [2cf3002942ef891c9993959a8861878654018fae] | 20:30 |
-!- n4nd0 [~nando@s83-179-44-135.cust.tele2.se] has quit [Client Quit] | 20:33 | |
shogun-buildbot | build #74 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/74 | 20:38 |
shogun-buildbot | build #74 of deb3 - modular_interfaces started, including [] | 20:47 |
shogun-buildbot | build #73 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/73 | 20:47 |
@sonney2k | it is thunderstorm time! | 20:49 |
-!- alexlovesdata_ [82955843@gateway/web/freenode/ip.130.149.88.67] has quit [Quit: Page closed] | 21:27 | |
shogun-buildbot | build #74 of deb3 - modular_interfaces is complete: Failure [failed test python_modular] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/74 | 21:36 |
-!- nietpiet [92329062@gateway/web/freenode/ip.146.50.144.98] has quit [Ping timeout: 245 seconds] | 21:37 | |
-!- gsomix [~gsomix@109.169.246.7] has joined #shogun | 21:55 | |
@sonney2k | gsomix, the recent thunderstorm really killed my power supply | 22:06 |
@sonney2k | unit | 22:06 |
@sonney2k | now I have ~50 EUR less and a new one but things are working | 22:07 |
@sonney2k | and surprise new thunderstorm! | 22:07 |
gsomix | too many thunderstorm in Germany | 22:07 |
gsomix | *s | 22:08 |
gsomix | random pic http://piccy.info/view3/3225244/0c55735400d993a9ebeb0ba46756c81d/ | 22:15 |
gsomix | good night guys | 22:31 |
-!- gsomix [~gsomix@109.169.246.7] has quit [Quit: Ex-Chat] | 22:31 | |
@sonney2k | gsomix ??? black hole? | 22:36 |
-!- emrecelikten [~emre@213.153.222.106] has joined #shogun | 22:39 | |
-!- n4nd0 [~nando@s83-179-44-135.cust.tele2.se] has joined #shogun | 22:55 | |
-!- nietpiet [9232901a@gateway/web/freenode/ip.146.50.144.26] has joined #shogun | 23:01 | |
nietpiet | Blackburn, @sonney2k, Thanks for your help with the list. It seems to be a stupid exchance server thing at my end at work. I just tried with my private gmail and subscription went like a charm. Sorry to bother you.. Thanks, Jan. | 23:02 |
blackburn | nietpiet: no problem you are welcome | 23:02 |
nietpiet | I'll try and send my MKL thing to the list, maybe others have also experienced this. | 23:03 |
blackburn | nietpiet: which one? | 23:03 |
nietpiet | Well, both of them :) The one with the small random output from the stable source, and the one with the completely random results with the git version. | 23:04 |
blackburn | ah ok | 23:04 |
blackburn | strange it is random | 23:05 |
nietpiet | yeah.. you've seen those alpha scores :) | 23:05 |
blackburn | brb | 23:06 |
-!- blackburn [~blackburn@81.28.187.0] has quit [Remote host closed the connection] | 23:07 | |
-!- blackburn [~blackburn@81.28.187.0] has joined #shogun | 23:09 | |
shogun-buildbot | build #75 of deb3 - modular_interfaces started, including [] | 23:11 |
@sonney2k | blackburn, nietpiet what? | 23:33 |
@sonney2k | did I understand this correctly - totally random outputs with libsvm? | 23:34 |
nietpiet | @sonney2k, just thanking you for your help. The mailing list problem was a mistake on my end. | 23:34 |
nietpiet | Oh.. random, yes.. but only in my code :) The documented examples still work nicely. | 23:34 |
@sonney2k | nietpiet, no something is still fishy with the gmane archive... | 23:34 |
@sonney2k | nietpiet, where is your code | 23:35 |
@sonney2k | a) did you try to use a single thread only? | 23:35 |
@sonney2k | b) did you try to run the example under valgrind and see if there are uninited memory accesses | 23:35 |
nietpiet | @sonney2k, the code is here: http://pastebin.com/mkQQ10wS | 23:36 |
nietpiet | @sonney2k: I've never used valgrind with python before (only with c++). Yes! I can try to find out how i can turn off multi-threading | 23:37 |
@sonney2k | nietpiet, on your first created shogun object do obj.parallel.set_num_threads(1) | 23:39 |
nietpiet | @sonney2k, background info in the log from today: http://www.shogun-toolbox.org/irclogs/%23shogun.2012-07-05.log.html Blackburn was already very helpful. | 23:39 |
nietpiet | I will do that now. | 23:40 |
@sonney2k | note that due to parallel stuff the output is not deterministic(!) | 23:40 |
shogun-buildbot | build #75 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/75 | 23:40 |
@sonney2k | nietpiet, and please lets try to get this to work with libsvm first... | 23:40 |
@sonney2k | nietpiet, could you please get the real valued outputs of the svm too | 23:41 |
@sonney2k | you can do this via outputlabels.get_confidences() | 23:41 |
nietpiet | @sonney2k: Ok.. libSMV it is. The first shogun object is a combined kernel, shall i put the obj.parallel.set_num_threads(1) on that? Or on the libSVM object? | 23:42 |
@sonney2k | nietpiet, btw you don't need to do mkl.apply() twice | 23:44 |
@sonney2k | predLabels = mkl.apply() once is sufficient | 23:44 |
@sonney2k | and then predLabels.get_labels() to get the +1/-1 predictions | 23:44 |
@sonney2k | and predLabels.get_confidences() to get the real valued outputs | 23:44 |
@sonney2k | nietpiet, it doesn't matter | 23:45 |
@sonney2k | so put it on the first possible :) | 23:45 |
nietpiet | @sonney2k: yes.. i only did apply twice because i had a core dump somewhere there, and i wanted every statement to be on it's own line :) | 23:46 |
@sonney2k | k | 23:46 |
@sonney2k | though that already shouldn't happen | 23:46 |
nietpiet | Blackburn helped me around the core dump by commenting out some C++ lines. | 23:46 |
nietpiet | The kernel was checking for features, and i do not have any features anymore, only precomputed kernels.. | 23:47 |
blackburn | sonney2k: problem is that if you use only custom kernels and assign no features - kernel machine fails to apply | 23:47 |
@sonney2k | blackburn, I wonder why | 23:48 |
n4nd0 | sonney2k: btw, what is the trick that allows us to have templated classes separated in header and cpp files? | 23:48 |
blackburn | sonney2k: kernelmachine checks lhs | 23:48 |
n4nd0 | I thought that was not possible | 23:48 |
blackburn | n4nd0: why not? | 23:49 |
@sonney2k | blackburn, it should use has_lhs() and IIRC that is overloaded in customkernel to return true | 23:49 |
n4nd0 | blackburn: I think thatit is defined like that in the standard | 23:49 |
blackburn | sonney2k: KernelMachine 283 or so | 23:49 |
n4nd0 | blackburn: there are workarounds, but not recommended AFAIK | 23:49 |
@sonney2k | n4nd0, you have to explicitly name the types you want in the .cpp file | 23:49 |
@sonney2k | all others will not work | 23:49 |
n4nd0 | blackburn: but here it works fine, the only "weird" thing I see is ... | 23:50 |
n4nd0 | yeah exactly that | 23:50 |
@sonney2k | (or your will have to include the .cpp file!) | 23:50 |
n4nd0 | yes | 23:50 |
n4nd0 | that is how I managed to get it to work once | 23:50 |
n4nd0 | including the .cpp from the .h | 23:50 |
n4nd0 | I didn't know the one of the types though | 23:51 |
n4nd0 | nor the forums I read about a year ago to find a solution for this :D | 23:51 |
@sonney2k | blackburn, that code is totally b0rken | 23:51 |
blackburn | sonney2k: could you please take care of this? I am stucked with adjacency matrix -> tree shity conversion | 23:52 |
n4nd0 | blackburn: there was actually a sensible reason why, but I am afraid I do not remember | 23:52 |
blackburn | n4nd0: just like inline hehe | 23:52 |
n4nd0 | inline + virtual you mean? | 23:53 |
blackburn | n4nd0: no, inline in .cpp doesn't work too | 23:53 |
n4nd0 | aham, all right | 23:53 |
n4nd0 | I didn't know about that | 23:54 |
n4nd0 | funny details | 23:54 |
blackburn | actually that means something is wrong with C++ :D | 23:54 |
n4nd0 | too big to keep everything right maybe | 23:55 |
blackburn | it is not that cool to know that hammer you used to clinch nails with tends to kill people by mistake | 23:55 |
nietpiet | @sonney2k, blackburn, output of 5 single threaded runs here http://pastebin.com/heSyQLhP | 23:56 |
blackburn | nietpiet: I see confidences are equal | 23:56 |
blackburn | nearly | 23:56 |
nietpiet | Nr +1 is number of +1 labels predicted. ACC = accuracy, AVP = avg Precision. | 23:56 |
@sonney2k | blackburn, actually I understand now - we removed the apply() function - actually we merged apply() and apply(CFeatures* data) into one | 23:57 |
blackburn | sonney2k: yeah | 23:57 |
n4nd0 | blackburn: dafuq is wrong with your hammer!? | 23:57 |
blackburn | n4nd0: C++ is that hammer | 23:57 |
@sonney2k | so it now needs extra treatment to work | 23:57 |
blackburn | surgery | 23:58 |
n4nd0 | blackburn: I should read more poesy so I can get the metaphors better ;) | 23:58 |
@sonney2k | nietpiet, is that with a single thread already? | 23:59 |
@sonney2k | because I see fluctuations... so something is not deterministic... | 23:59 |
nietpiet | @sonney2k: Yes, i put kernelTR = CombinedKernel() and then kernelTR.parallel.set_num_threads(1) | 23:59 |
--- Log closed Fri Jul 06 00:00:17 2012 |
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!