@chhenning This sounds interesting. There may be some overlap with what the three of us are doing.

What I was trying to do was get it all to build using MSVC 2017 with all of the latest dependencies which would then allow us to support Python3. It turns out that it is not that simple. I am making progress but it is slow slogging through the compile errors in the Swig generated C++ code. And I have not even gotten to the bindings yet. My thinking is that it is best to have a baseline that we know works on MSVC 2017 before we start modifying it to add the other language bindings. I don’t think I am very far away from getting this working but it is slow.

As I understand it, @heilerm is starting with the raw C++ code (without all of the Python stuff) and getting that to build. I know that the python is embedded deeply into the C++ code. I think once I have my base working I will start working with this approach and see if we can condense the nupic.core code down to just C++. I would like to get rid of most of the dependencies. It is just way to complicated.

Your approach I think is to go directly to the existing C++ code, bypassing the Swig files using pybind11. Unfortunately pybind11 can not be used to interface other languages like C# which is our objective. But it is good to know there is a way to support Python without SWIG if we decide to use something else for C#.

As I understand it, @heilerm is starting with the raw C++ code (without all of the Python stuff) and getting that to build.

Yes, it’s just a foobar library right now. Some simple CMake and project structure stuff. I’m figuring out how best to setup swig to generate wrappers from the interface bindings. Eventually, adding all the necessary infrastructure used in nupic today. Appveyor, etc. Then, plop in the C++ source and header files, hopefully extracting all the python stuff in that process.

@David_Keeney@heilerm I’m trying to offer two things. One is a MSVC2017 solution to build/debug/extend nupic.core c++ code. This is pretty much accomplished in the visual_studio_2017 branch. Secondly, I’m trying to make nupic.core available to python 3 users. My work in progress in on the pybind11 branch. If I’m correct a lot of nupic.core c wrapper code for python can be removed.

As for the c# bindings. I have a feeling that all new fancy HTM algorithms are implemented and tested with python these days. Hence c# bindings would not have access to that easily. There is c++ htm research repo but it’s not very active as well. I might be wrong but if you like to do htm then you need to stick to python and c++.

NuPIC is currently undergoing a major refactoring, with the goal of extracting a C++ “core” that contains all CLA algorithms. This will provide a core repository so other language bindings can be created aside from Python.

@chhenning@David_Keeney This is what I’m thinking, as I understand it (a complete extraction to pure C++). Not sure yet if boost/ublas+mkl would be a suitable replacement for numpy, but that would remove the python dependency, I believe… if the tests were migrated as well. Would spend more time investigating that, down the line. Still not sure what pycapnp does.

@heilerm Yes, I think we can replace numpy. I don’t know if boost is the best approach or if I should just right the functions we need using the std:: library but either way we should be able to get pure C++.

By the way…major progress. My build finally completed…all 29 projects. The install also succeeded but I don’t know yet if I have python bindings. I started running the unit tests. It failed on something in SVM. Will have to do some debugging to see why the serialization did not work.

@heilerm pybind11 comes with Eigen support. I think that might be good to use as well.

I saw Eigen, too… and a few blogs that seemed to dispute its results. I’d like to benchmark it. I think a C++ solution would be best, though - no binding in core, if reasonable.

David_Keeney:

@heilerm Yes, I think we can replace numpy. I don’t know if boost is the best approach or if I should just right the functions we need using the std:: library but either way we should be able to get pure C++.

I’m assuming nupic went with numpy for the optimization on array operations, specifically for SDRs. Looks like uBLAS can be boosted and integrated with MKL. Seems like an optimal solution, and one that can be outsourced, but I’m not confident enough yet to defend that position.

swig has ability to generate bindings into MANY languages, pybind is c+±python, I assume. Do we want to remove that functionality? Not that I’m saying we shouldn’t as maybe noone is actually using the swig bindings (other than py)? There’s java fork, …

the move Py3, pybind11, … is a big change, I’d suggest to separate it: first pybind, then move along with py3?

@breznak You are correct pybind is a big change and only targets python. But at least both environments python 2.x and 3.x are covered. If you are interested in what it looks like, you can find my current implementation here. I think it’s in good state and so I have moved on to python 3 migration. That does not mean that I don’t find holes in my coverage but it’s easy to add.

What I really like is that I can define a python module with pybind in cpp. Then load it inside a cpp app along with some python code (file) and debug issues. There are many more advantages but this is the one I like most, right now.

Do you think nupic’s current usage of swig enables many languages? I only see python working.