ChanServ changed the topic of #mlpack to: "mlpack: a fast, flexible machine learning library :: We don't always respond instantly, but we will respond; please be patient :: Logs at http://www.mlpack.org/irc/
jeffin143 has quit [Remote host closed the connection]
< ShikharJ> zoq: Did you get a chance to take a look at https://github.com/mlpack/mlpack/pull/1761 for the gradient and backward functions? I'd like to get that merged if possible?
akfluffy has joined #mlpack
< akfluffy> zoq: hey, did you get a chance to make that CNN example with an image?
< akfluffy> with 3 channels*
akfluffy has quit [Remote host closed the connection]
< lozhnikov> jeffin143: okay, I'll look through the PR today.
< jenkins-mlpack2> Project docker mlpack nightly build build #359: STILL UNSTABLE in 3 hr 33 min: http://ci.mlpack.org/job/docker%20mlpack%20nightly%20build/359/
< zoq> ShikharJ: I did, but the gradient didn't match with the implementation, have to recheck my calculation, will do that in the next day or two.
< zoq> akfluffy: Not yet, will do this in the next hours.
< zoq> akfluffy: I pretty much reused the ConvolutionalNetworkTest/VanillaNetworkTest: https://gist.github.com/zoq/87070ff2a4bf769d2264527b2f67b035
< ShikharJ> zoq: Hmm, okay. Please take your time :)
< ShikharJ> sakshamB: Toshal: Are you guys here?
< Toshal> ShikharJ: I am here
< sakshamB> ShikharJ: yes I am here
< ShikharJ> sakshamB: Okay, let's start on MiniBatchDiscrimination and Inception Score.
< sakshamB> ShikharJ: alright
< ShikharJ> I see that you marked a task as check inception score, that got me a little confused. What was meant by checking the score? And is there anything left to implement there?
< sakshamB> I’ll push the changes requested by zoq soon.
< sakshamB> hmm I just wanted to check the inception score of images produced by gan with minibatch discirmination layer.
< ShikharJ> sakshamB: I see that Virtual Batch Norm is currently under progress, but I think the changes to BatchNorm should be made in a separate PR please.
< ShikharJ> sakshamB: Is there a baseline score reported somewhere?
< sakshamB> ShikharJ: yes I will do that. I just wanted to confirm whether the issue is valid or not before opening the PR.
< ShikharJ> sakshamB: I'm saying this about BatchNorm because it can be a part of a wider issue, and I don't wish Virtual Batch Norm to get stuck in that issue.
< sakshamB> ShikharJ: yes do you think I should open a separate PR for BatchNorm right now?
< ShikharJ> sakshamB: Yes, and you should also ideally push in changes for other tests that do not make use of Linear Layer before their layer of test, to check the validity of our hypothesis.
< sakshamB> ShikharJ: I will add the linear layer for the other tests but I am not sure how it would test the validity of the issue. It is possible that other layers also have the Backward implemented incorrectly.
< ShikharJ> sakshamB: Yeah, but if the number of those layers is small, we'll have a better idea where we're going wrong with the implementations.
< sakshamB> ShikharJ: alright sounds good. I will open the PR by today.
< ShikharJ> Toshal: Though I didn't get a chance to review the Radical Test PR, I think it's a nice addition. Radical test has been failing quite sometime lately.
< ShikharJ> Toshal: The argument about making the different changes related to GANs in different PRs would apply here as well.
< ShikharJ> Toshal: I'm talking in terms of Serialization PR. I'd appreciate if your GAN related changes were made in a separate PR, so we can focus on serialization only.
< ShikharJ> Toshal: I'm convinced of the implementation, so as soon as you shift those changes, I'll approve and merge. This is also because I'll have to see the output of serialized and reloaded GANs.
< ShikharJ> Toshal: Are you there?
< Toshal> ShikharJ: sorry
< Toshal> Okay I will make a seprate PR.
< ShikharJ> Toshal: I should be able to provide you brief reviews on the Label Smoothing and Weight Normalization by today. I still have to read the full papers.
< Toshal> Okay
xiaohong has joined #mlpack
< sakshamB> ShikharJ: Getting back to your previous question regarding the baseline for inception scores, I think that it would be difficult to have a fair comparison since we will be training our own cnn model for computing the score as compared to using the Inception. Also most of the scores reported online are for CIFAR.
< ShikharJ> Toshal: By GAN related changes, I mean those where the gradient of the generator is changed. Just to be clear, rest all looks good.
< ShikharJ> sakshamB: Oh, so is it a relative measure?
< Toshal> ShikharJ: Yes, I got that.
< ShikharJ> Toshal: Okay cool, feel free to log off for now. I'll have to run and catch my regular bus, I'll start reviewing when I'm on it :)
< Toshal> Okay, Have a good day.
< sakshamB> ShikharJ: yes it would be best if we compare the inception score for different GAN variations. it would be difficult to get absolute numbers.
< ShikharJ> sakshamB: Okay, that sounds like a good idea to me. Do you mind implementing it based upon the existing models that we have of the different GAN variations? We just need a script for testing, it doesn't need to be a new test that we wish to merge.
< ShikharJ> Or rather we could merge it in a different test file for metrics, I'm open to that as well. Since the models are already implemented, it shouldn't be too hard.
< ShikharJ> Just need to find a way to cross test them on Inception.
< sakshamB> ShikharJ: hmm I am not sure about your second idea on “test file for metrics”
< sakshamB> it won’t be possible to train the entire model in the duration of the build and check the inception scores.
< ShikharJ> sakshamB: Hmm, yes I think your concerns are valid. In that case, we can always push it over to models repository once we find the script is final.
< sakshamB> sakshamB: yes I think we should just have a script to see the inception scores for different variations rather than a test for now.
< sreenik[m]> rcurtin: Just received the stickers with your note. Looks really cool. Thanks :)
< ShikharJ> sakshamB: Okay, I'll leave you to the tasks then.
< ShikharJ> sakshamB: Toshal: Have a fun week.
< sakshamB> ShikharJ: alright have a great week. :D
xiaohong has quit [Ping timeout: 256 seconds]
ImQ009 has joined #mlpack
< rcurtin> sreenik[m]: awesome, glad they made it to you :)
< sreenik[m]> :)
< akhandait> sreenik[m]: Hey
< sreenik[m]> akhandait: Hey!
< akhandait> How did the last week go?
< sreenik[m]> Quite constructive. The weight extraction is complete.
< sreenik[m]> The transfer of weights to mlpack model is also done
< sreenik[m]> To summarize, linear models are getting converted as expected
< akhandait> Great, did you face any of those problems you thought you might face?
< akhandait> sreenik[m]: Awesome!
< sreenik[m]> I did but many of them are solved now
< akhandait> I would suggest open a WIP PR and keep updating it as you go
< sreenik[m]> Ah okay sounds reasonable
< akhandait> If the linear models work, then people can maybe leave any other suggestions they have on the PR
< sreenik[m]> Yup
< akhandait> Also, about the parser, when do you think you can open the new PR?
< sreenik[m]> I hope to get convolutions working soon. The issues are:
< sreenik[m]> akhandait: About the parser, I will take just one day to finish it up, whenever you say, I can get it done by the next day
< sreenik[m]> So, the issues are: 1) There is a supported parameter called groups for the conv layer in onnx. Not sure what it exactly does but it is missing in mlpack.
< akhandait> Okay, can you try to do it by Wednesday night? I was hoping we could get that merged before the first evaluations.
< akhandait> Okay, go on
< sreenik[m]> 2) The maxpool layer does not have *pads* in mlpack (zoq had said he will look into that, so that will be fixed soon)
< sreenik[m]> 3) A couple of mlpack layers have a few non-customizable parameters like batchnorm and selu
< sreenik[m]> That's what I remember for now
< sreenik[m]> akhandait: Yes, I can get the PR into mergeable state by Wednesday night
< akhandait> Okay, I think it will be a bit easier to help you with these specific problems once you open a WIP PR.
< akhandait> About the groups parameter, I will check it out and see what we can do about it.
< sreenik[m]> I agree. I'll do it in a couple of hours (after a little code cleaning), in my own repo?
< akhandait> 2) That's great
< akhandait> sreenik[m]: Oh, sure. I first thought that you would open it in the mlpack repo directly, but now I realized that we are planning to create a new repo for this stuff.
< akhandait> So, your profile works
< akhandait> 3) Let me see check the batchnorm and selu source quickly
< sreenik[m]> Yes, I will try to set up a repo in my profile as I think the new mlpack will look like. That would make the work a lot more easier
< akhandait> sreenik[m]: Nice idea.
< akhandait> 3) Sorry, I didn't exactly get the 3rd problem
< sreenik[m]> Say for example, in mlpack's implementation of batchnorm, we can specify epsilon, but in onnx's case we can specify epsilon and momentum (that's what it looks from the outside as I have never used momentum in batchnorm before)
< akhandait> Hmm, I get it
< akhandait> I think for frequently used layers like batchnorm, we could make changes in mlpack's source to add the parameters that onnx supports but we don't.
< akhandait> It will only make our layers more flexible
< akhandait> zoq: What do you think?
< sreenik[m]> Looks like a reasonable solution to me, let's see what zoq has to say
< akhandait> sreenik[m]: If we decide to go ahead with this, I guess you would have to make a list of reasonable number of important layers that lack some parameters compared to onnx which we can add.
< sreenik[m]> Yes, that's right. Moreover, we should also make a list of the layers we would support. There doesn't seem to be too many that exist though
< akhandait> Yeah, we should make a list.
< akhandait> We would also need to add this list in the documentation of our new repo
< akhandait> It should be clear what we support and what we don't
< sreenik[m]> Let me see. I will give the conv a shot today. If I can successfully get the conversion done (assuming the onnx model does not contain unsupported attributes) then I can compile the list by tomorrow noon
< akhandait> Great, add this list in the readme of the new repo
< sreenik[m]> Okay.
< akhandait> Cool, any other updates?
< sreenik[m]> No, just that I guess I would write the blog after I get that json parser PR in good state
< sreenik[m]> That is, this Wednesday
< akhandait> Sounds good.
< akhandait> So, how are we doing with our timeline?
favre49 has joined #mlpack
< sreenik[m]> Going at a slower pace than I thought it would when I made the timeline, sadly
< akhandait> Don't worry, that's what happens in most cases. :)
< sreenik[m]> Unexpected error and segmentation faults and all, but we are probably a week behind
< favre49> zoq: I have some preliminary results - NEAT is producing errors of at most 0.5 in the current XOR test
< akhandait> sreenik[m]: We have a lot of time left to cover stuff up, I think you are doing good right now.
< zoq> favre49: Are you talking about the infinity issue?
< sreenik[m]> akhandait: Thanks for the assurance. I'll finish these things for now as discussed and give you a report on Wednesday night. I'll keep you updated as I complete each of these small tasks
< favre49> Oh no i fixed that, it was exactly what you suspected. Sorry for not updating you on that
< zoq> sreenik[m] akhandait: have to take a closer look at the discussion.
< favre49> This is the error on the actual XOR test
< akhandait> sreenik[m]: Sure, good luck with it! Good night :)
< zoq> favre49: So it fails half of the time?
< favre49> basically a fitness of ~3.8 on the current test.
< zoq> hm, not sure if this is good or bad :)
< akhandait> zoq: No rush, whenever you are free
< favre49> No I meant it gives a fitness of at least 3.5, or an error of 0.5 as the result of the training, sorry if that was not clear
< sreenik[m]> akhandait: Thanks, good night!
< favre49> zoq: Well actually there are some problems, and I'll try to figure them out. For one, if instead of passing a random input, I pass all possible XOR inputs, the results become far more erratic, and sometimes produces some stellarly horrible results.
< favre49> I am aiming for a fitness of 3.9, since that's what the python implementation gives on the XOR test
< zoq> favre49: Okay, that is strange, if I remember right you pushed the XOR test?
< favre49> Yup, but I'm yet to push the changes
< zoq> favre49: okay, the maximal fitness is 4 on the XOR task?
< favre49> Yup
< zoq> Do you think you can push the changes today or tomorrow?
< favre49> I'll push the debugged code tomorrow, still have a thing or two to fix.
< zoq> okay sounds good
< zoq> Maybe it makes sense to step through the method using GDB.
< favre49> Yup I'll do that
favre49 has quit [Quit: Page closed]
ImQ009 has quit [Read error: Connection reset by peer]
akfluffy has joined #mlpack
< akfluffy> zoq: thanks so much for the example :) just out of curiosity, how long does it take you to run one pass?
gmanlan has joined #mlpack
< gmanlan> rcurtin: you there?
< rcurtin> gmanlan: yeah, just got back from dinner
< gmanlan> hope it was a good dinner
< gmanlan> qq: you suggested renaming openblas to workaround the python build... but the script is looking for .lib not .dll.a
< rcurtin> gmanlan: just boring chipotle :) but it was good enough
< gmanlan> :)
< rcurtin> oh, right, so... hm. I think the regular mlpack build should be linking against the .lib, so I guess that would need to be renamed
< rcurtin> is there a libopenblas.lib file somewhere?
< zoq> akfluffy: < 1 second, the complete run took about 10 seconds
< gmanlan> when we use nuget package manager to obtain openblas, there is no .lib
< gmanlan> that .lib would be available if openblas is built from scratch
< rcurtin> gmanlan: huh, in this case, I'm not sure how any of the mlpack programs or libraries are linking successfully against openblas
< rcurtin> I thought that on Windows, if you were linking against something, you needed the .lib available at link time, but the .dll at runtime
< rcurtin> maybe my memory or understanding is wrong...
< gmanlan> that's the .a I believe in this case - let me double check
< rcurtin> huh, but I guess then python is trying to link against openblas.lib but instead should be linking against openblas.dll.a?
< rcurtin> you could try a "cheap hack" and just copy openblas.dll.a to openblas.lib to see if that will work, and if it does, I can try to fight with setuptools to get it to link directly against openblas.dll.a
< gmanlan> well, the .dll.a helps the program link against the dll (dynamic)
< gmanlan> and that's the only thing that nuget downloads when you include the openblas package
< rcurtin> the first answer seems to suggest that maybe the .dll.a and .lib are equivalent... do you want to try the copy/rename trick and see what happens?
< gmanlan> let me try
< rcurtin> or if you're sure it won't work, I can maybe try to get setuptools to use the .dll.a
< rcurtin> from my end I'm not sure what the right way to link is, so I'm just suggesting trying random things, and if we get one to work I can fight with setuptools to make it do the right thing :)
< gmanlan> well I have built openblas from scratch so I know the .lib will be there, it's just the way in which Nuget works that you get the .dll.a so let me try the hack
< rcurtin> ah, ok, yeah
< rcurtin> we'll find out I guess...
< gmanlan> don't worry
< rcurtin> the issue is that for setuptools, I pass in a list of libraries and a list of library paths
< rcurtin> and the intention is that it will link like it would on linux... i.e. it takes the library list ["mlpack", "openblas"] and does -lmlpack -lopenblas
< rcurtin> and uses -L to set the library search directories right using the given library paths
< rcurtin> but the thing is, one can also use the gcc linker to specify a library to link against directly with -L/path/to/libmlpack.so
< rcurtin> which is what I'd really prefer to do... but I haven't yet figured out how to make setuptools do that
< rcurtin> (my processing of the library locations and names is why the "libopenblas.dll" change to "openblas.dll" was needed---I strip the "lib" from the front of the names, since on linux you'd specify -lmlpack not -llibmlpack
< rcurtin> so, as a result, setuptools expects "mlpack" not "libmlpack")
< gmanlan> I see
< gmanlan> that's a lot of work to keep it compatible across OSs
< gmanlan> "I'm not sure how any of the mlpack programs or libraries are linking successfully against openblas" --> by just specifying the .dll.a in -DBLAS_LIBRARY and -DLAPACK_LIBRARY
< rcurtin> ok, so the linker is just linking directly against the .dll.a then
< rcurtin> ok, so I think the renaming trick will work, and on my end I'll just have to fight with setuptools to make it handle direct library names better
< gmanlan> probably... I'm running a build to double check
< rcurtin> thanks
< gmanlan> rcurtin: it seems it worked
< gmanlan> at least 44 errors went away
< gmanlan> it seems there is an extra decoding error: mlpack\kernel_pca.pyx:83:67: Decoding error, missing or incorrect coding=<encoding-name> at top of source (cannot decode with encoding 'utf-8': invalid start byte)