Nupic.Core C# Bindings

#62

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

SparseBinaryMatrix
SegmentMatrixAdapter
SparseMatrixConnections
SparseMatrix
SparseRLEMatrix

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.

#63

@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.

#64

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

#65

I think https://uscilab.github.io/cereal/ 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.

#66

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?

Requirements from Serialization
#67

@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.

#68

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.
https://github.com/dkeeney/nupic.core/tree/master/src/nupic/csharp/wrappers
Do not expect anything to work or anything to be complete. Its a bit of a mess actually…

#69

@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:

#70

@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.

#71

Welcome back!

Do you look at this file?

#72

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?

#73

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?

#74

Sure. I will grab it now.

#75

@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.

#76

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.

#77

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.