allow algorithm alternatives

[floybix]

In Comportex the regions, layers etc are built to protocols, so technically everything can have alternative implementations. But it is awkward to provide a whole region/layer implementation when you just want to change a part of the core algorithms.

It would be useful to be able to specify alternative implementations (functions) for algorithm parts in "user" code. For example - spatial pooling, i.e. selecting the set of active columns.

This is complicated mainly by the need to be able to serialize a HTM model. So it couldn't just be a function parameter.

I imagine we could specify a namespaced symbol resolved to a function at runtime.

• like Onyx.
• spec {:spatial-pooling 'org.nfrac.comportex.cells/standard-spatial-pooling}
• behind the scenes this could be either just a resolve and call, or a multimethod dispatched on the spec key.

Does that seem reasonable?

(It may also be worth remembering that engineering everything to be customisable is often a worse idea than having simple code that can be edited as needed.)

[robjfr]

I've always thought it weird that in a functional implementation all your protocols refer to objects. I reconciled that by remembering that HTM is a model rooted in the object of the cortex. But the fit still seems problematic. We don't have a good idea what the functions of the cortex are. That is the problem.

Hint: I think the core function is collecting contexts together. That also avoids the time problem.

[floybix]

First cut of multimethods for spatial-pooling and temporal-pooling implemented in 2b90437