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/
robertoh1eso has quit [Quit: leaving]
robertohueso has joined #mlpack
< robertohueso>
rcurtin: I think I finally made some progress! :D
< robertohueso>
Let's say we have a Monte Carlo with probability set at 95%. 300000 reference points and 100 query points. Relative error tolerance set at 1%
< robertohueso>
Out of those 100 query points, 90 of them satisfy the relative error tolerance bound, the other 10 instead have relative errors of ~1.5% to ~2%.
< robertohueso>
Does this seem right?
< robertohueso>
(Although I think we still have the recursion issue)
< rcurtin>
robertohueso: nice! that seems pretty close to correct, although I'd expect ~5 query points to have higher relative errors
< rcurtin>
what happens if you run with different random seeds?
< rcurtin>
I haven't had a chance to think through the way recursion should happen, but I have a few ideas (maybe you have some too)
< rcurtin>
I should be able to think them through the rest of the way tomorrow and then share on Friday
sumedhghaisas_ has quit [Ping timeout: 248 seconds]
sumedhghaisas_ has joined #mlpack
sumedhghaisas_ has left #mlpack []
sumedhghaisas_ has joined #mlpack
Suryo has joined #mlpack
< Suryo>
zoq: I have some comments about the CNE algorithm in ensmallen.
< Suryo>
The CNE algorithm employs elitism. My own experience with elitism in GAs is quite mixed. For some problems, I have observed that the preservation of elites renders a good and stable solution, and for some problems, a completely new successive generation of solutions yields better results.
< Suryo>
Note that there are very many local minima in the function.
< Suryo>
One of the things that could possibly go wrong is that the elitist solutions settle in a local minima and then these solutions start dominating over the successive generations. Naturally, if most of your elite solutions are settled near a single local minima, their children would also be concentrated in the vicinity. And the problem here is that most of the children in successive generations may not be better than the already elite par
< Suryo>
One other reason why I think this may be happening is that the initial population is created as a gaussian distribution around the initial point. So I think that it is likely (though not in a strictly statistical sense), that they're all settling into a local minima and getting stagnant.
< Suryo>
What bothers me the most about this is that the tests almost never fail on my system. And the builds also succeed in travis-ci.
sumedhghaisas_ has quit [Ping timeout: 258 seconds]
< Suryo>
Let
< Suryo>
*Let's work this out. Do let me know your thoughts on this.
Suryo has quit [Quit: Page closed]
< akhandait>
sreenik: Sublime uses much much lesser memory than vscode as far as I know. Also, I like it because it's a nice balance between a basic text editor and an IDE. It's a good visual text editor, project manager but I still like to use the linux terminal for compiling and executing.
< zoq>
Suryo: I can rerun the experiments and check if it ends up in a local minima. Also, about the travis build keep in mind that we only run the test once, so travis was probably just lucky. if you run the test on yur local machine it's important to use a different seed for each run: https://github.com/mlpack/ensmallen/blob/master/tests/main.cpp.
< zoq>
Suryo: We could swap out the gaussian distribution.
sreenik has quit [Ping timeout: 256 seconds]
Suryo has joined #mlpack
< Suryo>
zoq: Okay I understand now. Allow me to re-run the tests with different seeds and also check if the solutions stagnate.
< Suryo>
Also, since you've mentioned it, I would like to try it after swapping out the with a uniform distribution across the entire search range. I'm not thinking about this as a feature or anything, but I'd just like to investigate it.
< Suryo>
Thank you once again for your insights.
< zoq>
Would be great if we could increase the stability of the optimizer for sure.
Suryo has quit [Remote host closed the connection]
KimSangYeon-DGU has joined #mlpack
sreenik has joined #mlpack
< sreenik>
akhandait: Sounds good, I'll give iit a try
< rcurtin>
Suryo: I found a strange and unexpected bit of code in the CNE code... you should try changing it and see if that affects your results
< rcurtin>
there is a line like this:
< rcurtin>
size_t result = function.Evaluate(...)
< rcurtin>
but... size_t is not the right type! in a PR that is open I have changed that to `double` but you might try doing that locally also
< rcurtin>
that's in cne_impl.hpp
< ShikharJ>
rcurtin: Just received the stickers, thanks a lot! Gonna hunt for some good Mexican tacos now :)
< ShikharJ>
sakshamB: I just read the full highway networks paper. Quite interesting, I wish I had read that earlier :) Do you think we could implement an MNIST classification test on that?
< ShikharJ>
zoq: I would appreciate your views on this as well.
pd09041999 has joined #mlpack
< sakshamB>
ShikharJ: I think we already did that. I have added a test for that in feedforward_network_test for MNIST.
< ShikharJ>
sakshamB: Oh okay, I should've kept that in mind :)
< rcurtin>
ShikharJ: glad you got them :)
< ShikharJ>
sakshamB: I'm still not certain about the backward and gradient functions though.
< sakshamB>
ShikharJ: do you think they are implemented incorrectly?
< ShikharJ>
sakshamB: Nah, I needed to do a little scribbling on paper to find the derivatives myself.
< ShikharJ>
I just spent the last five minutes manually computing them, and now I'm confident of the backward pass atleast for now.
< ShikharJ>
In particular, I understand why transformGateError = gy % (networkOutput - inputParameter) %
< ShikharJ>
transformGateActivation % (1.0 - transformGateActivation); is there.
< sakshamB>
alright let me know if anything doesn’t make sense :)
< ShikharJ>
sakshamB: I don't think I have any more doubts, the PR is good to go IMO.
< ShikharJ>
Glad to merge the changes in.
< sakshamB>
ShikharJ: thanks! :)
< ShikharJ>
sakshamB: Alright, I gotta get back to my assigned work. I'll see you guys tomorrow, and maybe provide another review of a PR later today.
< rcurtin>
zoq: I see that conda-forge is packaging mlpack now; do you think that we should remove the mlpack packages you uploaded to conda?
< rcurtin>
actually I just encountered a very strange issue with a user today---they had python 3.7, so actually mlpack 2.2.5 got installed because there is no py3.7 package for mlpack 3.x
jeffin143 has joined #mlpack
< jeffin143>
lozhnikov : thanks for the code, are you there
< rcurtin>
zoq: sorry, got hijacked by someone else and didn't finish the whole message chain :)
< zoq>
ShikharJ sakshamB: Happy to take a look at the PR as well.
< rcurtin>
they then tried to install mlpack from source, and it was kind of a linking disaster because conda's environment plus setuptools were linking against libmlpack.so.2, etc., etc.
< rcurtin>
I need to debug the anaconda environment a bit more, to see what's really needed (I think there may be boost issues too?) and then I think I will try to help the conda-forge maintainers update their package
< zoq>
but they initially installed mlpack via conda?
< rcurtin>
zoq: yeah, it was a bit of a weird situation, it went off the rails fast
< zoq>
oh, okay
< rcurtin>
but in any case, what do you think, should we turn over maintenance of the mlpack conda package to the conda-forge maintainers?
< rcurtin>
I see emails from that repository so there is some activity there, but I am not sure of the state of the packages
< rcurtin>
judging by the download stats it looks like people end up using the conda-forge package a lot more anyway:
< zoq>
think an mkl version would be interesting as well.
< rcurtin>
however, they don't have osx images
< zoq>
*Not sure I like to remove the repo entirly, maybe just bring it up to date? conda forge dosn't build for windows or mac, and I think an mkl version would be interesting as well.
< zoq>
right
< rcurtin>
ah, ok
< rcurtin>
yeah, if they only do linux, then yeah, we should just bring it up to date
< rcurtin>
but I do think we should remove the 2.2.5 package regardless
< zoq>
agreed
< rcurtin>
it's on my list to bring the pip packages up to date too, but I haven't had a chance to really dig into that though
< rcurtin>
I want to get it working on Jenkins so I don't have to fight with all the manylinux docker containers, etc., every time I do a release...
< zoq>
I think they might build for windows and mac as well, they skiped the build in the config
< zoq>
Have to take a look at the build script.
< jeffin143>
lozhnikov : the code above was written , using the current state* ,
< zoq>
Yeah, was working on the docker build script, but got distracted by the callbacks PR.
< rcurtin>
gmanlan and I are still debugging the Python bindings on Windows, so probably we have to disable that until those are done, but OS X should be just fine :)
< lozhnikov>
jeffin143: It's weird. I have to download the branch add look into this thoroughly.
< rcurtin>
the callbacks PR is really exciting to me, once that's ready we can release that and templated optimize in a new major version
< zoq>
Would be great if we could create a mac pip package as well. But if I remember right, the build isn't straightforward.
< rcurtin>
yeah, I was going to look into that
< rcurtin>
for Linux you can use the manylinux builder; for OS X I am not sure if something similar is there
< jeffin143>
lozhnikov: Yeah, sure , I will to do the same , may be some cout statements here and there will tell us.
< rcurtin>
however I am finding that there are so many users using OS X that it's really a necessity
< zoq>
Same for windows.
< rcurtin>
yeah... and here I used to think that all people doing data science work would be low-level linux system experts who didn't use Python! :)
< rcurtin>
of course that may have been closer to true in 2010 when I thought that
< zoq>
Never encounter someone using windows for ml :)
< rcurtin>
but it seems that OS X or Windows Python users make up the majority of the casual userbase right now
< rcurtin>
same, but apparently they are out there :)
< jeffin143>
lozhnikov : not sure , may be it's because of the hash function we are using , it is helping us out I guess*
< lozhnikov>
jeffin143: No, the hash function doesn't influence on the string view.
< jeffin143>
Ok
< lozhnikov>
jeffin143: No, the code doesn't work well. Just try to run with valgrind
< jeffin143>
Ok , I will give it a try
< lozhnikov>
There are a lot of invalid reads as I expected
< lozhnikov>
I don't know why it prints out valid keys. Looks like it's accidental.
< jeffin143>
Yes, thanks for letting me know how to get the errors
< jeffin143>
On a look , I thought it worked
< jeffin143>
But that wasn't true, as u said. Thank again :)
< lozhnikov>
Not at all. Here to help. Actually, I am curious why the code prints out valid keys.
< jeffin143>
I tried multiple times , just to be sure that it works.
< jeffin143>
Also did it on a bigger set , with different values but it works for that too*
< jeffin143>
The only issue you pointed out was the invalid reads :)
Suryo has joined #mlpack
< Suryo>
rcurtin: regarding the change in cne_impl :: roger that. I'll check this out.
< lozhnikov>
jeffin143: I worked it out. Looks like the compiler just didn't use the memory of the origin class. I wrote a simple test that uses more memory i.e. I just introduced a vector and made sure that the compiler doesn't remove unnecessary code. https://pastebin.com/U6dnEDFK
< jeffin143>
lozhnikov , umm how do you come up with this , I mean the thought process .
< lozhnikov>
jeffin143: Actually, it was the only thought since the beginning. I just didn't know how to force the compiler to show the issue.
< jeffin143>
I agree, may be this was a better question " how to force compiler to show the error" , I will overload and check using the same test cases
< lozhnikov>
hmm.. actually I thought if the system runs out of memory, it will be forced to use the memory of the original encoder.
< jeffin143>
:)
pd09041999 has quit [Ping timeout: 246 seconds]
< sreenik>
Can someone throw some light on how to convert a byte stream of uint8 (stored as a string) to an array? What I need is actually an exact implementation of the numpy function frombuffer()
pd09041999 has joined #mlpack
pd09041999 has quit [Remote host closed the connection]
< zoq>
Could you use strcpy?
< zoq>
uint_8* str;
< zoq>
std::string s((char*) str);
< zoq>
char array[s.length() + 1];
< zoq>
strcpy(array, s.c_str());
jeffin143 has quit [Read error: Connection reset by peer]
jeffin143 has joined #mlpack
jeffin143 has quit [Ping timeout: 272 seconds]
< sreenik>
zoq: Thanks. I probably couldn't convey the issue perfectly but I think I have found a solution. I'll try that out and in case that doesn't work, I'll let you know :)
< rcurtin>
however I am sure I will spend hours debugging and getting this working right :)
< rcurtin>
once it does work right, I may try to move it to Jenkins so that I can be more complex with the trigger (it should trigger when a new tag is pushed)
< zoq>
a bunch of bash scripts, but looks promising at a first glance
< rcurtin>
I feel really comfortable with a bunch of bash scripts :)
< rcurtin>
most of my coworkers are really confused when I tell them I do my basic data analysis with awk and sed and grep...
< rcurtin>
(to be honest, Python visualizations of data are generally much better, but I am cheap and reading the output of 'sort | uniq -c | less' is often good enough for me :))
< zoq>
Usually, I end up in python if I wanted to test something real quick, don't really like string parsing in bash.