04:10 < jeffin143> Sreenik

04:10 < jeffin143> Didn't order for one ,

04:11 < jeffin143> Will do so , after I make some space on my laptops :) for mlpack stickers

06:07 < Suryo> zoq: For some of the new test functions, I was trying to condense the functional forms of the gradients by using aliases for expressions that are repeated for the gradients of different variables. Also, I thought that the aliases could help prevent repeated computations. But for the GoldsteinPrice Function, the number of such aliases became too many so I resorted to code the entire expressions for the gradients. Hope that's okay.

06:08 < Suryo> Also, I've seen your comments on using CMAES and CNE for testing the non-differentiable functions. I'll test them accordingly.

06:08 < Suryo> Thanks

06:27 < jeffin143> rcurtin , zoq : strange enough I used grep and found out that we haven't used PARAM_VECTOR_IN and PARAM_VECTOR_OUT anywhere

06:27 < jeffin143> So here is my results of many trials and error that I did today morning

06:28 < jeffin143> Saw the definition of PARAM_VECTOR_IN and found out that , it's define as vector<t> and hence may take any type, therefor declare a test class* with some datatypes * and then tried passing that

06:29 < jeffin143> Threw some big 15 pages of error , after going through some of those , understood we have to overlood << and >> operator and did that and successfully compiled

06:30 < jeffin143> But the only issue is take input from command line, -v = 1,2,3 throws error saying (=) is invalid argument

06:30 < jeffin143> So I decide to make a vector of int and tried taking input from command line , and that is also throwing error

06:31 < jeffin143> Used something as --vec = 1,2 ,3 after going through the documentation at website. but I am sure there is some error in that

07:13 < toshal> ShikharJ: No I didn't got them. I have sent the mail quite a lot before. Frankly speaking I don't trust our post mail service.

07:52 < jenkins-mlpack2> Project docker mlpack nightly build build #343: STILL UNSTABLE in 3 hr 38 min: http://ci.mlpack.org/job/docker%20mlpack%20nightly%20build/343/

11:48 < zoq> Suryo: Sure, no problem, it can be difficult to create an easy to read expression.

11:51 < zoq> toshal: We can give it another shot.

11:52 < zoq> jeffin143: PARAM_VECTOR_IN is used in a test function here: https://github.com/mlpack/mlpack/blob/2326bf8bd0b380c17eed6b5b1c34fbfab1563774/src/mlpack/tests/cli_test.cpp#L181

11:53 < zoq> you have to repeat the key --vec 1 --vec 2 --vec 3

12:32 < KimSangYeon-DGU> sumedhghaisas_: Hey Sumedh, I figured out the QGMM python code uses radian, not degree when calculating the cos(phi), so I edited it accordingly.

12:33 < KimSangYeon-DGU> sumedhghaisas_: As a result, we can see the interference phenomena. you can check it at https://github.com/KimSangYeon-DGU/GSoC-2019/blob/master/Research/Probability_Space/README.md

12:33 < KimSangYeon-DGU> I updated our research repository

12:34 < KimSangYeon-DGU> The two distributions look different totally.

12:34 < KimSangYeon-DGU> as we expected

12:37 < KimSangYeon-DGU> Currently, I'm struggling to find the method to integrate the probability space.

16:12 < favre49> rcurtin: zoq: Is it possible to have a config file to specify the parameters of NEAT? Something like https://github.com/CodeReclaimers/neat-python/blob/master/examples/xor/config-feedforward

16:12 < favre49> Unless we decide to make certain things hard coded or the mutation probabilities the same, the constructors might turn very large.

16:13 < favre49> Of course i could assign default values and the user could use setter functions to change them, this is just a design question of what would be better

16:14 < favre49> It seems more user friendly, but it hasn't been used anywhere else in mlpack and there's probably a reason for that.

16:14 < zoq> favre49: Yeah, we could do that, but I guess for now I would just go with hardcoded settings.

16:15 < favre49> zoq: Alright thanks :)

16:16 < zoq> We could use the serialization feature to achive something like that which would allow us to save/load the model as txt,xml, etc.

16:20 < favre49> yup i was thinking that as well, I'm gonna work on getting it basically working first though.

16:24 < zoq> right, I was thinking the same

18:19 < akhandait> sreenik: Hey, sorry I am quite late.

18:23 < sreenik> akhandait: Hi

18:23 < akhandait> Okay, so let's start.

18:23 < sreenik> Yes

18:24 < akhandait> Did you make any progress with the onnx C++ API after that problem was solved?

18:25 < sreenik> Yes, I extracted the layers, attributes and values and am mapping them to the corresponding mlpack layer attributes now

18:26 < sreenik> I tried extracting the weights but have still not been able to. It was easy with python, perhaps some digging into protobuf is needed for doing this in c++

