--- Log opened Thu Jul 07 00:00:52 2011 | ||
blackburn | we should make some massive testing on many machines | 00:03 |
---|---|---|
blackburn | before 1.0 | 00:03 |
@sonney2k | blackburn, yeah... I usually build on cygwin, osx etc | 00:06 |
@sonney2k | but we also need some more changes | 00:06 |
@sonney2k | blackburn, for example the serialization thingy | 00:06 |
blackburn | we should make it earlier | 00:07 |
@sonney2k | I realized that we need a version in the m_parameters-> add thing | 00:07 |
blackburn | to make able 'freeze' it | 00:07 |
blackburn | for troubleshooting and etc | 00:07 |
@sonney2k | because now when one loads a old version some new variables are not filled in - that can cause errors... | 00:07 |
blackburn | old version of? | 00:08 |
@sonney2k | if you save/serialize an object | 00:08 |
blackburn | I never used it, how it can be used? | 00:08 |
@sonney2k | blackburn, jsut save | 00:08 |
@sonney2k | just | 00:08 |
blackburn | save some trained svm? | 00:08 |
@sonney2k | yes | 00:09 |
blackburn | I see | 00:09 |
@sonney2k | including kernels features etc | 00:09 |
@sonney2k | blackburn, same thing - when you call pickle on a shogun object | 00:10 |
blackburn | yeap | 00:10 |
blackburn | understand | 00:10 |
@sonney2k | but now when we add fields to be serialized it will be problematic to load old ones | 00:11 |
@sonney2k | so we need to add a version saying that this field was added in version XX | 00:11 |
@sonney2k | such that newer shogun version will be able to load older files | 00:11 |
blackburn | is it a heiko-related things? :) | 00:12 |
@sonney2k | of course with this restructuring we did - basically everything is incompatible now | 00:12 |
@sonney2k | blackburn, it is close to what heiko1 was modifying | 00:12 |
blackburn | much more pain for you both :D | 00:13 |
@sonney2k | even though it is easy to do - in parameters add a argument with version - it is painful as one has to modify all code | 00:14 |
@sonney2k | all the m_parameters->add(&some_variable, "shortname", "some_descr") needs to become m_parameters->add(SOME_VERSION, &some_variable,... | 00:14 |
blackburn | do you really want it? | 00:15 |
@sonney2k | only by doing that I can still run the test suite | 00:15 |
blackburn | hmm | 00:15 |
@sonney2k | blackburn, just consider we add one more variable to a kernel | 00:15 |
CIA-32 | shogun: Sergey Lisitsyn master * rfb96073 / (8 files): Some more doc for dimreduction preprocessors - http://bit.ly/qsh0AX | 00:15 |
@sonney2k | and you did some experiments | 00:15 |
@sonney2k | and did use pickle before | 00:16 |
@sonney2k | you definitely want to be able to load your models in newer shogun versions | 00:16 |
@sonney2k | otherwise it is more like m$ office $year | 00:17 |
blackburn | yes, it is needed | 00:17 |
@sonney2k | I mean we at least need that for version 1.0 | 00:19 |
blackburn | hehe 'some more doc' | 00:22 |
blackburn | sound like сам мудак | 00:22 |
-!- f-x__ [~f-x@213.155.190.131] has quit [Ping timeout: 258 seconds] | 00:26 | |
-!- f-x_ [~f-x@213.155.190.131] has joined #shogun | 00:32 | |
blackburn | sonney2k: received mail? | 00:37 |
@sonney2k | yes | 00:41 |
* sonney2k enters the congo territory | 00:42 | |
CIA-32 | shogun: Sergey Lisitsyn master * re44411c / src/libshogun/lib/arpack.cpp : ARPACK wrapper improvements - http://bit.ly/orvsoq | 00:44 |
f-x | sonney2k: how does shogun set the large file option in g++? through #define HAVE_LARGEFILE? | 00:45 |
@sonney2k | f-x, I thought this is no longer needed? | 00:45 |
f-x | sonney2k: I don't know exactly, but fopen gives an error when I try it on the training data | 00:46 |
f-x | 2.3GB | 00:46 |
@sonney2k | f-x, do you have a 32bit machine? | 00:46 |
@sonney2k | blackburn, I can reproduce the error gunnar is getting | 00:46 |
f-x | sonney2k: 64 bit, but I think the OS is built for 32 bit | 00:46 |
blackburn | sonney2k: no atlas? | 00:46 |
@sonney2k | blackburn, no atlas but blas and lapack | 00:47 |
blackburn | sonney2k: yes I'm already fixing it | 00:47 |
@sonney2k | f-x, hmmhh I guess you have to test this | 00:47 |
@sonney2k | blackburn, actually we don't have a HAVE_ATLAS check | 00:48 |
blackburn | sonney2k: oh.. what to do? | 00:48 |
@sonney2k | well not true | 00:49 |
@sonney2k | we have | 00:49 |
f-x | sonney2k: yes - mine's built for i686, not for 64 bit.. is there no way to open > 2GB files without an OS reinstall then? | 00:49 |
@sonney2k | blackburn, but why did you wrap this in HAVE_ATLAS | 00:49 |
blackburn | sonney2k: wrap what? | 00:50 |
@sonney2k | f-x, it could be that you then have to set some large file support | 00:50 |
@sonney2k | blackburn, libshogun/lib/arpack.h | 00:50 |
@sonney2k | blackburn, the ifdef HAVE_ATLAS - why is it there? | 00:50 |
blackburn | sonney2k: because arpack wrapper uses blas | 00:50 |
@sonney2k | blackburn, but then just check for HAVE_LAPACK | 00:51 |
@sonney2k | me checks if it compiles when doing so | 00:51 |
@sonney2k | make -j 32 :D | 00:52 |
blackburn | sonney2k: cblas and clapack is atlas things, right? | 00:53 |
blackburn | headers | 00:53 |
@sonney2k | I think so | 00:53 |
blackburn | so there should be HAVE_ATLAS I guess | 00:53 |
@sonney2k | blackburn, it compiled... | 00:53 |
blackburn | sonney2k: HAVE_LAPACK and no atlas installed? | 00:54 |
f-x | sonney2k: how does HAVE_LARGEFILE work? i'm unable to find it among standard gcc definitions | 00:54 |
@sonney2k | yes | 00:54 |
blackburn | okay | 00:54 |
@sonney2k | f-x, I see it only in open - the flag is O_LARGEFILE | 00:55 |
@sonney2k | there | 00:55 |
f-x | sonney2k: hmm.. for fopen and the rest we have to combine _FILE_OFFSET_BITS=64 and _LARGEFILE_SOURCE apparently | 00:56 |
f-x | checking it out | 00:56 |
blackburn | sonney2k: clapack is atlas thing | 00:57 |
blackburn | ehh.. I lost idea | 00:57 |
blackburn | sonney2k: you simply replaced it in wrapper ? | 00:57 |
@sonney2k | f-x, see http://www.suse.de/~aj/linux_lfs.html using lfs | 00:57 |
@sonney2k | f-x, -D_FILE_OFFSET_BITS=64 | 00:58 |
f-x | sonney2k: trying to add them to .config.. i'll try a make after that | 00:58 |
@sonney2k | only that flag is needed no more | 00:59 |
blackburn | sonney2k: HAVE_LAPACK instead of HAVE_ATLAS, right? | 00:59 |
@sonney2k | yes | 01:00 |
@sonney2k | which function do you think is offending | 01:00 |
@sonney2k | ? | 01:00 |
blackburn | eh? | 01:00 |
blackburn | what do you mean? | 01:00 |
@sonney2k | ahh the cblas_dsymv? | 01:01 |
@sonney2k | that one is in libblas-dev on debain | 01:02 |
@sonney2k | but this cries for problems on osx or so | 01:02 |
f-x | sonney2k: thanks - the error's gone.. and btw do I have to do 10 epochs over the data to be able to use the evaluation script? | 01:02 |
@sonney2k | f-x, yes use blackburn's evaluation code - i.e. return a label object with the outputs adn compute the aoPRC | 01:03 |
@sonney2k | f-x, but do the testing on a tiny file of 5 k or so in size | 01:03 |
blackburn | sonney2k: there is no dsymv.. | 01:04 |
@sonney2k | say head -n 1000 of the real data | 01:04 |
@sonney2k | blackburn, ? | 01:04 |
blackburn | you said dsymv will cause problems, there is no dsymv usage in arpack.cpp | 01:05 |
@sonney2k | line 103 | 01:05 |
@sonney2k | there is... | 01:06 |
blackburn | sonney2k: I have updated it | 01:06 |
@sonney2k | blackburn, me not :D | 01:06 |
blackburn | just 10 minutes ago | 01:06 |
blackburn | it uses dgemm now | 01:06 |
blackburn | dgemm is ok?:0 | 01:07 |
blackburn | :) | 01:07 |
@sonney2k | but you now use clapack_dgetrf | 01:07 |
@sonney2k | etc | 01:07 |
blackburn | is it bad? | 01:08 |
@sonney2k | this definitely only exists in atlas | 01:08 |
blackburn | sonney2k: I can't live without it :D | 01:08 |
blackburn | hmm I can disable mode==3 with no atlas | 01:09 |
@sonney2k | yeah but then HAVE_ARPACK should not be set to true if atlas is not there | 01:09 |
blackburn | I don't know how to avoid this | 01:09 |
blackburn | arpack without some lapack is useless | 01:09 |
@sonney2k | blackburn, well you use clapack_* | 01:10 |
blackburn | it provides no matvec operations - only reverse communication | 01:10 |
@sonney2k | either do the wrappers like we do in lib/lapack.* or require atlas | 01:10 |
blackburn | sonney2k: it is wrapped in lapack.h already | 01:10 |
@sonney2k | no | 01:12 |
@sonney2k | lib/arpack.cpp:92: error: ‘clapack_dgetrf’ was not declared in this scope | 01:12 |
@sonney2k | lib/arpack.cpp:93: error: ‘clapack_dgetri’ was not declared in this scope | 01:12 |
blackburn | sonney2k: it is wrapped inside HAVE_ATLAS :) | 01:13 |
@sonney2k | blackburn, what is wrapped inside HAVE_ATLAS? | 01:13 |
blackburn | sonney2k: dgetr{i,f} | 01:13 |
@sonney2k | which file? | 01:13 |
blackburn | lapack.h | 01:13 |
blackburn | lib/lapack.h | 01:14 |
@sonney2k | grep clapack_dgetrf libshogun/lib/lapack.{cpp,h} | 01:14 |
@sonney2k | returns nothing | 01:14 |
CIA-32 | shogun: Sergey Lisitsyn master * r30ca8a3 / (src/libshogun/lib/arpack.cpp src/libshogun/lib/arpack.h): Fixed compilation error of arpack wrapper - http://bit.ly/n5hH6v | 01:14 |
blackburn | sonney2k: ah sorry | 01:14 |
blackburn | dpotri | 01:14 |
blackburn | yes | 01:15 |
blackburn | sonney2k: can you test this up-to-date wrapper? | 01:15 |
blackburn | without atlas | 01:15 |
@sonney2k | yeah it does not compile | 01:15 |
blackburn | error? | 01:15 |
@sonney2k | ^ the one above | 01:16 |
@sonney2k | we need wrappers for dgetr* in lapack.cpp/h | 01:16 |
@sonney2k | alternatively we disable support for arpack if atlas is not installed | 01:17 |
blackburn | sonney2k: how can we disable arpack if atlas is not installed? | 01:19 |
@sonney2k | in the configure test we check for these needed clapack functions too | 01:20 |
blackburn | sonney2k: can you add some temporarily? | 01:20 |
@sonney2k | too tired today | 01:20 |
@sonney2k | but just the ones from your arpack call are sufficient... you can do so too | 01:21 |
blackburn | sonney2k: I'll better do wrappers now ) | 01:21 |
@sonney2k | yeah that would be better | 01:22 |
@sonney2k | pain again though | 01:22 |
blackburn | not much | 01:22 |
@sonney2k | a great blackburn is growing pain resistant | 01:28 |
blackburn | I will become a wrapper master as you became diaper one | 01:29 |
blackburn | sonney2k: here? | 01:41 |
@sonney2k | or there that is the question | 01:41 |
blackburn | okay | 01:42 |
blackburn | I'll push in a minute | 01:42 |
blackburn | can you test without atlas? | 01:42 |
@sonney2k | well I can compile on congo still | 01:42 |
blackburn | what is congo? | 01:42 |
@sonney2k | the dangerous war-zone | 01:43 |
blackburn | somali is more dangerous | 01:43 |
@sonney2k | and blackburn the wrapper rapper is even more | 01:43 |
blackburn | :D | 01:43 |
bettyboo | strange | 01:43 |
@sonney2k | so I hope your child (aka patch) kick ass rambo style | 01:44 |
* sonney2k sth is wrong with me today | 01:44 | |
blackburn | :D | 01:44 |
blackburn | compiles slow.. | 01:44 |
blackburn | 12 minutes?? | 01:56 |
blackburn | shit | 01:56 |
@sonney2k | 12 minutes? | 01:57 |
blackburn | it was compiling for more than 12 minutes | 01:57 |
@sonney2k | blackburn, great | 01:57 |
blackburn | pretty bad :) | 01:57 |
blackburn | okay I haven't broke anything | 01:57 |
blackburn | lets try | 01:57 |
@sonney2k | disable optimizations... | 01:58 |
CIA-32 | shogun: Sergey Lisitsyn master * r120604e / (3 files): An attempt to make arpack compile without atlas - http://bit.ly/nMZrST | 01:59 |
blackburn | sonney2k: try compile it | 01:59 |
@sonney2k | lib/lapack.cpp: In function ‘int clapack_dgetrf(CBLAS_ORDER, int, int, double*, int, int*)’: | 02:00 |
@sonney2k | lib/lapack.cpp:136: error: ‘dgetrf_’ was not declared in this scope | 02:00 |
@sonney2k | lib/lapack.cpp: In function ‘int clapack_dgetri(CBLAS_ORDER, int, double*, int, const int*)’: | 02:00 |
@sonney2k | lib/lapack.cpp:147: error: expected type-specifier before ‘work’ | 02:00 |
@sonney2k | lib/lapack.cpp:147: error: cannot convert ‘int*’ to ‘double*’ in initialization | 02:00 |
@sonney2k | lib/lapack.cpp:147: error: expected ‘,’ or ‘;’ before ‘work’ | 02:00 |
@sonney2k | lib/lapack.cpp:157: error: ‘dgetri_’ was not declared in this scope | 02:00 |
@sonney2k | lib/lapack.cpp:160: error: expected type-specifier before ‘work’ | 02:00 |
@sonney2k | lib/lapack.cpp:160: error: cannot convert ‘int*’ to ‘double*’ in assignment | 02:00 |
@sonney2k | lib/lapack.cpp:160: error: expected ‘;’ before ‘work’ | 02:00 |
@sonney2k | blackburn, you are getting close | 02:00 |
blackburn | ehh | 02:00 |
blackburn | OH | 02:01 |
blackburn | work = new work[lwork] | 02:01 |
blackburn | :D | 02:01 |
CIA-32 | shogun: Soeren Sonnenburg master * rc0e495d / src/libshogun/machine/LinearMachine.h : remove obsolete swig wrapper - http://bit.ly/oiBC14 | 02:02 |
CIA-32 | shogun: Soeren Sonnenburg master * r6b14520 / (2 files): add helper function to compute 3x2 table - http://bit.ly/oZI7PY | 02:02 |
CIA-32 | shogun: Soeren Sonnenburg master * rae673e4 / (12 files in 2 dirs): Merge branch 'master' of github.com:shogun-toolbox/shogun - http://bit.ly/qi0XxJ | 02:02 |
CIA-32 | shogun: Sergey Lisitsyn master * r06c39df / (src/libshogun/lib/lapack.cpp src/libshogun/lib/lapack.h): Fix for dgetr{i,f} - http://bit.ly/nvmhh2 | 02:06 |
blackburn | sonney2k: can you please test it again? | 02:06 |
@sonney2k | blackburn, | 02:08 |
@sonney2k | lib/lapack.cpp: In function ‘int clapack_dgetri(CBLAS_ORDER, int, double*, int, const int*)’: | 02:08 |
@sonney2k | lib/lapack.cpp:157: error: invalid conversion from ‘const int*’ to ‘int*’ | 02:08 |
@sonney2k | lib/lapack.cpp:157: error: cannot convert ‘double*’ to ‘int*’ for argument ‘5’ to ‘int dgetri_(int*, double*, int*, int*, int*, int*, int*)’ | 02:08 |
@sonney2k | lib/lapack.cpp:161: error: invalid conversion from ‘const int*’ to ‘int*’ | 02:08 |
@sonney2k | lib/lapack.cpp:161: error: cannot convert ‘double*’ to ‘int*’ for argument ‘5’ to ‘int dgetri_(int*, double*, int*, int*, int*, int*, int*)’ | 02:08 |
@sonney2k | make[1]: *** [lib/lapack.cpp.o] Error 1 | 02:08 |
@sonney2k | even closer :D | 02:08 |
blackburn | HRRRRRR | 02:08 |
CIA-32 | shogun: Sergey Lisitsyn master * ra827fb9 / src/libshogun/lib/lapack.h : Fix for dgetri definition - http://bit.ly/o69Q6R | 02:10 |
blackburn | sonney2k: now should work.. | 02:10 |
blackburn | btw, is there ACML at this 'congo'? | 02:10 |
@sonney2k | lib/lapack.cpp: In function ‘int clapack_dgetri(CBLAS_ORDER, int, double*, int, const int*)’: | 02:10 |
@sonney2k | lib/lapack.cpp:157: error: invalid conversion from ‘const int*’ to ‘int*’ | 02:11 |
@sonney2k | lib/lapack.cpp:157: error: initializing argument 4 of ‘int dgetri_(int*, double*, int*, int*, double*, int*, int*)’ | 02:11 |
@sonney2k | lib/lapack.cpp:157: error: invalid conversion from ‘int’ to ‘int*’ | 02:11 |
@sonney2k | lib/lapack.cpp:157: error: initializing argument 6 of ‘int dgetri_(int*, double*, int*, int*, double*, int*, int*)’ | 02:11 |
@sonney2k | lib/lapack.cpp:161: error: invalid conversion from ‘const int*’ to ‘int*’ | 02:11 |
@sonney2k | lib/lapack.cpp:161: error: initializing argument 4 of ‘int dgetri_(int*, double*, int*, int*, double*, int*, int*)’ | 02:11 |
@sonney2k | lib/lapack.cpp:161: error: invalid conversion from ‘int’ to ‘int*’ | 02:11 |
@sonney2k | lib/lapack.cpp:161: error: initializing argument 6 of ‘int dgetri_(int*, double*, int*, int*, double*, int*, int*)’ | 02:11 |
@sonney2k | incredibly close :D | 02:11 |
@sonney2k | blackburn, no | 02:14 |
blackburn | I'm getting mad | 02:14 |
blackburn | no what? | 02:14 |
@sonney2k | no ACML | 02:14 |
blackburn | ah | 02:14 |
@sonney2k | that is the wrapper pain... | 02:14 |
blackburn | sonney2k: how to avoid const int* to int*? | 02:14 |
blackburn | make a different one pointer? | 02:14 |
@sonney2k | not use const | 02:14 |
blackburn | good idea | 02:15 |
blackburn | sonney2k: I hope the last one | 02:16 |
CIA-32 | shogun: Sergey Lisitsyn master * r502bd56 / (src/libshogun/lib/lapack.cpp src/libshogun/lib/lapack.h): Fix for wrappers - http://bit.ly/nx1kmo | 02:16 |
@sonney2k | lib/lapack.cpp: In function ‘int clapack_dgetri(CBLAS_ORDER, int, double*, int, int*)’: | 02:17 |
@sonney2k | lib/lapack.cpp:157: error: lvalue required as unary ‘&’ operand | 02:17 |
blackburn | ahaha | 02:17 |
CIA-32 | shogun: Sergey Lisitsyn master * r40a4ea7 / src/libshogun/lib/lapack.cpp : Another one crazy fix for dgetri wrapper - http://bit.ly/rhq6XU | 02:19 |
blackburn | sonney2k: I pray for that one | 02:19 |
@sonney2k | blackburn, I hope you sent them to the right $DEITY | 02:20 |
@sonney2k | stroustrup? | 02:20 |
blackburn | sonney2k: $DEITY? | 02:20 |
blackburn | didn't understand anything :) | 02:21 |
@sonney2k | blackburn, http://en.wikipedia.org/wiki/Deity | 02:21 |
blackburn | ah | 02:21 |
blackburn | sonney2k: so, working? | 02:21 |
@sonney2k | looks like your choice of $DEITY was a good one | 02:22 |
@sonney2k | I would say that ends this day for us - at least I will go to bed now :) | 02:22 |
blackburn | thanks for compiling for me :D | 02:22 |
blackburn | 04-22 here | 02:22 |
blackburn | I want to sleep too :) | 02:22 |
bettyboo | grin | 02:22 |
@sonney2k | blackburn, announce success to gunnar and cu tomorrow | 02:22 |
@sonney2k | or today even | 02:22 |
blackburn | okaaay | 02:22 |
blackburn | yes, today | 02:22 |
-!- blackburn [~blackburn@188.122.238.99] has quit [Quit: Leaving.] | 02:25 | |
-!- f-x [~user@117.192.204.35] has quit [Read error: Connection reset by peer] | 02:26 | |
-!- heiko1 [~heiko@main.uni-duisburg.de] has quit [Ping timeout: 258 seconds] | 05:41 | |
-!- heiko [~heiko@main.uni-duisburg.de] has joined #shogun | 05:46 | |
CIA-32 | shogun: Shashwat Lal Das master * r04b8112 / (5 files in 3 dirs): Added a function to cancel the parse thread. And another to expand a vector upto the dimensionality of the features in StreamingDotFeatures. - http://bit.ly/nGhfPI | 09:10 |
CIA-32 | shogun: Shashwat Lal Das master * r9f7011e / src/libshogun/features/StreamingDotFeatures.h : Trivial commit. - http://bit.ly/nP01C4 | 09:10 |
CIA-32 | shogun: Shashwat Lal Das master * re72ed0b / (5 files in 2 dirs): Made an online version of sgd - OnlineSVMSGD, based on the original SVMSGD in shogun. - http://bit.ly/or07TE | 09:10 |
CIA-32 | shogun: Soeren Sonnenburg master * ra0d8aa3 / (8 files in 4 dirs): | 09:10 |
CIA-32 | shogun: Merge pull request #177 from frx/streaming_1 | 09:10 |
CIA-32 | shogun: OnlineSVMSGD with associated classes - http://bit.ly/pCt8Fv | 09:10 |
heiko | sonney2k, I left on my computer, thats why i was online :) | 09:31 |
@sonney2k | heiko, asodeska or so would the japanese say | 09:48 |
@sonney2k | heiko, there is one thing I discussed with blackburn that might be very relevant to you... | 09:49 |
@sonney2k | serialization currently is unversioned, i.e. when you do these m_parameters->add business it is not clear in which version this parameter appeared | 09:49 |
@sonney2k | and so one cannot load older files... | 09:50 |
@sonney2k | so at some point it makes a lot of sense to modify 'add' to have as first argument the version number | 09:50 |
heiko | yes this makes sense | 09:51 |
heiko | is there a macro that contains the version number? | 09:51 |
@sonney2k | so then the loader can check what his internal version is and what the version number of the file is and load only upto everythin <=internal_version | 09:51 |
@sonney2k | heiko, this all doesn't exist yet | 09:52 |
heiko | alright, then lets do it :) | 09:52 |
heiko | (when the other stuff is ready :) | 09:52 |
@sonney2k | it just came to my mind when trying to get the test suite running (I failed... because of these new subset additions that modify the serialization code) | 09:52 |
@sonney2k | heiko, yes | 09:52 |
@sonney2k | first do your stuff | 09:52 |
@sonney2k | but later we thought it is now in your area of expertise | 09:52 |
heiko | yes, good idea :) | 09:53 |
heiko | I currently have a little problem, c++ related, perhaps you know a quick answer: | 09:53 |
@sonney2k | of course we also have the problem that classes might be renamed etc and loading will fail due to that too | 09:53 |
@sonney2k | but we think of this when the problem appears (some kind of aliasing scheme) | 09:54 |
@sonney2k | there are more problems but anyway... | 09:54 |
@sonney2k | heiko, where is the question? | 09:54 |
heiko | yes, there will probably be more problems with versioning :) | 09:54 |
bettyboo | ;> | 09:55 |
heiko | but however: | 09:55 |
heiko | I want to create a DynamicArray with CAnyClass as type, but I get a compile error for the add_vector(&m_array.array ...) method in Dynamic array | 09:55 |
heiko | says, invalid conversion from CAnyclass*** to CSGObject*** | 09:55 |
heiko | should I just add a cast in the DynamicArray code? | 09:55 |
heiko | m_parameters->add_vector(&m_array.array, | 09:56 |
heiko | &m_array.num_elements, "array", | 09:56 |
heiko | "Memory for dynamic array."); | 09:56 |
heiko | this line | 09:56 |
@sonney2k | triple * ? | 09:56 |
heiko | yes, sorry the type is CAnyClass* | 09:57 |
heiko | DynamicArray<CAnyClass*> | 09:57 |
heiko | adress of an array of pointers | 09:57 |
@sonney2k | heiko, can't you use a dynamicarray for the array of pointers? | 09:58 |
@sonney2k | otherwise that is getting really messy | 09:58 |
heiko | yes i do, but the adress of this array is added to m_parameters | 09:58 |
@sonney2k | but then it is only ** ? | 09:59 |
heiko | *is the type of the DynamicArray class | 10:00 |
heiko | another* for an array of poitners | 10:00 |
heiko | and another * for the adress of that array since it is m_parameters->add_vector(&m_array.array, ... | 10:00 |
@sonney2k | heiko, the alternative is to use DynamicArrayPtr | 10:00 |
heiko | which is an array only for CSGObjects? | 10:00 |
@sonney2k | heiko, yes | 10:00 |
heiko | ok, perhaps this is just easier | 10:01 |
@sonney2k | and it uses ptrs already | 10:01 |
@sonney2k | but looking at the code it needs SG_REF / SG_UNREF treatment - I mean it makes sense now to always SG_REF when returning an element | 10:02 |
heiko | ok | 10:02 |
heiko | but DynamicArrayPtr does not do this | 10:03 |
@sonney2k | hmmhh dynarray 3 times, once derived form SGObject but templated, once not, once derived but for SGObject - I wish these could be merged | 10:03 |
@sonney2k | heiko, yeah - but it should. otherwise it does not make sense. | 10:03 |
heiko | perhaps I will also do this later and just stay with DynArray now, because the original intention was to make python work :) | 10:04 |
@sonney2k | heiko, why do you need to add a parameter btw? | 10:04 |
@sonney2k | or is this done in DYnamicArray already | 10:05 |
heiko | yes | 10:05 |
@sonney2k | then use DynamicArrayPtr | 10:05 |
@sonney2k | w/o fixing the REF issues | 10:05 |
heiko | w/o ? :) | 10:06 |
heiko | what does that mean? | 10:06 |
@sonney2k | without | 10:06 |
@sonney2k | w/ | 10:06 |
@sonney2k | with | 10:06 |
heiko | sorry, not very internet chat experience here :) | 10:06 |
heiko | ok whatever, I will change this | 10:06 |
@sonney2k | heiko, I just checked it is never used so far | 10:07 |
heiko | should I just add SGREF stuff then? | 10:07 |
@sonney2k | so let me please rename it | 10:08 |
@sonney2k | to DynamicObjectArray | 10:08 |
@sonney2k | or you do this | 10:08 |
heiko | ok I will | 10:08 |
heiko | SG_REF? | 10:08 |
@sonney2k | and then whenever someone puts in an element you need to SG_REF, when you return an element SG_REF, when you delete an element SG_UNREF and destroy the array when it is SG_UNREF'd | 10:09 |
heiko | ok, another question for the SG_REF stuff | 10:13 |
heiko | I found some places where this is not done. | 10:13 |
heiko | for example CLinearMachine::apply() | 10:14 |
heiko | CLabels* output=new CLabels(num); | 10:14 |
heiko | output->set_labels(out, num); | 10:14 |
heiko | return output; | 10:14 |
@sonney2k | heiko, yes when an object is *newly* created and you *don't* keep a reference to it this is not necessary | 10:14 |
@sonney2k | however you should write down the function names | 10:15 |
@sonney2k | I have to tell swig via the %newobject directive that this certain function returns a newly alloc'd object | 10:15 |
heiko | ok | 10:15 |
@sonney2k | heiko, btw thanks for the bug report :) | 10:16 |
@sonney2k | I just grepped trhough the code | 10:16 |
heiko | ehm, which one? | 10:16 |
@sonney2k | and I see that I forgot to rename classify -> apply | 10:16 |
heiko | hehe ok :) | 10:16 |
heiko | sonney2k, are you still there? | 10:31 |
heiko | what about type safety with the DynamicObjectArray? | 10:31 |
heiko | I want to call methods on elements, in particular from python | 10:31 |
heiko | but the array is not generic | 10:31 |
-!- sonney2k [~shogun@7nn.de] has quit [Ping timeout: 260 seconds] | 10:31 | |
-!- shogun-irclog [~shogun@7nn.de] has quit [Ping timeout: 260 seconds] | 10:31 | |
--- Log closed Thu Jul 07 10:31:55 2011 | ||
--- Log opened Thu Jul 07 10:47:25 2011 | ||
-!- shogun-irclog [~shogun@7nn.de] has joined #shogun | 10:47 | |
-!- Irssi: #shogun: Total of 10 nicks [2 ops, 0 halfops, 0 voices, 8 normal] | 10:47 | |
-!- Irssi: Join to #shogun was synced in 4 secs | 10:47 | |
CIA-32 | shogun: Heiko Strathmann master * rc4334b7 / (2 files): | 10:48 |
CIA-32 | shogun: -renamed DynamicArrayPtr to DynamicObjectArray | 10:48 |
CIA-32 | shogun: -added SG_REF/SG_UNREF treatment of elements - http://bit.ly/nXksZe | 10:48 |
CIA-32 | shogun: Soeren Sonnenburg master * rc49ac89 / (2 files): | 10:48 |
CIA-32 | shogun: Merge pull request #178 from karlnapf/master | 10:48 |
CIA-32 | shogun: DynamicObjectArray - http://bit.ly/nqHnU8 | 10:48 |
heiko | sonney2k, did you read my question before disconnect? | 10:49 |
@sonney2k | heiko, no wasn't there | 10:51 |
heiko | what about type safety with the DynamicObjectArray? | 10:54 |
heiko | I want to call methods on elements, in particular from python | 10:54 |
heiko | but the array is not generic | 10:54 |
heiko | wouldnt it be better if it would be generic but only allow subclasses ob CSGObject? | 10:54 |
-!- alesis-novik [~alesis@188.74.87.206] has joined #shogun | 10:57 | |
@sonney2k | heiko, yes please add this | 11:00 |
@sonney2k | I mean this is defined for SGObjects only anyway and so is not performance critical | 11:00 |
heiko | so to the DynamicObjectArray class? | 11:00 |
@sonney2k | yes | 11:00 |
heiko | ok | 11:00 |
@sonney2k | heiko, the other dyn* classes can be used like double* x[] | 11:01 |
heiko | this should work with swig and python then :) | 11:01 |
@sonney2k | so accessing things should better be fast | 11:01 |
@sonney2k | heiko, well the [] function is not necessary - unsupported by swig | 11:01 |
@sonney2k | so explicit set/ get functions are preferred | 11:01 |
heiko | ok, I mean SG_REF memory manegment and generic stuff | 11:02 |
@sonney2k | heiko, yes :) | 11:05 |
@sonney2k | that will work... | 11:05 |
-!- VojtechFranc [~quassel@gw-101.scnet.cz] has joined #shogun | 11:06 | |
-!- VojtechFranc is now known as vojta | 11:06 | |
-!- vojta is now known as VojtechFranc | 11:06 | |
VojtechFranc | hi alesis | 11:11 |
bettyboo | hey | 11:11 |
alesis-novik | Hello VojtechFranc | 11:11 |
alesis-novik | Did you manage to run the large dataset example? | 11:11 |
VojtechFranc | I finaly managed to install scipy v0.8.0 and it works. | 11:12 |
VojtechFranc | I plan to test the EM implementation more intensively. | 11:13 |
VojtechFranc | however, so far everything seems to work well. | 11:13 |
alesis-novik | My hope is that I didn't miss any memory leaks after moving to SG* | 11:14 |
alesis-novik | As far as I have tested it, it seems fine | 11:14 |
VojtechFranc | I will prepare some more test data and double-check the results with my Matlab implementation. | 11:15 |
VojtechFranc | we should proceed to the project stage two, i.e. implementing split-merge EM | 11:16 |
alesis-novik | Yes, I did look up a few papers on that, though maybe you already have something in mind? | 11:16 |
VojtechFranc | is there from your point of view enything which remains to be done on the basic EM / GMM implementation? | 11:17 |
VojtechFranc | yes, I'd like you to implement the classical SMEM algorithm http://mlg.eng.cam.ac.uk/zoubin/papers/uedanc.pdf | 11:18 |
alesis-novik | VojtechFranc, not that I could think of now. But if I think of something, I can always add it later. I think it's best to proceed. | 11:18 |
VojtechFranc | I have already did some experiments in Matlab. | 11:18 |
VojtechFranc | I suggest we take the same approach -- I'll send you Matlab implementation and you rewrite it to shogun | 11:19 |
alesis-novik | If you believe that's the best way, then sure. | 11:20 |
VojtechFranc | second option is that you implement it according to the paper | 11:20 |
alesis-novik | I could do that as well | 11:21 |
VojtechFranc | ok, let proceed as follows. you read the paper and think if everything is so clear you can implement it | 11:22 |
alesis-novik | sounds good. | 11:22 |
VojtechFranc | in the mean time, I finish my implementation (it is almost ready, but there are several things to tune) | 11:23 |
VojtechFranc | then we can discuss it and decide which way to go | 11:23 |
alesis-novik | While I haven't read it yet, I assume this will be another method for the GMM class (train_smem() for example) | 11:24 |
VojtechFranc | exactly | 11:24 |
VojtechFranc | the SMEM will call the classical EM algorithm | 11:24 |
VojtechFranc | in addition, it does some paramater updates (merge two components and split one) | 11:25 |
VojtechFranc | in order to avoid local optima | 11:25 |
VojtechFranc | can you read it today so that we can tommorow chat again ? | 11:26 |
alesis-novik | VojtechFranc, sure | 11:27 |
VojtechFranc | the paper is well written. it should not be a problem to understand it | 11:27 |
alesis-novik | I'll read it and see if there's anything I don't understand. I've skimmed it and it seems clear enough | 11:29 |
VojtechFranc | indeed it is not difficult. there won't be many new functions to implement. we can recycle thouse used in standard EM | 11:30 |
alesis-novik | I should be interesting to see if this will solve some of the problems the current EM runs into | 11:31 |
alesis-novik | VojtechFranc, I might need to separate out some of the functions out of the main train_em method for that, but I was thinking that it might be necessary already | 11:32 |
VojtechFranc | which ones exactly? | 11:32 |
VojtechFranc | the main bulting blocks are functions for computing log of p(x,y) and the complete ML estimate. I hope you implement these functions separately | 11:33 |
alesis-novik | the ml estimate is separate, but I think the log of p(x, y) is partially built in. There is a method called cluster which kind of does that, but in a slightly different way. I'll need to look at it again | 11:35 |
VojtechFranc | it is very useful to have the function computing log(p(x,y)) implemented separately, e.g. for classification etc | 11:36 |
alesis-novik | Also, given that this is written in c++, all methods work with the fields, which, from skimming the paper, I think might be not what we need because the algorithm uses candidates and reverting back | 11:38 |
VojtechFranc | the algorithm basically runs standard EM, then it constructs new initial models from the current solution and runs EM on these new initializations | 11:40 |
VojtechFranc | I don't see any reverting step but may be I didn't understand what you mean | 11:41 |
alesis-novik | Well, from what I gathered if the new model does worse, it reverts to the original, but like I said, I haven't read it in depth yet :) | 11:46 |
-!- in3xes_ [~in3xes@180.149.49.227] has quit [Read error: Operation timed out] | 11:48 | |
VojtechFranc | yes, it keeps the current model, then tries new candidates and if the new condidates do not work it returns the current one as the solution | 11:49 |
alesis-novik | Ah, so I can create new GMM objects for candidates then? | 11:50 |
VojtechFranc | exactly | 11:52 |
-!- in3xes_ [~in3xes@180.149.49.227] has joined #shogun | 12:01 | |
-!- VojtechFranc [~quassel@gw-101.scnet.cz] has quit [Ping timeout: 264 seconds] | 12:13 | |
-!- in3xes1 [~in3xes@180.149.49.227] has joined #shogun | 12:40 | |
-!- in3xes_ [~in3xes@180.149.49.227] has quit [Ping timeout: 258 seconds] | 12:44 | |
-!- VojtechFranc [~quassel@gw-101.scnet.cz] has joined #shogun | 12:57 | |
-!- in3xes [~in3xes@180.149.49.227] has joined #shogun | 13:06 | |
-!- in3xes_ [~in3xes@210.212.58.111] has joined #shogun | 13:29 | |
-!- in3xes__ [~in3xes@180.149.49.227] has joined #shogun | 13:30 | |
-!- in3xes1 [~in3xes@180.149.49.227] has quit [Ping timeout: 240 seconds] | 13:33 | |
-!- in3xes [~in3xes@180.149.49.227] has quit [Ping timeout: 258 seconds] | 13:33 | |
-!- in3xes__ is now known as in3xes | 13:37 | |
-!- in3xes__ [~in3xes@59.163.196.121] has joined #shogun | 13:47 | |
-!- in3xes [~in3xes@180.149.49.227] has quit [Ping timeout: 276 seconds] | 13:51 | |
-!- in3xes__ is now known as in3xes | 13:58 | |
-!- blackburn [~blackburn@188.122.238.99] has joined #shogun | 14:06 | |
blackburn | will we have a party today? :D | 14:10 |
-!- VojtechFranc [~quassel@gw-101.scnet.cz] has quit [Ping timeout: 276 seconds] | 14:38 | |
-!- f-x [~user@117.192.213.129] has joined #shogun | 14:40 | |
-!- VojtechFranc [~quassel@gw-101.scnet.cz] has joined #shogun | 14:50 | |
-!- sploving1 [~sploving@2001:cc0:2020:2022:5eff:35ff:fe04:f091] has joined #shogun | 15:00 | |
@sonney2k | party in 27 minutes | 15:03 |
sploving1 | soney2k, when I fetched upstream, and compiles. it shows the following error: /base/DynArray.h:379: error: ‘shogun::CSGObject** shogun::DynArray<shogun::CSGObject*>::array’ is protected | 15:09 |
sploving1 | http://pastebin.com/b06WAAxW sonney2k, | 15:11 |
sploving1 | the above link is the error | 15:11 |
@sonney2k | heiko I guess thats yours ^ | 15:12 |
blackburn | sonney2k confirm | 15:12 |
-!- cwidmer [~quassel@connect.tuebingen.mpg.de] has joined #shogun | 15:22 | |
blackburn | lets the party started ? :) | 15:30 |
-!- in3xes [~in3xes@59.163.196.121] has quit [Ping timeout: 252 seconds] | 15:30 | |
@sonney2k | Alright lets start | 15:32 |
@sonney2k | So midterm is coming up! | 15:32 |
@sonney2k | How is everyone doing, are you all on time? | 15:32 |
@sonney2k | And does everyone know what this involves? | 15:33 |
cwidmer | looks pretty good on blackburn's side, so yes | 15:33 |
@sonney2k | VojtechFranc, ? | 15:33 |
VojtechFranc | yes, alesis is follwing plan very well, no problems so far | 15:33 |
@sonney2k | I can tell heiko is also very well on track | 15:34 |
@sonney2k | and f-x is also progressing fine and sploving1 too | 15:34 |
@sonney2k | So everyone has to fill out forms between July 11 and (deadline!) 15th | 15:35 |
@sonney2k | students have to fill out forms for themselves and for their mentors | 15:35 |
@sonney2k | mentors just for the students | 15:35 |
@sonney2k | please don't miss the deadline | 15:35 |
cwidmer | ok | 15:35 |
-!- mikiobraun [~mikio@squid.ml.tu-berlin.de] has joined #shogun | 15:35 | |
cwidmer | it's on the radar :) | 15:35 |
sploving1 | glad to see you mikiobraun | 15:36 |
VojtechFranc | sonney2k, is there only a single form to fill (the one at Melange) or more? | 15:36 |
@sonney2k | the form will be available starting from July 11 | 15:37 |
@sonney2k | VojtechFranc, but I sent the questions around to the mentors mailinglist earlier | 15:37 |
mikiobraun | hi | 15:37 |
@sonney2k | (look at carols email) | 15:37 |
bettyboo | hi | 15:37 |
VojtechFranc | yes, I read them. | 15:37 |
@sonney2k | (at the end) | 15:37 |
@sonney2k | ok | 15:37 |
VojtechFranc | sonney2k, I have the email and read it. I just want to be sure that it is a single form to fill in... | 15:38 |
sploving1 | yeap. I think so | 15:38 |
@sonney2k | VojtechFranc, well I haven't seen the form but I guess so | 15:38 |
@sonney2k | at least that is what her letter was saying | 15:38 |
VojtechFranc | that's what I wanted to know :) | 15:39 |
@sonney2k | I know that some of you still promised to do a couple of 'features' to be achieved before mid-term so it does not really make sense to discuss future plans now. | 15:39 |
blackburn | I can tell about my plan - it is ready :D | 15:39 |
cwidmer | maybe its better to have the future plan discussion for each project separately | 15:40 |
VojtechFranc | I can tell you as well | 15:40 |
@sonney2k | So I would just like to remind everyone to please at least idle in IRC channel during normal working hours (many of you do already) but it is really a nice thing to get some synergistic effects | 15:40 |
blackburn | legendary synergistic pain in da ass | 15:41 |
heiko | hehe :) | 15:41 |
@sonney2k | So I would propose to have a short meeting just after Midterm, say July 15? to discuss future plans | 15:41 |
heiko | ok for me | 15:41 |
cwidmer | agreed | 15:41 |
VojtechFranc | ok | 15:41 |
heiko | but please not too late | 15:41 |
blackburn | okay, I won't be drunk on 15, July | 15:41 |
blackburn | :D | 15:42 |
@sonney2k | In the end we would like to end the more rough beginning period and get to a more stabilized shogun that one can by the end of August be used by everyone again :) | 15:42 |
sploving1 | ok. I hope not later than UTC2:00 | 15:42 |
bettyboo | ;D | 15:42 |
sploving1 | UTC14:00 | 15:42 |
@sonney2k | Jul 7, UTC 13:00 would be my suggestion again | 15:43 |
blackburn | 15 | 15:43 |
@sonney2k | err 15 | 15:43 |
@sonney2k | Jul 15, UTC 13:00 | 15:43 |
sploving1 | okay for me | 15:43 |
cwidmer | k | 15:43 |
heiko | ok for me | 15:43 |
VojtechFranc | ok | 15:43 |
f-x | suits me | 15:43 |
mikiobraun | yeah, whatever | 15:43 |
@sonney2k | ok then. Please don't forget to send in your reviews next week - the earlier the better | 15:43 |
@sonney2k | and please notify me that you did | 15:44 |
@sonney2k | Alright, that is all from my side - any question from your side, things you would want to see improved etc? | 15:44 |
@sonney2k | anyone? | 15:45 |
heiko | for me everything ok :=) | 15:45 |
cwidmer | same | 15:45 |
heiko | sonney2k, I just corrected the error, will send a pull request | 15:45 |
blackburn | sonney2k: I would like to have something to eat, is it an improvement? | 15:46 |
VojtechFranc | currently I have no problems I can finally even use the git ... :) | 15:46 |
bettyboo | ^_^ | 15:46 |
@sonney2k | then I guess blackburn can go and clean his roof from the snow and walk his bear | 15:46 |
blackburn | sonney2k: :D | 15:46 |
cwidmer | lol | 15:46 |
@sonney2k | so thanks all for attending this meeting | 15:46 |
@sonney2k | and see you next week (already!) | 15:46 |
cwidmer | ok, thanks sören | 15:46 |
cwidmer | cu | 15:46 |
blackburn | back to work! :) | 15:47 |
VojtechFranc | ok, bye | 15:47 |
heiko | bye ;) | 15:47 |
-!- cwidmer [~quassel@connect.tuebingen.mpg.de] has quit [Remote host closed the connection] | 15:47 | |
f-x | bye everybody | 15:47 |
@sonney2k | back to work indeed | 15:48 |
blackburn | chris doesn't talk to me much :) | 15:48 |
@sonney2k | blackburn, well you should drink with him then | 15:48 |
blackburn | sonney2k: is he an alcohol addict like me? | 15:48 |
CIA-32 | shogun: Heiko Strathmann master * r6245366 / src/libshogun/lib/DynamicObjectArray.h : made generic to have type safety - http://bit.ly/pW0GI6 | 15:49 |
CIA-32 | shogun: Heiko Strathmann master * rb5719cc / src/libshogun/base/DynArray.h : applied name change of DynamicObjectArray which is in addition now generic - http://bit.ly/pnyJNK | 15:49 |
CIA-32 | shogun: Heiko Strathmann master * raaf13bf / : Merge remote-tracking branch 'upstream/master' - http://bit.ly/nbIbk8 | 15:49 |
CIA-32 | shogun: Soeren Sonnenburg master * r111a5a7 / (2 files in 2 dirs): | 15:49 |
CIA-32 | shogun: Merge pull request #179 from karlnapf/master | 15:49 |
CIA-32 | shogun: error correction and generic DynamicObjectArray - http://bit.ly/qiFOhm | 15:49 |
blackburn | sonney2k: I will suggest to drink the thing we call ёрш | 15:49 |
@sonney2k | blackburn, he only has marginal training (he is German) but I guess you can practice with hime | 15:49 |
blackburn | sonney2k: ёрш is very simple cocktail: 50/50 vodka/beer :D | 15:49 |
@sonney2k | yeah for beginners a good starter | 15:50 |
@sonney2k | alright then | 15:50 |
blackburn | sonney2k: will SVR act well on some USD/EUR rate? | 15:50 |
blackburn | or any other rate | 15:51 |
blackburn | is it suitable for some graphical example? | 15:51 |
alesis-novik | Sorry I'm late | 15:52 |
alesis-novik | Hmm. It seems it's over already... | 15:53 |
blackburn | alesis-novik: you should definitely stay in the corner :D | 15:53 |
blackburn | we will punish you later | 15:53 |
alesis-novik | VojtechFranc, are you around? | 15:53 |
VojtechFranc | yes | 15:53 |
alesis-novik | I've been reading the paper. So from what I gather the idea is on every SMEM iteration to merge 2 gaussians and split 1, always keeping the same amount of Gaussians | 15:55 |
VojtechFranc | correct | 15:55 |
alesis-novik | Also use the simple heuristic to sort the candidates to hopefully reduce the amount we want to test | 15:56 |
VojtechFranc | yes | 15:56 |
alesis-novik | Well, the paper seems clear enough to implement SMEM using it | 15:57 |
VojtechFranc | so, have you comprehend everything to start implementing? | 15:58 |
alesis-novik | Yes. I'll probably separate out a partial_em(i, j, k) method as well | 15:58 |
VojtechFranc | I just spent 1 hour to rederive the update formula for "partial EM steps" which is not explained in the paper | 15:58 |
alesis-novik | VojtechFranc, that might be helpful to have, so that I don't need to redo it | 15:59 |
VojtechFranc | actually, to implement the algorithm you don't need it if you just trust the authors | 16:00 |
VojtechFranc | which I didn't ... :) | 16:00 |
VojtechFranc | just joking | 16:00 |
blackburn | VojtechFranc, alesis-novik, will your project take all the time to the end of August? | 16:02 |
blackburn | VojtechFranc: do you interested in gaussian processes? | 16:02 |
VojtechFranc | I guess we finish our project by the end of August | 16:03 |
alesis-novik | blackburn, scary things, those gaussian processes... | 16:03 |
blackburn | strictly? not earlier? | 16:03 |
VojtechFranc | blackburn, I know very very little aboyut GP | 16:03 |
blackburn | i just asking because if you will finish earlier we could work jointly on GPs in shogun | 16:03 |
blackburn | (and if I will) | 16:04 |
blackburn | let me know if you are interested | 16:04 |
-!- mikiobraun [~mikio@squid.ml.tu-berlin.de] has left #shogun ["Leaving."] | 16:04 | |
VojtechFranc | I'll see when we finish our EM project | 16:05 |
blackburn | okay | 16:05 |
alesis-novik | blackburn, I haven't looked through them, but given that Shogun already has a kernel mechanism, that removes one bit of work | 16:06 |
blackburn | alesis-novik: yeap. if you keep being interested in shogun dev after GSoC - we could collaborate somehow | 16:08 |
alesis-novik | sounds good. | 16:11 |
alesis-novik | VojtechFranc, I'll start implementing SMEM and email you if I run into any problems | 16:11 |
VojtechFranc | ok, great. | 16:12 |
VojtechFranc | I'll try to be in IRC the next week so we can chat if needed | 16:12 |
@sonney2k | f-x, around? | 16:22 |
f-x | sonney2k: here | 16:22 |
@sonney2k | well labels is not really a growing (Dyn*) vector | 16:24 |
@sonney2k | so I think least work would be to do it via dynamicarray and copy at the end | 16:25 |
f-x | sonney2k: yeah so i guess it's not worth it to change all that just for this case | 16:25 |
f-x | okay, that's good | 16:26 |
@sonney2k | yes :) | 16:27 |
bettyboo | :*) | 16:27 |
-!- in3xes_ [~in3xes@210.212.58.111] has quit [Remote host closed the connection] | 16:34 | |
-!- alesis-novik [~alesis@188.74.87.206] has quit [Quit: I'll be Bach] | 16:35 | |
-!- in3xes [~in3xes@180.149.49.227] has joined #shogun | 16:37 | |
-!- VojtechFranc [~quassel@gw-101.scnet.cz] has quit [Read error: Operation timed out] | 16:37 | |
heiko | any c++ guru here? | 16:42 |
@sonney2k | heiko, ? | 16:43 |
heiko | sonneyk2, I got this problem with the protected stuff again. | 16:46 |
heiko | I want to access protected elements from another class | 16:46 |
heiko | in DynamicObjectArray<T>, i got | 16:47 |
heiko | DynArray<T*> m_array; | 16:47 |
@sonney2k | the templated stuff again?! | 16:47 |
heiko | yes | 16:47 |
heiko | and in DynArray, I got: | 16:47 |
heiko | friend class CDynamicObjectArray<T>; | 16:47 |
blackburn | frieeends | 16:47 |
@sonney2k | heiko, sigh - I would define them friend | 16:47 |
@sonney2k | I see no other way :( | 16:48 |
blackburn | heiko: are you lacking pain in ass ©? | 16:48 |
heiko | hehe :) | 16:48 |
heiko | well there is this friend line in DynArray | 16:48 |
heiko | but the error apprears nevertheless | 16:48 |
heiko | and the funny thing is: | 16:49 |
heiko | that if i use DynArray<T> m_array; instead of DynArray<T*> m_array; | 16:49 |
heiko | the access to protected elements works | 16:49 |
CIA-32 | shogun: Soeren Sonnenburg master * r52f2f0a / src/modular/Classifier.i : tell swig that apply returns a new object - http://bit.ly/pKAgDX | 16:52 |
CIA-32 | shogun: Soeren Sonnenburg master * r5bd07dc / (2 files): add fishers statistics test for 2x3 tables - http://bit.ly/pF6FSS | 16:52 |
CIA-32 | shogun: Soeren Sonnenburg master * re630eb2 / (3 files in 2 dirs): Merge branch 'master' of github.com:shogun-toolbox/shogun into fisher - http://bit.ly/nT8L3i | 16:52 |
blackburn | what it is | 16:53 |
heiko | so this somehow depends on the types, | 16:54 |
@sonney2k | heiko, very werid | 16:54 |
heiko | or do I miss something | 16:54 |
heiko | I mean if I got friend class CDynamicObjectArray<T> in a class that has protected elements, I normally can access these from CDynamicObjectArray , or not? | 16:55 |
@sonney2k | heiko, and if you do friend class CDynamicObjectArray<T*>; | 16:55 |
@sonney2k | ? | 16:55 |
heiko | its the other way round | 16:55 |
heiko | should be *T | 16:55 |
heiko | but does not work | 16:55 |
@sonney2k | other way round? | 16:56 |
@sonney2k | I see | 16:56 |
heiko | because the T in DynArray is the T* of DynamicObjectArray | 16:56 |
heiko | but no, does not work :( | 16:56 |
heiko | I think, perhaps this is just not possible | 16:59 |
@sonney2k | heiko, is this committed? | 17:00 |
@sonney2k | I would like to see this on my own. | 17:00 |
heiko | I could push it to my master repo? | 17:00 |
-!- sploving1 [~sploving@2001:cc0:2020:2022:5eff:35ff:fe04:f091] has left #shogun [] | 17:00 | |
heiko | or I just could post both files | 17:01 |
heiko | ok pushed | 17:02 |
heiko | https://github.com/shogun-toolbox/shogun | 17:03 |
heiko | ehm | 17:03 |
heiko | https://github.com/karlnapf/shogun | 17:03 |
heiko | files lib/DynamicObjectArray.h and base/DynArray.h | 17:03 |
heiko | or I just make a pull request then you can see | 17:04 |
heiko | sorry, I have to go now for today. | 17:05 |
heiko | But if you directly can see what the error is, I'll be happy. | 17:06 |
heiko | will be back tomorrow! | 17:06 |
heiko | see you! | 17:06 |
-!- heiko [~heiko@main.uni-duisburg.de] has quit [Ping timeout: 258 seconds] | 17:10 | |
@sonney2k | ha heiko now I know: | 17:36 |
@sonney2k | template<class U> friend class CDynamicArray; | 17:36 |
@sonney2k | like this! | 17:36 |
CIA-32 | shogun: Soeren Sonnenburg master * r37fcfdc / src/libshogun/base/DynArray.h : properly do the templating with friends - http://bit.ly/r2oXsC | 17:39 |
@sonney2k | blackburn, ^ seen this? Hefty! There is always sth one does not know.... | 17:41 |
blackburn | sonney2k: I prefer avoiding friends :D | 17:41 |
blackburn | (in C++) | 17:41 |
blackburn | (in real life too sometimes) :D | 17:41 |
bettyboo | crazy | 17:41 |
@sonney2k | blackburn, yes one should | 17:41 |
@sonney2k | but in this case we we have a family of dynamicarrays | 17:42 |
blackburn | C++ is a wonderland of const, friend, volatile, blablile | 17:42 |
@sonney2k | interacting | 17:42 |
@sonney2k | yeah | 17:42 |
blackburn | sonney2k: what about my SVR question, have you any ideas? | 17:43 |
@sonney2k | your what? | 17:43 |
@sonney2k | you never ask questions... you only solve the problems I pose to you | 17:43 |
blackburn | I asked you about suitability of SVR to financial rates | 17:44 |
@sonney2k | it will of course work :) | 17:44 |
blackburn | I'm thinking about some small tasks to new people :) | 17:44 |
@sonney2k | at least you can overfit the curve - not sure about the prediction | 17:45 |
blackburn | okay, it could be a task for my girlfriend haha | 17:46 |
@sonney2k | *lol* | 17:47 |
-!- f-x [~user@117.192.213.129] has quit [Remote host closed the connection] | 18:27 | |
-!- VojtechFranc [~quassel@gw-101.scnet.cz] has joined #shogun | 18:40 | |
-!- in3xes [~in3xes@180.149.49.227] has quit [Read error: Connection reset by peer] | 18:53 | |
-!- f-x_ [~f-x@213.155.190.131] has quit [Ping timeout: 252 seconds] | 18:53 | |
-!- f-x [~f-x@213.155.190.141] has joined #shogun | 18:54 | |
-!- f-x is now known as Guest55834 | 18:54 | |
blackburn | sonney2k: | 19:27 |
blackburn | lib/Mathematics.cpp: In static member function ‘static shogun::SGVector<double> shogun::CMath::fishers_exact_test_for_multiple_2x3_tables(shogun::SGMatrix<double>)’: | 19:27 |
blackburn | lib/Mathematics.cpp:179: error: call of overloaded ‘SGMatrix(NULL, int, int)’ is ambiguous | 19:27 |
blackburn | added ,false - works now | 19:30 |
blackburn | wow | 19:51 |
@sonney2k | blackburn, strange | 19:51 |
@sonney2k | this did compile here?! | 19:51 |
blackburn | I've done lle with arpack yesterday | 19:51 |
blackburn | didn't know | 19:51 |
blackburn | :D | 19:51 |
bettyboo | <:*) | 19:51 |
blackburn | hmm it is pretty fast now | 19:52 |
blackburn | I rock | 19:52 |
@sonney2k | now all the girls hail to you | 19:52 |
blackburn | sth like that | 19:53 |
@sonney2k | the crowd cheers | 19:53 |
-!- VojtechFranc_ [~quassel@gw-101.scnet.cz] has joined #shogun | 19:54 | |
-!- VojtechFranc [~quassel@gw-101.scnet.cz] has quit [Ping timeout: 240 seconds] | 19:55 | |
-!- VojtechFranc_ is now known as VojtechFranc | 19:55 | |
blackburn | I guess I should replace inverse with just LU Ax=b solver | 19:56 |
blackburn | but now vodka time | 19:56 |
* sonney2k switches into something more comfortable... | 19:56 | |
* sonney2k Lederhosen! | 19:56 | |
blackburn | ahaha | 19:56 |
* blackburn found wtf is lederhosen | 19:57 | |
CIA-32 | shogun: Shashwat Lal Das master * r827f72a / (3 files in 2 dirs): | 19:57 |
CIA-32 | shogun: Made a check for whether the parser is running already in start_parser(). | 19:57 |
CIA-32 | shogun: Implemented the apply() function for OnlineLinearMachine. - http://bit.ly/qeI7LK | 19:57 |
CIA-32 | shogun: Shashwat Lal Das master * rb93b623 / (2 files): Rename apply_to_this_example to apply_to_current_example() in OnlineLinearMachine. - http://bit.ly/pQeWgM | 19:57 |
CIA-32 | shogun: Soeren Sonnenburg master * re5e175f / (3 files in 2 dirs): | 19:57 |
CIA-32 | shogun: Merge pull request #181 from frx/streaming_1 | 19:57 |
CIA-32 | shogun: OnlineLinearMachine minor modifications - http://bit.ly/p8uLOp | 19:57 |
-!- VojtechFranc [~quassel@gw-101.scnet.cz] has quit [Quit: No Ping reply in 180 seconds.] | 20:01 | |
-!- VojtechFranc [~quassel@gw-101.scnet.cz] has joined #shogun | 20:04 | |
-!- VojtechFranc [~quassel@gw-101.scnet.cz] has quit [Ping timeout: 264 seconds] | 20:11 | |
-!- VojtechFranc [~quassel@gw-101.scnet.cz] has joined #shogun | 20:12 | |
-!- VojtechFranc [~quassel@gw-101.scnet.cz] has quit [Ping timeout: 246 seconds] | 20:17 | |
-!- VojtechFranc [~quassel@gw-101.scnet.cz] has joined #shogun | 20:18 | |
-!- VojtechFranc [~quassel@gw-101.scnet.cz] has quit [Ping timeout: 252 seconds] | 20:27 | |
-!- blackburn1 [~blackburn@188.122.238.99] has joined #shogun | 20:27 | |
CIA-32 | shogun: Sergey Lisitsyn master * r285cdee / src/libshogun/preprocessor/LocallyLinearEmbedding.cpp : Added ARPACK support for LocallyLinearEmbedding - http://bit.ly/oE55lD | 20:27 |
CIA-32 | shogun: Sergey Lisitsyn master * r539aaeb / (3 files in 2 dirs): Merge branch 'master' of github.com:shogun-toolbox/shogun - http://bit.ly/p3DIgC | 20:28 |
-!- blackburn [~blackburn@188.122.238.99] has quit [Read error: No route to host] | 20:28 | |
-!- Guest55834 [~f-x@213.155.190.141] has quit [Ping timeout: 260 seconds] | 21:25 | |
CIA-32 | shogun: Sergey Lisitsyn master * r393de5c / (4 files in 2 dirs): Moved swissroll example to subdir, added hemisphere example - http://bit.ly/pur74R | 21:31 |
CIA-32 | shogun: Sergey Lisitsyn master * rda3af46 / data : Updated data - http://bit.ly/q7Vc0G | 21:31 |
CIA-32 | shogun: Sergey Lisitsyn master * reeb0db5 / examples/undocumented/python_modular/graphical/swissroll_lle.py : Removed wrong example - http://bit.ly/n6vL7n | 21:33 |
-!- in3xes [~in3xes@180.149.49.227] has joined #shogun | 21:42 | |
-!- in3xes_ [~in3xes@210.212.58.229] has joined #shogun | 21:43 | |
-!- in3xes [~in3xes@180.149.49.227] has quit [Ping timeout: 240 seconds] | 21:47 | |
-!- in3xes_ is now known as in3xes | 21:48 | |
-!- f-x [~f-x@213.155.190.134] has joined #shogun | 21:52 | |
-!- f-x is now known as Guest74997 | 21:52 | |
-!- blackburn1 [~blackburn@188.122.238.99] has quit [Ping timeout: 255 seconds] | 22:21 | |
-!- f-x` [~user@117.192.213.129] has joined #shogun | 22:38 | |
@sonney2k | dammed | 22:43 |
@sonney2k | wasted time looking for a heisenbug | 22:44 |
CIA-32 | shogun: Soeren Sonnenburg master * rafbb4cf / (2 files): fix matrix order - http://bit.ly/oOnWeN | 22:47 |
CIA-32 | shogun: Soeren Sonnenburg master * reddc83a / (5 files in 4 dirs): Merge branch 'master' of github.com:shogun-toolbox/shogun - http://bit.ly/pQeBtL | 22:47 |
--- Log closed Fri Jul 08 00:00:54 2011 |
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!