13:56 < mentekid> rcurtin: I haven't gotten around to dealing with the removal of omp.h yet, but I've been thinking about it. I have some questions related to it

13:57 < mentekid> a) Should I just add #include <omp.h> to core.hpp? There is a header defined in openMP so we can know when it is included, but how do I tell the compiler "try to include this, if you fail, ignore it?" is there such possibility?

13:59 < mentekid> b) If I don't include omp.h, I can create some helper functions like NumThreads() and NumCores() that monitor and control core use, that way I can avoid the calls to omp functions. But will the parallelization happen this way?

13:59 < mentekid> I mean, doesn't the compiler need omp.h to recognize the #pragmas?

14:09 < mentekid> what I was thinking was, maybe create our own omp.h file and put it (I don't know how but there should be a way) low in the priority. That way, if a "system" omp.h (the actual openMP) is found, we use that one, but if it isn't, we use our own where we simply do a #define omp_not_included or something

14:16 < zoq> mentekid. The OpenMP macros e.g. '#pragma omp' are intrusive and safely skipped when OpenMP is not activated. About including "omp.h", you could add add_definitions(-DHAS_OPENMP) to the CMakeLists.txt once OPENMP_FOUND is true. That way you can add '#ifdef HAS_OPENMP #include <opm.h> #endif ' in core to include 'opm.h' if the system supports OpenMP.

14:17 < mentekid> ah perfect! Thanks I didn't know that :)

14:26 < zoq> Do you need NumThreads() or could you also just use '#pragma omp parallel for', I guess, it could be somewhat ugly if you check HAS_OPENMP to get the number of threads, so maybe defining a default NumThreads() function would make sense.

15:31 < rcurtin> I was hpping that all of the OprnMP code cpuld be done with pragmas but I have not had a chance to research it further yet

15:31 < rcurtin> *OpenMP, *could... phone typing is hard :)

15:31 < rcurtin> I think that a lot of the behavior of OpenMP can be controlled with environment variables

15:32 < rcurtin> so possibly any checks to NumThreads() or anything like that are unnecessary

15:32 < rcurtin> hopefully I will have a chance to look further tonight and figure it out

16:02 < zoq> ilay: I looked into the feature extraction part, and used the latest version from your fork, but I encountered a problem when running the example ... segmentation fault. Before I take a closer look, maybe you can help me here, should I use another version, or should I modify the data somehow?

16:02 < zoq> *nilay

16:23 < nilay> zoq: it works in my system, did you use the fm branch?

16:23 < nilay> i'll try running it again

16:23 < zoq> nilay: yes

16:23 < nilay> and let you know

16:24 < zoq> okay, thanks

16:26 < nilay> it works on the remote

16:26 < nilay> and there is nothing to commit also

16:26 < nilay> it'll only run with arma 7.2

16:27 < nilay> i'll change that index_min() function today, other than that there is nothing to commit also

16:27 < nilay> i am running the executable bin/mlpack_edge_boxes

16:27 < zoq> hm, okay, I have written a simple index_max function, maybe I missed something

16:28 < nilay> maybe that function you have to check then

16:29 < nilay> or could it be anything weird?

16:31 < zoq> not sure, I'll go and take a closer look, just wanted to check if you think I missed something

16:32 < nilay> do you want me to do anything before you take a look?

16:34 < zoq> If you like, you can incorporate the index_min function.

16:35 < nilay> ok i'll go ahead and do that

17:04 < nilay> zoq: can you check now, thanks.

17:19 < zoq> nilay: Thanks!

17:27 < nilay> zoq: what are you checking with the hoeffedding tree and discretize function. Is there anything i can do

17:35 < zoq> nilay: I already modified the Train() function of the hoeffding tree, one thing left is to incorporate the mapping function. Since you said it's kinda slow, I wanted to check if we could do something to make it faster. I'm trying to finish the modification in the next days.

17:35 < zoq> Do you made progress with the inception layer, do you need any help?

17:39 < nilay> zoq: uptil now, i have only did reading.

17:41 < nilay> i still have one chapter left. i'll implement from tomorrow

17:41 < zoq> Ah, great, I really like the idea of using a 1x1 convolution to reduce the kernel dimension, it's pretty neat and it's so simple.

17:42 < nilay> yes, i understood that now, finally :)

17:43 < nilay> we reduce the dimension of input, not the kernel?

17:43 < zoq> right, my fault

17:45 < zoq> Have you seen the GoogLeNet presentation? It's pretty funny: https://www.youtube.com/watch?v=ySrj_G5gHWI

17:46 < nilay> yes, i did, that was before i wrote the proposal. :)

17:47 < zoq> The results are pretty amazing, you can even challenge yourself: http://cs.stanford.edu/people/karpathy/ilsvrc/

17:50 < nilay> this is nice. but difficult to play, can't see 1000 objects for one guess :)

17:53 < nilay> or even see 10 objects.

17:53 < zoq> yeah :)

17:56 < nilay> you do work on these things in your Phd also? that should be very interesting.

18:25 < zoq> I agree it's very interesting, although I don't particular work on convolutional neural networks

18:30 < nilay> oh, ok

19:42 < marcosirc> zoq: Hi, how are you?!

19:42 < marcosirc> I have implemented a new view for the benchmarking system

19:43 < marcosirc> http://marcospividori.github.io/mlpack-app/

19:43 < marcosirc> I will make a pull request if you agree.a

19:44 < zoq> marcosirc: Hello, sure go ahead, the view looks great.

19:45 < marcosirc> Thanks!

19:49 < zoq> marcosirc: Is this the actual data for mlpack, flann and ann?

19:53 < marcosirc> yes

19:53 < marcosirc> zoq: I have run it on my machine.

19:54 < marcosirc> We should do more test with bigger datasets

19:56 < marcosirc> Maybe using jenkins? Other datasets like: 1000000-10-randu.csv, tinyImages100k.csv, etc require too much time..

20:12 < zoq> yeah, I agree, we should update the results, I guess you also updated the config.yaml

20:20 < marcosirc> zoq: I haven't updated the config.yaml file.

20:20 < marcosirc> Do you want me to include all that cases for different values of epsilon?

20:22 < zoq> marcosirc: That would be great, that would make things a lot easier.

20:22 < marcosirc> Ok, no problem. I have been using a separated config file. I will include that in the main config.yaml file.

20:23 < zoq> great, thanks!

20:29 < marcosirc> zoq: done!

20:37 < zoq> marcosirc: Perfect, thanks again; I'll take a look at the PR tomorrow.

20:38 < marcosirc> zoq: Ok, great!