| --- Log opened Thu Nov 21 00:00:12 2013 | ||
| --- Day changed Thu Nov 21 2013 | ||
| @wiking | ok | 00:00 |
|---|---|---|
| @wiking | so nooow | 00:00 |
| @wiking | before doing any other fucking thing in my life | 00:00 |
| @wiking | let's see this swig interface w/o libshogun compilation | 00:00 |
| @wiking | :)))) | 00:00 |
| @iglesiasg | the adapters? | 00:01 |
| @iglesiasg | I mean, what lisitsyn and you were talking about before | 00:01 |
| @wiking | naaah | 00:01 |
| @wiking | it's more like | 00:01 |
| @wiking | cmake hacking | 00:01 |
| @iglesiasg | ok | 00:01 |
| @wiking | how to compile swig interfaces | 00:01 |
| @wiking | w/o compiling libshogun | 00:01 |
| @iglesiasg | is matlab alive btw? | 00:02 |
| @wiking | (using the preinstalled one) | 00:02 |
| @wiking | iglesiasg: dunno how to generated the mex file | 00:02 |
| @wiking | until i dont know how to do that | 00:02 |
| @wiking | it's not usable | 00:02 |
| @iglesiasg | I am afraid I will be doing lot of matlab during my phd :| | 00:02 |
| @iglesiasg | all right, my cmake 2.8.9 is ready now | 00:02 |
| @wiking | iglesiasg: y u no scikit :D | 00:02 |
| @iglesiasg | wiking, I think the people where I will be are Matlab people | 00:03 |
| @iglesiasg | they mentioned that in the interview | 00:03 |
| @iglesiasg | no idea if they will give me freedom about that though | 00:03 |
| @iglesiasg | but even if they do, it is probably better that I adapt | 00:03 |
| @wiking | mmm | 00:09 |
| @wiking | matlab man | 00:09 |
| @wiking | that's like 90s | 00:09 |
| @wiking | and rather beginning of 90s :P | 00:09 |
| @wiking | but it'snot your fault | 00:09 |
| -!- travis-ci [~travis-ci@ec2-54-205-88-49.compute-1.amazonaws.com] has joined #shogun | 00:09 | |
| travis-ci | [travis-ci] it's Soeren Sonnenburg's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: http://travis-ci.org/shogun-toolbox/shogun/builds/14278824 | 00:09 |
| -!- travis-ci [~travis-ci@ec2-54-205-88-49.compute-1.amazonaws.com] has left #shogun [] | 00:09 | |
| @wiking | but u should bring chaaange | 00:09 |
| thoralf_ | Woha. Replacing DynamicObjectArray by DynArray<void *> worked instantly. No broken tests. | 00:09 |
| @wiking | be the obama of ML | 00:09 |
| @wiking | thoralf_: woohooo | 00:09 |
| thoralf_ | so maybe replacing void by StructuredLabels, but should work fine. | 00:10 |
| @wiking | i mean seriously | 00:10 |
| thoralf_ | Okay, will continue tomorrow. | 00:10 |
| @wiking | we could start using std::list | 00:10 |
| thoralf_ | :) | 00:10 |
| @wiking | it's not more bloated than this | 00:10 |
| @wiking | :P | 00:10 |
| @iglesiasg | wtf my Shogun doesn't compile now | 00:11 |
| @iglesiasg | ProtobufFile.h | 00:11 |
| @wiking | hahahah | 00:11 |
| @wiking | ok | 00:11 |
| @wiking | do u really use protobuf? | 00:11 |
| @wiking | or just happen to have the library around? | 00:11 |
| @iglesiasg | thoralf_, I add the doc fix and will change the set_label maybe tom | 00:11 |
| @wiking | if not using it | 00:11 |
| @wiking | apt-get remove the libprotobuf-dev | 00:12 |
| @wiking | or whatever it is called | 00:12 |
| @iglesiasg | it might be here because of GraphLab | 00:12 |
| @wiking | or comment out the protobuf detection in CMakeLists.txt | 00:12 |
| @wiking | iglesiasg: comment then | 00:12 |
| @iglesiasg | and I shouldn't remove it then until my thesis is graded :D | 00:12 |
| thoralf_ | iglesiasg: Don't do anything except the comment :P | 00:12 |
| @iglesiasg | could screw up new experiments if I need | 00:13 |
| * thoralf_ just refactors StructuredLabels | 00:13 | |
| @iglesiasg | thoralf_, you are the man :) | 00:13 |
| @wiking | iglesiasg: comment out line 741-748 in CMakeLists.txt | 00:13 |
| @iglesiasg | I just wrote added to pre-allocate to "number of labels to pre-allocate" | 00:13 |
| @iglesiasg | wiking, it is ok. I will try tomorrow again in the office computer | 00:14 |
| @iglesiasg | this one takes too much time to compile :( | 00:14 |
| @wiking | iglesiasg: okok i'm just saying | 00:14 |
| @wiking | it's not a surprise it doesn't work | 00:14 |
| @wiking | we fucking broke develop atm | 00:14 |
| @wiking | ;P | 00:14 |
| @wiking | but people can have fun with 3.0 | 00:14 |
| @iglesiasg | I should go back to arch again soon | 00:14 |
| @wiking | yeah arch is cool | 00:15 |
| @iglesiasg | I have the feeling everything is much much slower with ubuntu | 00:15 |
| @wiking | i[m using arch on my raspi | 00:15 |
| @iglesiasg | I don't know if it even makes sense | 00:15 |
| @iglesiasg | oh nice | 00:15 |
| @iglesiasg | I have it with raspbian | 00:15 |
| @wiking | aaah outdated shiatz | 00:15 |
| @iglesiasg | doing ros stuff with it | 00:15 |
| @iglesiasg | and I already tried once to get ros in arch | 00:15 |
| @wiking | arch has much more updated packages | 00:15 |
| @iglesiasg | and was not fun | 00:15 |
| @wiking | hahehhehe | 00:15 |
| @wiking | well tit for tat | 00:16 |
| @iglesiasg | hehe yeah | 00:16 |
| @wiking | ok | 00:16 |
| @wiking | fuckit | 00:16 |
| @wiking | i'm gonna masacre now the cmakefile | 00:16 |
| @wiking | agaaain | 00:16 |
| shogun-notifier- | shogun: Fernando Iglesias :develop * 9079856 / src/shogun/labels/StructuredLabels.h: https://github.com/shogun-toolbox/shogun/commit/90798560260a15596670f69529397fd1f564e85d | 00:16 |
| shogun-notifier- | shogun: Minor doc improvement in StructuredLabels constructor | 00:16 |
| shogun-notifier- | shogun: Fernando Iglesias :develop * 46e1bd5 / src/shogun/labels/StructuredLabels.h: https://github.com/shogun-toolbox/shogun/commit/46e1bd566a72d909d03722278de1a303e1e2cfb2 | 00:16 |
| shogun-notifier- | shogun: Merge pull request #1761 from iglesias/develop | 00:16 |
| shogun-notifier- | shogun: | 00:16 |
| shogun-notifier- | shogun: Minor doc improvement in StructuredLabels constructor | 00:16 |
| @iglesiasg | that was just a doc change so it should not kill anything :D | 00:17 |
| @iglesiasg | all right guys | 00:18 |
| @iglesiasg | good night | 00:18 |
| @iglesiasg | it was a pleasure | 00:18 |
| -!- iglesiasg [~iglesiasg@s83-179-44-135.cust.tele2.se] has quit [Quit: Leaving] | 00:18 | |
| shogun-buildbot_ | build #2036 of deb3 - modular_interfaces is complete: Failure [failed test ruby modular] Build details are at http://buildbot.shogun-toolbox.org/builders/deb3%20-%20modular_interfaces/builds/2036 blamelist: Soeren Sonnenburg <sonne@debian.org> | 00:19 |
| shogun-buildbot_ | build #1961 of bsd1 - libshogun is complete: Failure [failed compile test] Build details are at http://buildbot.shogun-toolbox.org/builders/bsd1%20-%20libshogun/builds/1961 blamelist: Soeren Sonnenburg <sonne@debian.org>, Fernando Iglesias <fernando.iglesiasg@gmail.com> | 00:30 |
| thoralf_ | src/shogun/base/class_list.cpp:673:125: error: cannot convert 'shogun::CFactorGraphObservation*' to 'shogun::CSGObject*' in return | 00:43 |
| thoralf_ | Grr. | 00:43 |
| thoralf_ | Dependencies on CSGObject are hidden in several places. ;) | 00:44 |
| thoralf_ | wiking: Any idea how to get StructuredData subclasses out of class_list? | 00:46 |
| thoralf_ | Houston, we've lost Serialization on StructuredData. | 00:50 |
| thoralf_ | total heap usage: 1,000,299 allocs, 299 frees, 32,033,787 bytes allocated | 00:51 |
| thoralf_ | 32 Bytes/Float. | 00:51 |
| thoralf_ | wiking: Editing class_list fixed it... is there a blacklist I could extend? | 00:53 |
| -!- thoralf_ [~thoralf@91-66-33-4-dynip.superkabel.de] has quit [Quit: Konversation terminated!] | 00:53 | |
| @wiking | yes | 00:54 |
| @wiking | or i think so | 00:54 |
| @wiking | src/shogun/base/class_list.cpp.py | 00:55 |
| @wiking | check this | 00:55 |
| -!- hushell [~hushell@c-50-188-141-210.hsd1.or.comcast.net] has quit [Ping timeout: 272 seconds] | 01:12 | |
| -!- hushell [~hushell@c-50-188-141-210.hsd1.or.comcast.net] has joined #shogun | 01:15 | |
| shogun-buildbot_ | build #2037 of deb3 - modular_interfaces is complete: Success [build successful] Build details are at http://buildbot.shogun-toolbox.org/builders/deb3%20-%20modular_interfaces/builds/2037 | 01:24 |
| shogun-buildbot_ | build #123 of clang34 - undefined behaviour analysis is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/clang34%20-%20undefined%20behaviour%20analysis/builds/123 blamelist: Soeren Sonnenburg <sonne@debian.org>, Fernando Iglesias <fernando.iglesiasg@gmail.com> | 01:39 |
| shogun-buildbot_ | build #121 of clang34 - thread analysis is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/clang34%20-%20thread%20analysis/builds/121 blamelist: Soeren Sonnenburg <sonne@debian.org>, Fernando Iglesias <fernando.iglesiasg@gmail.com> | 01:55 |
| -!- pickle27 [~kevin@24-212-221-132.cable.teksavvy.com] has joined #shogun | 02:36 | |
| shogun-buildbot_ | build #140 of clang34 - static analysis is complete: Failure [failed analyse] Build details are at http://buildbot.shogun-toolbox.org/builders/clang34%20-%20static%20analysis/builds/140 blamelist: Soeren Sonnenburg <sonne@debian.org>, Fernando Iglesias <fernando.iglesiasg@gmail.com> | 02:38 |
| -!- sonne|osx [~sonne@f053043202.adsl.alicedsl.de] has quit [Ping timeout: 248 seconds] | 03:14 | |
| -!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout] | 03:16 | |
| shogun-buildbot_ | build #624 of nightly_default is complete: Failure [failed notebooks] Build details are at http://buildbot.shogun-toolbox.org/builders/nightly_default/builds/624 | 04:59 |
| -!- pickle27 [~kevin@24-212-221-132.cable.teksavvy.com] has quit [Quit: Leaving.] | 05:04 | |
| -!- zxtx [~zv@129-79-241-148.dhcp-bl.indiana.edu] has quit [Ping timeout: 245 seconds] | 06:16 | |
| -!- zxtx [~zv@c-98-193-83-24.hsd1.il.comcast.net] has joined #shogun | 06:56 | |
| -!- Saurabh7 [~Saurabh7@115.248.130.148] has joined #shogun | 06:59 | |
| -!- Jagged [~NULL@vtluug/member/jagged] has quit [Read error: Operation timed out] | 07:38 | |
| -!- Jagged [~NULL@vtluug/member/jagged] has joined #shogun | 07:38 | |
| -!- Saurabh7 [~Saurabh7@115.248.130.148] has left #shogun ["Leaving"] | 07:45 | |
| -!- lisitsyn1 [~lisitsin@mxs.kg.ru] has joined #shogun | 08:53 | |
| lisitsyn1 | ah again | 08:53 |
| lisitsyn1 | sorry guys for gunfire haha | 08:53 |
| -!- lisitsyn [~lisitsyn@80.252.20.67] has quit [Disconnected by services] | 08:53 | |
| -!- lisitsyn1 is now known as lisitsyn | 08:54 | |
| -!- mode/#shogun [+o lisitsyn] by ChanServ | 08:54 | |
| -!- lisitsyn1 [~lisitsyn@80.252.20.67] has joined #shogun | 08:54 | |
| -!- lisitsyn1 was kicked from #shogun by lisitsyn [lisitsyn1] | 09:07 | |
| -!- iglesiasg [~iglesiasg@s83-179-44-135.cust.tele2.se] has joined #shogun | 09:21 | |
| -!- mode/#shogun [+o iglesiasg] by ChanServ | 09:21 | |
| @wiking | lisitsyn: btw about the droping stuff: it's in a way already part of shogun.. check the computational part. there's a Run class where u could plugin basically anything u want | 09:23 |
| @wiking | but what really concerns me atm is this RealNumber bloated shit | 09:24 |
| @wiking | that we need 127x more space for storing a stupid double :P | 09:24 |
| @lisitsyn | haha | 09:26 |
| @iglesiasg | c'mon RealNumber is not be used for real | 09:28 |
| @wiking | iglesiasg: but essentially yes | 09:28 |
| @iglesiasg | what do you mean? | 09:29 |
| @wiking | well what do u store in RealNumber | 09:29 |
| @wiking | a double no? | 09:29 |
| @wiking | anything else? | 09:29 |
| @iglesiasg | yep, just a double | 09:29 |
| @iglesiasg | but RealNumber is just used in SO | 09:30 |
| @wiking | yeah i know | 09:30 |
| @wiking | but this is outrages | 09:30 |
| @wiking | outragous | 09:30 |
| @iglesiasg | haha ok | 09:30 |
| @wiking | i mean this is far from being optimal | 09:30 |
| @iglesiasg | but it is not used! | 09:30 |
| @iglesiasg | let's care about real things | 09:30 |
| @wiking | iglesiasg: thoralf is using it no? :) | 09:30 |
| @iglesiasg | wiking, no no | 09:30 |
| @iglesiasg | thoralf had the same problem but using other kind of labels | 09:31 |
| @iglesiasg | since the overhead is the same | 09:31 |
| @iglesiasg | or at least I understood that | 09:31 |
| @wiking | iglesiasg: anyhow i think we should do something with this huge overhead somehow | 09:31 |
| @wiking | if possible at all | 09:31 |
| @iglesiasg | it should be less now after the shrinking of the DynamicObjectArray | 09:32 |
| @iglesiasg | although I am not sure if just setting size 4 for all Parameter and ParameterMap is the best way to do this | 09:32 |
| @wiking | besser82: do u really dislike the idea of vpn between the shoung-ca and shogun's fatbot? | 09:32 |
| thoralf | iglesiasg, wiking: Heard my name? ;) | 10:25 |
| * thoralf could change StructuredData to inherit from RefCount, nothing else. | 10:30 | |
| thoralf | Any objections? | 10:30 |
| thoralf | Seems to work. | 10:30 |
| thoralf | No more Parameter(Map) objects for each Label. | 10:31 |
| thoralf | Only 28 bytes overhead/label | 10:31 |
| besser82 | wiking: not really, if vpn is the way: just do it ;) | 10:40 |
| besser82 | wiking: I just prefer ssh, because it's less cpu-comsuming | 10:41 |
| besser82 | wiking: There is no other reason, against vpn. Just take the easier and working approach :D | 10:42 |
| besser82 | sonney2k_: I'm heading down to get the cmake stuff running with the protobuf-thing and the use-procompiled-shogun-lib | 10:43 |
| @wiking | besser82: i was looking into this and i've seen that we should create ShogunConfig.cmake and ShogunConfigVersion.cake | 10:43 |
| @wiking | *cmake | 10:44 |
| besser82 | sonney2k_: It simply took longer, because I got some unforeseen job to accomplish and stuff | 10:44 |
| besser82 | wiking: I know my approach uses some ShogunConfig.cmake, introduces shogun.pc and shogun_config.h | 10:44 |
| @wiking | besser82: we already have config.h | 10:45 |
| @wiking | maybe that needs fixing | 10:45 |
| besser82 | wiking: as far as I've seen, yes | 10:45 |
| besser82 | wiking: because there are lot of definitions passed by cmake to the compiler, which should be in config.h and used from there...# | 10:46 |
| @wiking | besser82: go ahead with fixess :P | 10:47 |
| besser82 | wiking: and that config.h which is actually generated, gets generated from some external script, like version.h | 10:47 |
| besser82 | wiking: which both should be generated when running cmake-configure-stage | 10:47 |
| besser82 | wiking: instead of `make all` | 10:48 |
| @wiking | not the version.h | 10:48 |
| besser82 | wiking: ??? | 10:48 |
| besser82 | wiking: what#s the problem with that? | 10:48 |
| besser82 | wiking: everything the autogen-script does can be done from cmake as well | 10:49 |
| @wiking | well version.h should be generated compile time | 10:49 |
| @wiking | and not configure time | 10:49 |
| besser82 | wiking: any special reason for that? | 10:49 |
| @wiking | well becasue the git rev version number can change | 10:50 |
| @wiking | after configure step | 10:50 |
| @wiking | obviously | 10:50 |
| @wiking | besser82: but this is already working like this in shogun | 10:50 |
| @wiking | so this is ok | 10:50 |
| @wiking | i mean version.h | 10:50 |
| besser82 | wiking: allright. | 10:51 |
| besser82 | wiking: but how the git-sha can change after configuring??? *confused* | 10:51 |
| @wiking | besser82: check this | 10:51 |
| @wiking | cmake/version.cmake | 10:51 |
| besser82 | wiking: will dive into... | 10:52 |
| -!- iglesiasg [~iglesiasg@s83-179-44-135.cust.tele2.se] has quit [Quit: Leaving] | 10:57 | |
| -!- iglesiasg [~iglesias@2001:6b0:1:1da0:d5d3:7e38:9901:108c] has joined #shogun | 12:52 | |
| -!- mode/#shogun [+o iglesiasg] by ChanServ | 12:52 | |
| @iglesiasg | hi thoralf | 12:52 |
| @iglesiasg | I had to run before so I didn't answer, sorry about that | 12:52 |
| @iglesiasg | thoralf, so at first sight what I see is that we would have to change the CDynamicObjectArray to a DynArray or so | 12:55 |
| @iglesiasg | but that should be fine | 12:55 |
| -!- sonne|osx [~sonne@f053047007.adsl.alicedsl.de] has joined #shogun | 13:17 | |
| @wiking | sonne|osx: bazinga | 13:18 |
| sonne|osx | wiking: good news everyone | 13:19 |
| sonne|osx | whats up? | 13:19 |
| @wiking | notmuhc | 13:21 |
| @wiking | w8ing for besser82 | 13:21 |
| thoralf | iglesiasg: I already replaced it by DynArray, but it's not that trivial because (1.) CDynamicObjectArray took care about SG_REF/UNREF | 13:26 |
| @iglesiasg | thoralf, does RefCount clean memory automatically? | 13:27 |
| thoralf | iglesiasg: and (2.) it seems that it's again consuming 5k/instance, but I need to check that. | 13:27 |
| @iglesiasg | thoralf, otherwise, what about using SGReferencedData instead | 13:27 |
| thoralf | iglesiasg: It does not. It's just a thread safe counter class. | 13:27 |
| thoralf | sonne|osx: Did you revert your changes? DynArray again allocates 5*1024 bytes for each label... | 13:37 |
| sonne|osx | thoralf: I understand why but now how to fix it - did it compile for you last time (buildbot was unhappy so I tried to do it differently but failed obviously) | 13:38 |
| thoralf | sonne|osx: you did something like "DynArray<xxx> foo(4);" -- my compiler complained, so I changed it locally to something like "DynArray<xxx> foo = DynArray<xxx>(4);", which worked well. | 13:41 |
| thoralf | I did this while watching a movie, so I didn't check in depth. | 13:42 |
| sonne|osx | thoralf: ahh ok then. maybe I should just do it this way then - or you do it if you have time now (search for set_granularity in the base/Param*.cpp) | 13:42 |
| thoralf | I'll try. | 13:46 |
| thoralf | set_granularity(int32_t g) | 13:46 |
| thoralf | g=CMath::max(g,128); | 13:46 |
| thoralf | LOL. | 13:46 |
| sonne|osx | huh? why that stupid limit? | 13:49 |
| sonne|osx | just drop it | 13:49 |
| sonne|osx | I mean 1 | 13:50 |
| sonne|osx | should be the limit | 13:50 |
| thoralf | Okay. | 13:51 |
| @iglesiasg | I think that a method to shrink the space is better than setting the granularity in Parameter | 13:53 |
| @iglesiasg | if for some reason in a Parameter object lot of elements are added to the list | 13:54 |
| @iglesiasg | it would be very slow if the granularity is that small | 13:54 |
| @wiking | heheh lol | 13:56 |
| @wiking | iglesiasg: have u read the mailinglist? | 13:56 |
| @iglesiasg | PrimalMosek? | 13:56 |
| @wiking | yeps | 13:56 |
| @wiking | i wonder wtf is happening there | 13:57 |
| @iglesiasg | not yet | 13:57 |
| @wiking | btw | 13:57 |
| @wiking | do we support svmlight input format -> SOSVM multiclass? | 13:57 |
| @iglesiasg | I haven't used that so AFAIK no | 13:57 |
| @iglesiasg | but it might be | 13:57 |
| thoralf | iglesiasg: I think we should talk about "preallocated size on construction" instead of granularity... | 14:03 |
| thoralf | iglesiasg: In most cases we either (a) need only small arrays or (b) we know in advance that it's going to be BIIIG. | 14:03 |
| @iglesiasg | thoralf, well not really | 14:04 |
| @iglesiasg | thoralf, that is the whole concept of dynamic arrays | 14:04 |
| @iglesiasg | thoralf, like dynamic resizing arrays. You can get amortized linear time insertion without even giving a preallocated size | 14:05 |
| thoralf | Can you achieve linear size by only resizing a fixed number of elements? | 14:06 |
| @iglesiasg | what I mean with this is that IMHO is OK to talk about granularity here | 14:06 |
| thoralf | Shouldn't something exponential happen wrt. the size happen? | 14:06 |
| @iglesiasg | thoralf, what? linear time you mean? | 14:06 |
| thoralf | iglesiasg: For having linear time, you need to multiply the array size. | 14:07 |
| @iglesiasg | yes | 14:07 |
| thoralf | But you're only adding K elements, for fixed K. | 14:07 |
| thoralf | So no linear time anyway. | 14:07 |
| @iglesiasg | So if this granularity is not set, it is just set to a constant value? | 14:08 |
| thoralf | 128 per default | 14:08 |
| thoralf | But this is not the point. | 14:08 |
| @iglesiasg | ok | 14:08 |
| @iglesiasg | what is it then? :) | 14:09 |
| thoralf | The point is: why something so expensive on every SGObject creation. | 14:09 |
| thoralf | The rest is only micro-optimization. | 14:09 |
| @iglesiasg | yes, that is true | 14:09 |
| @iglesiasg | probably Heiko has a good reason related to CV and model selection to use this Parameter attributes in SGObject | 14:09 |
| thoralf | Or the point might be: Why does StructuredData extend SGObject | 14:09 |
| @iglesiasg | I have nothing against making StructuredData not extend SGObject | 14:10 |
| thoralf | I tried it, but since serialization is encoded in the class name (CStructuredData), it makes a lot of pain to change this. | 14:11 |
| thoralf | And we're losing SG_REF/UNREF. | 14:12 |
| @iglesiasg | thoralf, I don't see the serialization point, let me check the code | 14:14 |
| thoralf | class_list.cpp.py | 14:15 |
| thoralf | Automagic stuff. | 14:15 |
| thoralf | class_list.cpp breaks as soon as you remove SGObject from StructData. | 14:15 |
| @iglesiasg | ok so pretty much the thing is that we cannot serialize CStructuredData if it is not SGObject | 14:15 |
| @iglesiasg | thoralf, so there are a couple of reasong to keep it as SGObject | 14:17 |
| @iglesiasg | thoralf, but the problem is that it takes too much memory | 14:17 |
| @iglesiasg | thoralf, what is the inconvenient with shrinking the memory used by the Parameter attributes in SGObject | 14:17 |
| @iglesiasg | I don't mean it to do *everywhere* | 14:17 |
| @iglesiasg | for instance, right now to me it seems reasonable to do it in the CStructuredData constructor | 14:18 |
| thoralf | The memory will be allocated by the default constructor of DynArray. | 14:19 |
| thoralf | So shrinking needs to realloc and eventually copy stuff around. | 14:19 |
| thoralf | I will commit something that initializes Parameter/ParameterMap with smaller sizes, as a hot-fix. | 14:20 |
| thoralf | 160 Bytes instead of 5KiB | 14:20 |
| @iglesiasg | ok | 14:20 |
| @iglesiasg | thoralf, out of curiosity, when "shrinking needs to realloc and eventually copy stuff around", is that overhead relevant? | 14:21 |
| thoralf | I think that (re)alloc is expensive and yields to memory fragmentation. But it's shouldn't be relevant. | 14:23 |
| thoralf | iglesiasg: Have a look: https://github.com/shogun-toolbox/shogun/pull/1762 | 14:23 |
| thoralf | sonne|osx as well | 14:23 |
| @iglesiasg | thoralf, yep, I opened it already. Looks good to me, let's see how does it looks for travis | 14:25 |
| thoralf | Note that I didn't change the default size. | 14:25 |
| thoralf | Only for usages within Parameter(Map). | 14:25 |
| -!- zxtx [~zv@c-98-193-83-24.hsd1.il.comcast.net] has quit [Ping timeout: 272 seconds] | 14:26 | |
| thoralf | Only 508 bytes per float now. :D | 14:26 |
| thoralf | total heap usage: 11,000,328 allocs, 11,000,328 frees, 508,034,974 bytes allocated | 14:27 |
| thoralf | 1M entries. | 14:27 |
| thoralf | So each label needs 11 (!) mallocs and uses 508 bytes. | 14:27 |
| @iglesiasg | thoralf, what labels are you exactly using btw? | 14:28 |
| thoralf | Multilabels | 14:28 |
| thoralf | Not yet committed. | 14:28 |
| @iglesiasg | what are they exactly? | 14:28 |
| @iglesiasg | a set of ints? | 14:28 |
| thoralf | A vector of {0,1}^K | 14:28 |
| thoralf | Formally. | 14:28 |
| @iglesiasg | all right | 14:28 |
| thoralf | Implemented as a set of ints. | 14:28 |
| thoralf | To make it sparse. :) | 14:28 |
| thoralf | to exploit sparsity | 14:29 |
| @iglesiasg | is your K large? | 14:29 |
| thoralf | 7000 | 14:29 |
| @iglesiasg | then it is good to make it sparse if labels are going to have to 1 just a few entries :) | 14:30 |
| @iglesiasg | good good | 14:30 |
| -!- shogun-notifier- [~irker@7nn.de] has joined #shogun | 15:04 | |
| shogun-notifier- | shogun: Thoralf Klein :develop * 72f0bb1 / src/shogun/base/ (3 files): https://github.com/shogun-toolbox/shogun/commit/72f0bb15699f5b5abb90e49b045b97580ce803a9 | 15:04 |
| shogun-notifier- | shogun: Fixed initialization of DynArray in Parameter/ParameterMap to get memory footprint small: | 15:04 |
| shogun-notifier- | shogun: DynArray will be instanciated 5 times for each SGObject (via Parameter/ParameterMap) | 15:04 |
| shogun-notifier- | shogun: which introduced a memory overhead of 5kb per instance. With this commit, the overhead | 15:04 |
| shogun-notifier- | shogun: should be reduced to 160 bytes. | 15:04 |
| shogun-notifier- | shogun: Fernando Iglesias :develop * fca253d / src/shogun/base/ (3 files): https://github.com/shogun-toolbox/shogun/commit/fca253db53149817a2fcdf5ba584d92366de11dd | 15:04 |
| shogun-notifier- | shogun: Merge pull request #1762 from tklein23/develop | 15:04 |
| shogun-notifier- | shogun: | 15:04 |
| shogun-notifier- | shogun: Fixed initialization of DynArray in Parameter/ParameterMap to reduce memory footprint | 15:04 |
| shogun-notifier- | shogun: Soeren Sonnenburg :develop * 22ba728 / src/shogun/base/DynArray.h: https://github.com/shogun-toolbox/shogun/commit/22ba728482a7adc4cef586e1b0cf84348a7ac900 | 15:05 |
| shogun-notifier- | shogun: 1 should be the lower bound | 15:05 |
| sonne|osx | thoralf: you could even use one - would make sense IMHO | 15:05 |
| sonne|osx | thoralf: I mean this is just done once for <10 parameters right so no reason to try to be fast | 15:06 |
| shogun-notifier- | shogun: Fernando Iglesias :develop * ba1a837 / src/shogun/base/DynArray.h: https://github.com/shogun-toolbox/shogun/commit/ba1a8375d55524f20d353c1ca333931aa38d0833 | 15:07 |
| shogun-notifier- | shogun: Set to 1 granulatity minimum threshold in DynArray::set_granularity | 15:07 |
| shogun-notifier- | shogun: Fernando Iglesias :develop * d8aab2f / : https://github.com/shogun-toolbox/shogun/commit/d8aab2fc464f0fc018aac9761d76404d13721555 | 15:07 |
| shogun-notifier- | shogun: Merge pull request #1763 from iglesias/develop | 15:07 |
| shogun-notifier- | shogun: | 15:07 |
| shogun-notifier- | shogun: Set to 1 granulatity minimum threshold in DynArray::set_granularity | 15:07 |
| thoralf | sonne|osx: Yeah, but the memory overhead for small memory chunks is quite big, so it usually makes no difference if you allocate 1 or 20 bytes. | 15:08 |
| sonne|osx | thoralf: it is still 3*8 bytes wasted * 4 | 15:10 |
| thoralf | Okay, let me check how many elements the array holds in average. ;) | 15:10 |
| thoralf | Micro-optimization done right[tm] ;) | 15:11 |
| sonne|osx | thoralf: why even try? I mean this is like 10 parameters / class max | 15:11 |
| sonne|osx | so I guess we usually have 0-2 parameters | 15:11 |
| sonne|osx | thoralf: but you know that the array is used here for convenience not optimization right? | 15:12 |
| sonne|osx | thoralf: so that one can do SG_ADD( some parameter) | 15:12 |
| sonne|osx | thoralf: anyway SGObjects are not small so one should not use them if you intend to have very little payload | 15:14 |
| sonne|osx | they are just not meant for that | 15:14 |
| sonne|osx | one should rather use aggregated data types | 15:14 |
| sonne|osx | I mean storing a real number as some CRealNumber is waste of resources | 15:15 |
| sonne|osx | CRealVector or CRealMatrix or whatever is what one should use | 15:15 |
| thoralf | sonne|osx: I'm not storing floats in StructuredData. It's complex labels, but even in my case the overhead exceeded the payload by many orders. | 15:16 |
| thoralf | complex as-in not-trivial | 15:16 |
| sonne|osx | then CSGObjects are not waht you want | 15:17 |
| thoralf | Btw., the average size of the DynArrays is 0 for StructuredData ;) | 15:17 |
| sonne|osx | they have 8 pointers several bools | 15:18 |
| sonne|osx | no size optimization at all | 15:18 |
| thoralf | sonne|osx: "then CSGObjects are not waht you want" <-- That's right, but as I was using the SO framework of iglesias, I didn't have a choice. | 15:18 |
| sonne|osx | so the right fix would be that StructuredData was not derived from SGObject | 15:19 |
| thoralf | Yes. | 15:19 |
| thoralf | I tried this, but it's not trivial. | 15:19 |
| sonne|osx | question is what of SGObject does it need | 15:19 |
| sonne|osx | iglesiasg: ? | 15:19 |
| thoralf | First, compiling class_list.cpp failed, but I blacklisted this. | 15:19 |
| @iglesiasg | I think only REF and UNREF is actually used | 15:19 |
| thoralf | Second, You have to care about REF/UNREF | 15:20 |
| @iglesiasg | and serialization too according to thoralf | 15:20 |
| thoralf | It helps te rename the classes and remove the "C". | 15:20 |
| thoralf | But still: Memory will not be freed automatically. | 15:21 |
| sonne|osx | iglesiasg: well then use delete instead of unref and good? or is this an object shared among variius places? | 15:21 |
| sonne|osx | thoralf: yes rule is - classes prefixed with C - are CSGObjects and will be serialized | 15:22 |
| sonne|osx | etc | 15:22 |
| @iglesiasg | sonne|osx, where I have used it it was not shared | 15:22 |
| sonne|osx | iglesiasg: so then easy fix right? | 15:22 |
| @iglesiasg | yes, I think so | 15:22 |
| shogun-buildbot_ | build #1962 of bsd1 - libshogun is complete: Failure [failed compile test] Build details are at http://buildbot.shogun-toolbox.org/builders/bsd1%20-%20libshogun/builds/1962 blamelist: Thoralf Klein <thoralf.klein@zib.de> | 15:22 |
| thoralf | iglesiasg: We have to take care a bit, since StructeredData is passed around in SO framework (argmax, etc.) | 15:24 |
| thoralf | But it should help to take care and run valgrind a few times. | 15:24 |
| sonne|osx | thoralf: I guess igleasias knows where it is initally set - in this object it has to be destroyed | 15:25 |
| @iglesiasg | it would basically be in the destruction of the labels | 15:26 |
| thoralf | Yes, I think so. | 15:26 |
| sonne|osx | iglesiasg, thoralf and when you set the object you have to delete the old one (make sure that the you do an init with NULL ...) | 15:29 |
| shogun-notifier- | shogun: Soeren Sonnenburg :develop * d52da29 / src/shogun/base/Parameter.cpp,src/shogun/base/ParameterMap.cpp: https://github.com/shogun-toolbox/shogun/commit/d52da29673ed829b285ebee0dc32062ce6951484 | 15:31 |
| shogun-notifier- | shogun: use 1 even | 15:31 |
| thoralf | Damn. I just prepared a PR for this. ;) | 15:33 |
| shogun-buildbot_ | build #1963 of bsd1 - libshogun is complete: Failure [failed compile test] Build details are at http://buildbot.shogun-toolbox.org/builders/bsd1%20-%20libshogun/builds/1963 blamelist: Soeren Sonnenburg <sonne@debian.org>, Fernando Iglesias <fernando.iglesiasg@gmail.com> | 15:38 |
| -!- hushell [~hushell@c-50-188-141-210.hsd1.or.comcast.net] has quit [Ping timeout: 248 seconds] | 15:41 | |
| @wiking | is there a fast way i can do Sparsefeatures->DenseFeatureS? | 15:47 |
| -!- thoralf [~thoralf@enki.zib.de] has quit [Quit: Konversation terminated!] | 15:50 | |
| -!- thoralf [~thoralf@enki.zib.de] has joined #shogun | 15:50 | |
| -!- iglesiasg [~iglesias@2001:6b0:1:1da0:d5d3:7e38:9901:108c] has quit [Quit: Ex-Chat] | 15:58 | |
| @wiking | we dont have a from_sparse(SGSparseMatrix) converter in SGMatrix :S | 16:00 |
| -!- FSCV [~FSCV@201.161.7.110] has joined #shogun | 16:05 | |
| -!- lisitsyn [~lisitsin@mxs.kg.ru] has quit [Quit: Leaving.] | 16:09 | |
| sonne|osx | wiking: do we have one in CDenseFeatures? | 16:48 |
| sonne|osx | wiking: actually I guess only the other way round | 16:49 |
| @wiking | noup | 16:49 |
| @wiking | yes in indeed only one way | 16:49 |
| sonne|osx | wiking: well sparse -> dense is very easy :) | 16:49 |
| @wiking | heheh indeed | 16:50 |
| @wiking | nevermind | 16:50 |
| @wiking | i could use sparsefeatures | 16:50 |
| @wiking | so it was ok | 16:50 |
| sonne|osx | thoralf: we really should do the structureddata change | 16:50 |
| thoralf | sonne|osx: Of course. Do you have an agenda for this? | 16:53 |
| shogun-buildbot_ | build #124 of clang34 - undefined behaviour analysis is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/clang34%20-%20undefined%20behaviour%20analysis/builds/124 blamelist: Thoralf Klein <thoralf.klein@zib.de> | 16:55 |
| shogun-buildbot_ | build #1964 of bsd1 - libshogun is complete: Failure [failed compile test] Build details are at http://buildbot.shogun-toolbox.org/builders/bsd1%20-%20libshogun/builds/1964 blamelist: Soeren Sonnenburg <sonne@debian.org> | 16:55 |
| sonne|osx | thoralf: agenda is you do it and I review the stuff :) I would prefer fixing cmake & protbuf | 16:56 |
| thoralf | Ehrm. ;) | 16:57 |
| thoralf | sonne|osx: What's the exact plan for this? Removing base class SGObject from structured stuff. Renaming subclasses so that they don't start with C (otherwise class_list.cpp will fail). Replacing all SG_UNREF on labels by delete. | 16:58 |
| thoralf | Anything else? | 16:59 |
| thoralf | Any expected side effects? | 16:59 |
| sonne|osx | thoralf: and init the data with NULL in labels and also free it before the setter is doing the set | 16:59 |
| sonne|osx | no side effects if this is really only *internal* data | 17:00 |
| sonne|osx | it cannot be exposed to e.g. python modular or so (otherwise ref/unref needs to work) | 17:00 |
| shogun-buildbot_ | build #335 of FCRH - libshogun is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/FCRH%20-%20libshogun/builds/335 blamelist: Soeren Sonnenburg <sonne@debian.org> | 17:03 |
| shogun-buildbot_ | build #122 of clang34 - thread analysis is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/clang34%20-%20thread%20analysis/builds/122 blamelist: Thoralf Klein <thoralf.klein@zib.de> | 17:20 |
| thoralf | sonne|osx: We somehow broke serialization ^ | 17:22 |
| sonne|osx | thoralf: you mean bug in DynArray with granularity 1? | 17:24 |
| sonne|osx | don't see it yet though | 17:25 |
| thoralf | http://buildbot.shogun-toolbox.org/builders/clang34%20-%20thread%20analysis/builds/122/steps/test/logs/stdio | 17:25 |
| thoralf | No, DynArray and tests are work locally. Seems to be build-system related. | 17:30 |
| sonne|osx | nah these are not really tests | 17:36 |
| -!- Saurabh7 [~Saurabh7@115.248.130.148] has joined #shogun | 17:51 | |
| shogun-buildbot_ | build #141 of clang34 - static analysis is complete: Failure [failed analyse] Build details are at http://buildbot.shogun-toolbox.org/builders/clang34%20-%20static%20analysis/builds/141 blamelist: Thoralf Klein <thoralf.klein@zib.de> | 18:04 |
| @wiking | lol | 18:06 |
| @wiking | http://stackoverflow.com/questions/20122267/ifinite-was-not-declared-in-this-scope | 18:06 |
| @wiking | stackoverflow :) | 18:06 |
| @wiking | afaik we should really do something about | 18:06 |
| @wiking | cmath and math.h | 18:06 |
| @wiking | and btw: | 18:07 |
| @wiking | Math.h:1257:11: warning: 'finite' is deprecated: first deprecated in OS X 10.9 [-Wdeprecated-declarations] | 18:07 |
| @wiking | return finite(f); | 18:07 |
| @wiking | ^ | 18:07 |
| @wiking | /usr/include/math.h:718:12: note: 'finite' declared here | 18:07 |
| @wiking | extern int finite(double) __OSX_AVAILABLE_BUT_DEPRECATED(__MAC_10_0, __MAC_10_9, __IPHONE_NA, __IPHONE_NA); | 18:07 |
| -!- thoralf [~thoralf@enki.zib.de] has quit [Quit: Konversation terminated!] | 18:13 | |
| shogun-buildbot_ | build #125 of clang34 - undefined behaviour analysis is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/clang34%20-%20undefined%20behaviour%20analysis/builds/125 blamelist: Soeren Sonnenburg <sonne@debian.org>, Fernando Iglesias <fernando.iglesiasg@gmail.com> | 18:15 |
| @wiking | fyi we have some sorts of memory leak in ./tests/unit/unit-SGObject | 18:16 |
| -!- lisitsyn1 [~lisitsyn@80.252.20.67] has joined #shogun | 18:21 | |
| shogun-buildbot_ | build #123 of clang34 - thread analysis is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/clang34%20-%20thread%20analysis/builds/123 blamelist: Soeren Sonnenburg <sonne@debian.org>, Fernando Iglesias <fernando.iglesiasg@gmail.com> | 18:30 |
| -!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout] | 18:31 | |
| @wiking | sonne|osx: ping. | 18:53 |
| @wiking | sonne|osx: is it ok if i change inline static int is_finite(double f) | 18:53 |
| @wiking | to static int is_finite(double f) | 18:53 |
| @wiking | just as like static int is_infinity(double f); | 18:54 |
| @wiking | ? | 18:54 |
| shogun-buildbot_ | build #142 of clang34 - static analysis is complete: Failure [failed analyse] Build details are at http://buildbot.shogun-toolbox.org/builders/clang34%20-%20static%20analysis/builds/142 blamelist: Soeren Sonnenburg <sonne@debian.org>, Fernando Iglesias <fernando.iglesiasg@gmail.com> | 19:13 |
| -!- FSCV [~FSCV@201.161.7.110] has quit [Quit: Leaving] | 19:30 | |
| @wiking | btw anybody here knows how to generate that stupid mex file for matlab static interface? | 19:33 |
| shogun-buildbot_ | build #126 of clang34 - undefined behaviour analysis is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/clang34%20-%20undefined%20behaviour%20analysis/builds/126 blamelist: Soeren Sonnenburg <sonne@debian.org> | 19:34 |
| sonne|osx | wiking: try mex | 19:43 |
| sonne|osx | wiking: this is_finite stuff worked already with configure no idea how to scan for it with cmake | 19:45 |
| @wiking | sonne|osx: is it ok if i do it like that? | 19:45 |
| @wiking | inline -> static? | 19:45 |
| sonne|osx | wiking: sure | 19:46 |
| sonne|osx | wiking: wow - many people with the ifinite issue :D | 19:46 |
| sonne|osx | and all trying to fix it?! | 19:46 |
| sonne|osx | oopsi | 19:46 |
| sonne|osx | there is a typo | 19:46 |
| sonne|osx | ifinite(f); -> isfinite(f) | 19:46 |
| sonne|osx | hmmh | 19:48 |
| sonne|osx | we don't have ifinite in the code | 19:48 |
| sonne|osx | something weird is going on there... | 19:48 |
| shogun-buildbot_ | build #124 of clang34 - thread analysis is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/clang34%20-%20thread%20analysis/builds/124 blamelist: Soeren Sonnenburg <sonne@debian.org> | 19:49 |
| sonne|osx | doesn't look like it is our fault | 19:51 |
| @wiking | sonne|osx: here | 19:52 |
| @wiking | check this patch | 19:52 |
| -!- shogun-notifier- [~irker@7nn.de] has joined #shogun | 19:53 | |
| shogun-notifier- | shogun: Viktor Gal :develop * 17babf2 / / (5 files): https://github.com/shogun-toolbox/shogun/commit/17babf2deb5c022396d0503a48d7e7de93b02fc6 | 19:53 |
| shogun-notifier- | shogun: Refactor is_nan, is_infinity and is_finite in CMath | 19:53 |
| shogun-notifier- | shogun: Disable ProtoBuf detection | 19:53 |
| @wiking | sonne|osx: soon we should do a hotfix release | 20:07 |
| shogun-buildbot_ | build #143 of clang34 - static analysis is complete: Failure [failed analyse] Build details are at http://buildbot.shogun-toolbox.org/builders/clang34%20-%20static%20analysis/builds/143 blamelist: Soeren Sonnenburg <sonne@debian.org> | 20:35 |
| shogun-buildbot_ | build #1685 of cyg1 - libshogun is complete: Failure [failed configure] Build details are at http://buildbot.shogun-toolbox.org/builders/cyg1%20-%20libshogun/builds/1685 blamelist: Viktor Gal <viktor.gal@maeth.com> | 20:40 |
| shogun-buildbot_ | build #1965 of bsd1 - libshogun is complete: Failure [failed compile test] Build details are at http://buildbot.shogun-toolbox.org/builders/bsd1%20-%20libshogun/builds/1965 blamelist: Viktor Gal <viktor.gal@maeth.com> | 20:43 |
| @wiking | doh | 20:47 |
| @wiking | /usr/local/bin/ld: CMakeFiles/libshogun.dir/ui/GUIPluginEstimate.cpp.o: relocation R_X86_64_32S against `vtable for shogun::CGUIPluginEstimate' can not be used when making a shared object; recompile with -fPIC | 20:47 |
| @wiking | freebsd :S | 20:47 |
| @wiking | fpic detection is not working | 20:47 |
| -!- hushell [~hushell@c-50-188-141-210.hsd1.or.comcast.net] has joined #shogun | 20:52 | |
| shogun-buildbot_ | build #336 of FCRH - libshogun is complete: Success [build successful] Build details are at http://buildbot.shogun-toolbox.org/builders/FCRH%20-%20libshogun/builds/336 | 21:10 |
| -!- zxtx [~zv@ool-2f110054.dyn.optonline.net] has joined #shogun | 21:26 | |
| shogun-notifier- | shogun: Viktor Gal :develop * ad0f48e / CMakeLists.txt: https://github.com/shogun-toolbox/shogun/commit/ad0f48e150072e2236ab5ea0b6620014c7e33edc | 21:35 |
| shogun-notifier- | shogun: Include CheckCXXSourceCompiles in CMakeLists.txt | 21:35 |
| shogun-buildbot_ | build #1966 of bsd1 - libshogun is complete: Failure [failed compile test] Build details are at http://buildbot.shogun-toolbox.org/builders/bsd1%20-%20libshogun/builds/1966 blamelist: Viktor Gal <viktor.gal@maeth.com> | 22:01 |
| shogun-buildbot_ | build #127 of clang34 - undefined behaviour analysis is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/clang34%20-%20undefined%20behaviour%20analysis/builds/127 blamelist: Viktor Gal <viktor.gal@maeth.com> | 22:01 |
| -!- iglesiasg [~iglesiasg@s83-179-44-135.cust.tele2.se] has joined #shogun | 22:07 | |
| -!- mode/#shogun [+o iglesiasg] by ChanServ | 22:07 | |
| shogun-buildbot_ | build #343 of FC19 - libshogun is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/FC19%20-%20libshogun/builds/343 blamelist: Viktor Gal <viktor.gal@maeth.com> | 22:09 |
| shogun-buildbot_ | build #125 of clang34 - thread analysis is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/clang34%20-%20thread%20analysis/builds/125 blamelist: Viktor Gal <viktor.gal@maeth.com> | 22:26 |
| shogun-notifier- | shogun: Viktor Gal :develop * 66d819f / src/shogun/structure/CCSOSVM.cpp,src/shogun/structure/CCSOSVM.h: https://github.com/shogun-toolbox/shogun/commit/66d819f1bbd3649cb2afbcdc28c0e45ba48a5aaa | 22:38 |
| shogun-notifier- | shogun: Small refactoring of CCSOSVM | 22:38 |
| sonne|osx | wiking: what is the issue with is_nan etc? it was all working OK before we switched to cmake?! | 22:38 |
| sonne|osx | wiking: ahh cool nice checks | 22:39 |
| sonne|osx | wiking: you should just merge that and then we see if the cygwin bot is happy or not | 22:40 |
| @wiking | we'll see now what happens with cygwin | 22:41 |
| @wiking | sonne|osx: there was nothing wrong with is_nan just made it a bit more portable | 22:42 |
| * wiking has a hunch that some basic mathematical function is being broken atm... | 22:42 | |
| @wiking | that's why ccsosvm not working anymore | 22:42 |
| sonne|osx | wiking: if you had tests :P | 22:43 |
| @wiking | sonne|osx: mosek based...so wouldnt have helped | 22:43 |
| sonne|osx | so useless stuff anyway | 22:44 |
| @wiking | we should have unittest for sparse_dot... | 22:44 |
| @wiking | wtf is this that there's no gettimeofday | 22:56 |
| sonne|osx | woa | 22:56 |
| sonne|osx | that is the seed for the rng | 22:56 |
| @wiking | sonne|osx: heiko style | 22:58 |
| shogun-buildbot_ | build #1686 of cyg1 - libshogun is complete: Success [build successful] Build details are at http://buildbot.shogun-toolbox.org/builders/cyg1%20-%20libshogun/builds/1686 | 22:59 |
| sonne|osx | wiking: well we could fall back to time() if getttimeofday is not available | 22:59 |
| sonne|osx | so cyg is happy | 22:59 |
| @wiking | noup | 22:59 |
| @wiking | Never use time() to initialize srand() | 22:59 |
| @wiking | google for this | 22:59 |
| sonne|osx | why not | 23:00 |
| sonne|osx | I mean we have the pid and other stuff mixed in too | 23:00 |
| @wiking | read the article | 23:01 |
| sonne|osx | wiking: no good enough as a fall back - at least some randomness | 23:01 |
| @wiking | sonne|osx: /dev/urandom | 23:02 |
| @wiking | sonne|osx: dunno what could be on non UNIX stuff | 23:03 |
| sonne|osx | you mean non-linux | 23:03 |
| sonne|osx | no lets not optimize for weird platforms | 23:03 |
| sonne|osx | lets just use time | 23:04 |
| @wiking | sonne|osx: let's not | 23:04 |
| @wiking | /dev/urandom is totaly unix | 23:04 |
| @wiking | urandom is available in any normal unix system | 23:04 |
| sonne|osx | wiking: any unix has gettimeofday so /dev/urandom doesn't help at all | 23:04 |
| @wiking | that is not from 1980s | 23:05 |
| @wiking | sonne|osx: yes it doesn | 23:05 |
| @wiking | gettimeofday and like | 23:05 |
| @wiking | is a very bad way to seed a prng | 23:05 |
| @wiking | as there's a high probabilyt | 23:05 |
| @wiking | that it makes totaly not rng | 23:05 |
| sonne|osx | sure but it is just a seed | 23:05 |
| @wiking | so the whole purpose of PRNG is just being | 23:05 |
| @wiking | sonne|osx: yes that's why it's Prng | 23:06 |
| @wiking | and not RNG | 23:06 |
| @wiking | w/o a good seed | 23:06 |
| @wiking | no good random is possible | 23:06 |
| @wiking | with any prng | 23:06 |
| sonne|osx | otherwise you would use /dev/random all the time | 23:06 |
| @wiking | sonne|osx: no | 23:06 |
| sonne|osx | and wait 20 seconds to get another integer | 23:06 |
| @wiking | sonne|osx: because u want Prng | 23:06 |
| @wiking | meaning u wanna be able to have 'states' | 23:06 |
| -!- sonne|osx [~sonne@f053047007.adsl.alicedsl.de] has quit [Quit: sonne|osx] | 23:08 | |
| shogun-buildbot_ | build #144 of clang34 - static analysis is complete: Failure [failed analyse] Build details are at http://buildbot.shogun-toolbox.org/builders/clang34%20-%20static%20analysis/builds/144 blamelist: Viktor Gal <viktor.gal@maeth.com> | 23:10 |
| -!- hushell [~hushell@c-50-188-141-210.hsd1.or.comcast.net] has quit [Ping timeout: 272 seconds] | 23:24 | |
| -!- travis-ci [~travis-ci@ec2-23-20-94-251.compute-1.amazonaws.com] has joined #shogun | 23:34 | |
| travis-ci | [travis-ci] it's Fernando Iglesias's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: http://travis-ci.org/shogun-toolbox/shogun/builds/14312348 | 23:34 |
| -!- travis-ci [~travis-ci@ec2-23-20-94-251.compute-1.amazonaws.com] has left #shogun [] | 23:34 | |
| shogun-buildbot_ | build #1967 of bsd1 - libshogun is complete: Failure [failed compile test] Build details are at http://buildbot.shogun-toolbox.org/builders/bsd1%20-%20libshogun/builds/1967 blamelist: Viktor Gal <viktor.gal@maeth.com> | 23:45 |
| -!- Saurabh7 [~Saurabh7@115.248.130.148] has quit [Ping timeout: 264 seconds] | 23:47 | |
| shogun-buildbot_ | build #128 of clang34 - undefined behaviour analysis is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/clang34%20-%20undefined%20behaviour%20analysis/builds/128 blamelist: Viktor Gal <viktor.gal@maeth.com> | 23:49 |
| shogun-buildbot_ | build #344 of FC19 - libshogun is complete: Success [build successful] Build details are at http://buildbot.shogun-toolbox.org/builders/FC19%20-%20libshogun/builds/344 | 23:54 |
| -!- hushell [~hushell@8-12.ptpg.oregonstate.edu] has joined #shogun | 23:58 | |
| --- Log closed Fri Nov 22 00:00:35 2013 | ||
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!