Implement Computable interface for SP, TM, TP, CP

[breznak]

part of #58 Interfaces.

Allows to interchange all computable instances.

• move Serializable to /src/nupic/interfaces/
• basic Computable iface
  • void compute(const SDR input, SDR output, bool learn);
  • additional methods (setLearning(), iterationNum, learnNum, ...
• use in MNIST, Hotgym examples.

[dkeeney]

Basically you are gravitating toward a plugin interface which we already have with NetworkAPI. Imho concentrate on the algorithm performance and don't worry about compatible interfaces.

[ctrl-z-9000-times]

I don't see the use-case for this...
I don't think these algorithms will ever be 100% interchangeable, since every algorithm accepts different arguments, has different methods, and does different things.

[breznak]

I don't see the use-case for this...

won't be 100% compatible, but these share enought in common to be useful (transform sdr -> sdr + some learning).

I have motivation in the mnist, hotgym examples (basically any code that wants to compare multiple versions of these algos).
Example usage in #293 :

//init 
Computable co = new SP(...)
//Computable co = new CP(...) //choose here, this is the only line (constructor) that needs to be different

//train
...
co.compute(input, true, columns);

//test
..
co.compute(input, false, inffered);
classifier.classify(co.iterationNum, inffered, ....); 

Another good example is in Hotgym.

basically, these algorithms (SP, TM, TP, BackTP, CP) have quite a lot in common (in contrary to Classifier, Encoders). It'll iron out the little differences (mostly syntactic sugar), and simplify the interoperability.

This should not be a big PR.

[dkeeney]

Like I said...for cases where a common interface is useful, use NetworkAPI. That is what it is for. Of course I need to finish a few more Region interfaces before this is ready, but I am getting there.

[breznak]

cases where a common interface is useful, use NetworkAPI.

it's a different scope, I don't use NetworkAPI in those examples.

Ok, both of you are not impressed, so I'll put it bluntly, will you not be agains such PR if I make it (because I want to)?

• I'll keep networkAPI
• "algorithms" API can be
  • unchanged + extended for the new common-ground
  • changed to common only (we've declared loose compatibility to anything below NetworkAPI)

[ctrl-z-9000-times]

If you think you can make it work without breaking lots of stuff then go for it, I will approve.

Also include method reset()

The temporal memory compute argument extra is a potential issue. I'm sure there are other places like this where two classes with seemingly similar APIs have subtle differences or arguments with default values. In python this usually isn't a problem B/C the interpreter just deals with it. The C++ compiler is not smart and does not deal with irregularities well.

[ctrl-z-9000-times]

I think what is more important than a C++ class hierarchy are: good conventions & naming schemes and for them to be used consistently throughout the API. And whatever scheme we settle on should be clearly documented.

For example: all classes which accept more than a few arguments should instead use a parameters structure. For a class named MyAlgorithm it should look like:

struct MyAlgorithmParameters
{ ... };

MyAlgorithm( MyAlgorithmParameters );
MyAlgorithm.parameters   // const reference

The parameter structure should not contain stateful data, meaning that instead of an SDR use the dimensions of the SDR.

[dkeeney]

Passing "by structure" I assume applies to just the constructor?

I don't think there is any speed advantage by doing this. So this is just to make it easier to code?
I don't see the benefit unless perhaps its to pass the same parameters to hundreds of instances of a class.

Have you considered some sort of std::map rather than a structure to pass parameters? More like Python.

[ctrl-z-9000-times]

Passing "by structure" I assume applies to just the constructor?

Yes

So this is just to make it easier to code?

Yes

Have you considered some sort of std::map rather than a structure to pass parameters?

I do not think this would work since the data type is different for each parameter. And if you did make it work then the compiler would be unable to check that the parameters are the correct type, and then the algorithm would have to check every parameter's type at run time.

[dkeeney]

You are right, a map would be messy...even though there are ways to use different data types in a map without loosing its type. Not not worth it in this case.

[ctrl-z-9000-times]

BTW:
In python, parameter structures become classes with public members to read/write.
Thank you dkeeney, for showing me how to use parameter structures in the first place!