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?

Requirements from Serialization

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