18:26 < sreenik> One thing that is a concern is that there are quite a few simple layer types not implemented n mlpack

18:26 < sreenik> Like say logsoftmax is there but no softmax

18:27 < akhandait> Hmm, okay

18:27 < sreenik> Then, the LRN layer is not there yet, which is present in the alexnet model. These are not my top concerns but these need to be addressed as well

18:28 < zoq> We could add a Softmax layer, but I think LogSoftmax is what people often use anyway.

18:29 < akhandait> zoq: Yeah, I am not sure it will be useful having just Softmax when we already have LogSoftmax

18:29 < sreenik> zoq: You are right but sadly the pretrained models in the onnx zoo have softmax all over. But adding one wouldn't be much of issue since logsoftmax is already there

18:30 < zoq> I see, I guess if we like to reuse some of thise models, it makes sense to implement softmax?

18:30 < akhandait> sreenik: I think we should build a simple onnx trained model with basic layers like Linear which we have right now

18:31 < akhandait> to at least test our framework

18:31 < sreenik> atharva: Okay that is reasonable

18:31 < zoq> That sounds like a good idea to me as well.

18:32 < sreenik> Yes I will try linear, sigmoid, relu and then move on to convolutions then?

18:33 < akhandait> Sounds good, once the basic framework is set and tested for a simple model with linear, sigmoid, relu, etc. adding more layers which we have in mlpack should not be difficult

18:33 < sreenik> Right

18:33 < akhandait> What is the problem with protobuf you said you were facing?

18:34 < sreenik> Can't really seem to extract the weights from a TensorProto object

18:35 < sreenik> There are fields like "int", "float", etc. which do not contain the value

18:35 < akhandait> Is it compiling? Or is it some extension of the same issue we were facing that day?

18:35 < akhandait> sreenik: Oh, okay

18:35 < sreenik> Along with another field called "raw_data" which actually has the value but in the form of a byte stream

18:36 < sreenik> So it has to be converted

18:36 < akhandait> Okay, what ways have you thought of to do that?

18:37 < sreenik> The python implementation has an implementation to directly convert using a function call. Will dig deep into that.

18:38 < akhandait> Cool

18:38 < sreenik> I am currently focussing to the layer conversion from onnx to mlpack which we were discussing earlier. Once that is done I will try to solve this

18:38 < sreenik> *on the

18:39 < akhandait> Any other issues? If not we could move on to discuss the timeline

18:39 < sreenik> No other issues right now

18:39 < akhandait> sreenik: Okay

18:40 < akhandait> sreenik: About that PR, I guess we will need that in a while

18:40 < akhandait> I will try and review it in a couple days.

18:40 < sreenik> That is done for now. WIll modify it as and when needed (I don't see a need right now)

18:41 < akhandait> Sure.

18:41 < akhandait> Now coming to the timeline, I guess we are a little behind right now.

18:42 < sreenik> Yes

18:43 < sreenik> It needs a little modification

18:44 < akhandait> akhandait: Yeah, can you make a google doc and just copy paste this timeline?

18:44 < akhandait> So that we can make changes as needed

18:44 < sreenik> Ya sure that will be of help to us

18:45 < akhandait> Let's set the tasks for the next week, till 9th that is.

18:46 < akhandait> What do you think is a reasonable goal for next week?

18:47 < sreenik> Completing the mapping along with..

18:47 < sreenik> Weight extraction and transferring the weights to the corresponding mlpack model

18:48 < akhandait> Okay, sounds good

18:48 < sreenik> Basically create the onnx to mlpack convertor and maybe test it with some simple models

18:48 < akhandait> Yes

18:49 < sreenik> If you see the original timeline it is actually somewhat in line with it (since I had kept an entire week to test it with small models)

18:50 < akhandait> akhandait: I saw that just now, that will give us some breathing space.

18:51 < akhandait> I think for now, some things which you had mentioned like the RNN functionality for the parser can be kept aside

18:51 < sreenik> Yes that is not reasonable to invest time in right now

18:53 < akhandait> So, I think that's it for now then.

18:54 < sreenik> Yup, will communicate with you over anything else through hangouts or here if required

18:54 < akhandait> Sure, good night!

18:54 < sreenik> Good night :)

23:19 < Suryo> zoq: For my PR #117, the Travis build isn't running, IDK why.

23:20 < Suryo> zoq, rcurtin: would it be okay to test all the test functions using CNE? As of now, I have only tested three of them that are non-differentiable. I had to select initial points that are 'appropriately close' to the global solutions, otherwise, the solution points were getting stuck in local minima, it seems :(

23:21 < Suryo> Let me know. Based on that, I'll wrap up the test development. I'm almost done, except for style fixes, etc. Then I'll resume development of PSO :)