@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#.
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++.
That would conflict with the extraction plan, am I wrong? It seems like the development team intended core to be wrapped in other languages using swig.
@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.
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.
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.
Love this proposal (pybind) for the c++11 and eigen,numpy support!
A few questions though:
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.
I am! Sound great.
As mentioned Port to Python 3 · Issue #2 · htm-community/nupic.py · GitHub
I have trouble merging/reviewing your changes in the “original” codebase, as you probably started a new repo. Can we try to rebase the changes on a new repo with the project’s history?
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.
That is a great feature! So we can now call Py from C++ (used to be only the other way). Does it mean removng the py classes needed in “nupic.bindings”?
Do you think nupic’s current usage of swig enables many languages? I only see python working.
Touche I don’t know…think not. Actually, I’ll be happy to see SWIG go. I’d just suggest asking here “Proposal: remove SWIG bindings for other languages”
Also, what do you think about the “separate bindings for each language”, vs “one bindings for all”?
Can we try to rebase the changes on a new repo with the project’s history?
Sorry you lost me here. My repo was initialized with the original numenta code and then I move from there. Is that not enough? Btw, nupic.core’s unit tests are running through (like 98% or so.)
nupic.core (the original) already makes use of embedded python. For instance when setting up a network with some python regions.
I don’t know…think not. Actually, I’ll be happy to see SWIG go. I’d just suggest asking here “Proposal: remove SWIG bindings for other languages”