Nupic.Core C# Bindings

@David_Keeney This is a good start! There are a few matrix classes missing:


They are all templated and so for python the type SM32 is

nupic::SparseMatrix<nupic::UInt32, nupic::Real32, nupic::Int32, nupic::Real64, nupic::DistanceToZero< nupic::Real32>> .

In python SM_01_32_32 is nupic::SparseBinaryMatrix<nupic::UInt32, nupic::UInt32> .

Hopefully at some point we can replace the matrix stuff with libraries like Eigen or Blaze.

@chhenning Ok, I added those to the ‘math’ section of the list. They are all C++ modules.

I would be interested in the speed difference Eigen or Blaze would make. But for now, lets implement the interface for what we have.

Moved from #nupic:developers into #nupic:community-fork.

I think would be a great, lightweight choice for c++ codebase.

My question is, if instead of solving serialization for each binding, we could make a separate “nupic.serializer” project? Which would take a py/c++/c#/java object and de/serialize it?

Alternatively, the serialization would be only provided by the one low-level binding (c++ nupic.core) and other bindings just call its load/store methods.

Can we define what we are trying to achieve with serialization? For instance, the following scenario.

  1. User A runs a htm network for many hours on his raspberry but realizes he doesn’t have enough computational power to ever finish the job.
  2. User A decides to dump the current state of his htm to disk (about 1TB zipped)
  3. User A calls up his friend User B to finish the job in the cloud on his Windows cluster.

Is that a valid use case?

@chhenning Yes, I think that is a valid description of serialization. The existing approach to serialization should be retained… starting with a call to serialization on the Network class, it calls serialization on all registered Region classes. They in turn call serialization on those classes below them. The de-serialization is just the same in reverse.

Progress report.
I have about 1/4 of the C# binding code rough written, about 1/2 of that compiles. One of the biggest challenges was getting CMake to build the C# interface code (C++/CLI) within the native C++ project that builds nupic core. I still don’t have it building the C# unit test code. Another challenge is determining how to implement the plug-in facility so that it works somewhat like it does for Python. C# is a strongly typed language and some of the data structures used in the nupic.core do not lend themselves to passing data between the native C++ core and the C# plug-ins without copying. But I think it can be done.

I currently have wrappers for:

  • Engine - about 75% rough coded.

  • nTypes and types - 80% coded and compiled.

  • utils - 25% coded

  • encoders - 0% coded

  • algorithms - 0% coded

  • math - 0% coded

  • regions - 0%

  • tests - 0%

  • os - will not be needed.

  • proto - will not be needed (using Yaml serialization.

  • py_support - will not be used

  • bindings - will not be needed (not using SWIG)

Additional work that needs to be done:

  • Write unit tests comparable to the Python test suite.
  • Documentation of the C# interface
  • Sample code written in C#
  • port other Python code to C#
  • getting it to work with non-Microsoft C# compiler on linux

I am taking next week off … Headed for Hawaii in the morning for a destination wedding.
I pushed what I have up to my repository in case anyone wants to take a look.
Do not expect anything to work or anything to be complete. Its a bit of a mess actually…

1 Like

@David_Keeney Great news! Glad you’re making progress. I’ll have to hit you up for some cmake questions. But first enjoy your vacation!

Thanks for making me jealoussssss. :wink:

@chhenning I am back working on the C# interface again and I wanted to get the latest version of Nupic.cpp. But I see this still has the capnproto code in it. Didn’t you remove the capnproto serialization? … or am I looking in the wrong place. I really did not want to do Capn proto serialization in C# unless I had to.

Welcome back!

Do you look at this file?

Ah, yes. This is what I expected to see.
But I expected to see it in htm_community.nupic.cpp
Is this expected to be pushed up any time soon?

I’m still working on my python 3 migration and things change a little from time to time. And besides, I haven’t seen @breznak around for awhile .

I suggest we just use my repo for now. Do you agree?

Sure. I will grab it now.

@chhenning I am in the process of sticking the C# modules into a clone of your repository but I get this error when I try to compile one of my modules:
f:\ai\chhenning\include\pybind11\detail/common.h(111): fatal error C1083: Cannot open include file: ‘Python.h’: No such file or directory

I assume this means that you want Python to be installed in some specific place? How do I fix this?

It would be nice if there is a way to do a C# & nupic.core only build without also having Python installed but we can worry about that later.

Never mind…worked around it. Don’t know which Python version it is getting Python.h from but it now seems to be getting it from someplace.

Sorry for the late reply. You should be able to use both python versions, 2.7.x and 3.x . I think the path might be hardcoded to c:\python36\include. Will fix that eventually.


Can you please tell me in simpler way to setup this nupic in c#. As I have looked at this but I didn’t understand many things. So please make any video tutorial on this or provide some steps to do it. Also what is the advantage of this nupic?

We are still a long ways off from having a C# interface working.

The first steps are to get the nupic.core library extracted so it can be compiled with the latest compilers C++ compilers. Then re-constructing the Python extension to work with this library using Python3 and pybind11. And with support for MSVC, Linux, and OSx platforms. This is almost working but not quite ready for prime time.

The next step is to fill out the C++ library with missing components that are currently implemented in Python (SPRegion, TMRegion), such that Python is not required to implement a full application in C++ using the Network API.

Once all of that is working, we can write wrappers for C#. Much of that has been roughed out but a lot of work remains.

Anyone interested in helping is welcome.