01:14 < rcurtin> gmanlan: ah, ok, maybe I didn't get the only character

01:16 < rcurtin> I pushed a fix to that... I should have checked all through the file for the bad encoding characters :)

01:18 < rcurtin> sorry for the slow response, by the way... there was a big rainstorm and a tree fell down (luckily missed a nearby car)

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

16:08 < gmanlan> rcurtin: np, I hope you are ok with that rainstorm

16:09 < rcurtin> yeah, it wasn't that bad :) I was surprised a tree fell, but glad it didn't hit anything

16:14 < gmanlan> (Y)

16:49 < favre49> zoq: I've made some progress, and found a bunch of bugs and errors. I'll push the code in an hour or so

16:51 < favre49> I still get a std::bad_alloc sometimes, I'll fix that soon. I was more concerned with getting more consistent results.

16:52 < favre49> I get a fitness around 3 almost consistently now, but from what I see, the problem is that there isn't much of a change in fitness over the generations.

16:54 < favre49> But it doesn't regress or bloat like it used to. To fix the bloating issue, I allowed a type of structural mutation to only occur once. I was wondering, in the paper only structural mutations that increased complexity were allowed, but in some implementations they also include deleting nodes and connections to be allowed. What do you think?

17:21 < gmanlan> rcurtin: python build was successful

17:21 < gmanlan> I was able to install the python package - although it can't find the DLLs in runtime

17:21 < gmanlan> The interesting fact is that mlpack was built as a static library

17:27 < gmanlan> ah - ok so it was not mlpack but openblas dll missing in the PATH

17:28 < gmanlan> now it's not complaining about DLLs but something else, not sure what: from .cf import cf ImportError: cannot import name 'cf' from 'mlpack.cf' (C:\miniconda3\lib\site-packages\mlpack-3.1.1-py3.7-win-amd64.egg\mlpack\cf.cp37-win_amd64.pyd)

17:51 < gmanlan> ok so it seems the problem is just the CF module - commenting out that one mlpack seems to work

18:15 < rcurtin> not sure why CF would have an error...

18:15 < rcurtin> anyway, I'll spend a little time thinking about the RF error, but do any of the other bindings work?

18:15 < rcurtin> you can try this:

18:15 < rcurtin> >>> from mlpack import pca

18:15 < rcurtin> >>> import numpy as np

18:15 < rcurtin> >>> x = np.random.rand(100, 10)

18:15 < rcurtin> >>> output = pca(input=x, verbose=True, new_dimensionality=5)

18:16 < gmanlan> uhm, that dimensionality is invalid?

18:16 < rcurtin> huh, looks like x isn't being properly passed to C++ then...

18:16 < gmanlan> [FATAL] Invalid value of 'new_dimensionality' specified (5); cannot be greater than existing dimensionality (0)!

18:16 < gmanlan> yep

18:17 < rcurtin> I feel like I might have to get a Windows VM running to debug this one... with the build stuff I think we could iterate okay but this is probably a lot more in-depth :(

18:17 < gmanlan> probably

18:17 < gmanlan> I feel the RF is related to the same

18:17 < rcurtin> yeah, if matrices aren't going back and forth nothing will work

18:17 < gmanlan> probably the C++ side has evolved a lot and the bindings are not following

18:18 < gmanlan> I just posted some of the changes I made, maybe we can include these so at least the build is successful

18:18 < rcurtin> the point of interface is that we get the memory address of a matrix from numpy and then wrap it in C++, so I'm surprised that those don't work

18:18 < gmanlan> and then work on the implementation-related issues

18:18 < rcurtin> yeah, I saw those, I'll incorporate those tonight

18:21 < gmanlan> rcurtin: thanks for the help - I will get back to this later, leave me a note in the PR if you need me to try it out

18:26 < rcurtin> sounds good

18:26 < rcurtin> I can at least fix the build issues (I think), it might take longer to get the runtime issues sorted out

18:38 < gmanlan> (Y)

19:11 < zoq> favre49: I did some experiments with the possiblity to disable genes (some time ago) and it can be helpful for sure, so if you see a way to do this, I think we should implement that as well.

19:11 < zoq> favre49: Don't think this is necessary for the XOR test case, maybe we should test on a AND as well?

19:18 < zoq> rcurtin: about https://github.com/mlpack/mlpack/issues/1929, if I remember right you discussed with someone some sort of streaming data wrapper around arma::mat, but I can't remember what the idea was.

20:59 < abernauer> rcurtin: Should I move on to the code that actually prints the pca binding?

21:06 < rcurtin> abernauer: of course, if you like, but I still haven't seen the working handwritten PCA binding. maybe I missed an email?

21:08 < abernauer> Yeah I need to push that to a repository still. I will get on that now. Forgot to CC Dirk and James in that last email.

21:18 < rcurtin> I'd suggest making sure we can all see and run what you wrote by hand first, so that you don't do a bunch of work on the code to print the binding and then have to rework it

21:29 < abernauer> Yeah that is fine and preferred.

21:41 < abernauer> https://github.com/abernauer/mlpack_r_binding/blob/master/pca_binding.cpp

23:37 < rcurtin> abernauer: how can I run this binding from R?

23:37 < rcurtin> I think there needs to be a .r file too (and compilation/usage directions would be useful, since I don't know much about R...)

23:37 < rcurtin> thanks for uploading it, otherwise it seems to look right (from what I can see so far)