So, what would each node represent? A region? I don't quite understand the idea of "plugging a node". In my mind, a whole HTM system is like a single brain: multiple sensors supply data to hierarchical regions, which build models for that data, and generate behavior that achieves goals using the models. In this scheme, regions are tightly interdependent, with lots of communication between them. It would make sense to keep them as close together as possible. If by nodes you mean just sensors, then sure, but the actual processing system (HTM) would still be a single entity, that has to be under the same "management", so to speak, to follow the same set of goals, generate coherent behavior, etc.
On Thu, Feb 5, 2015 at 6:15 PM, Matthew Taylor <[email protected]> wrote: > It will become very relevant once proper temporal pooling is > implemented and people start building hierarchies. > > Imagine a networked hierarchy where each node in the network can be > running anywhere on the "cloud". Once a standard model serialization > format and message protocol is in place for this system, anyone could > host a node in the hierarchy and collaborate with others to link > together, forming giant HTM networks. Each node could be tuned > differently, outputting their stable SDRs upwards to other nodes > managed by other groups of people with different configurations. If > one node gets overwhelmed, scaling would not be hard in a distributed > system. Just bring up another node with more power and re-route the > network. The overwhelmed node could save its model state and the new > one can take over without forgetting any data (except what came across > the wire while the swap was taking place, but the whole system will be > fine). > > There are a lot of possibilities, and I don't think anyone understands > the potential applications of a massive networked fault-tolerant > learning system like this. > > --------- > Matt Taylor > OS Community Flag-Bearer > Numenta > > > On Thu, Feb 5, 2015 at 5:36 PM, Michael Klachko > <[email protected]> wrote: > > Why do we need a distributed architecture for Nupic? Is there a > performance > > bottleneck? > > > > On Feb 5, 2015 2:48 PM, "Rich Morin" <[email protected]> wrote: > >> > >> On Feb 5, 2015, at 12:00, Gurvinder Singh < > [email protected]> > >> wrote: > >> > May be I was not clear enough. I am with you on that Nupic does not > >> > need translation to any other language to be disributed. Java is more > >> > than enough. What I meant was that Nupic java implementation can be > >> > used with framework like Apache Spark to get disributed. ... > >> > >> I think we may be conflating some issues and thus talking at cross- > >> purposes. Here are the issues I see and my positions on them (ducks): > >> > >> -r > >> > >> > >> Implementations > >> > >> I really like the idea of multiple NuPIC implementations as a way to > >> try out ideas, learn what works best for what problems, etc. Some of > >> these implementations may be academic, experimental, specialized, etc. > >> > >> So, for example, a message-based implementation in Clojure or Elixir > >> might not be as performant as a highly-optimized Java implementation. > >> However, it may have other benefits (eg, acting as executable pseudo- > >> code and a very malleable workbench for trying out modeling notions). > >> > >> > >> At least one implementation (preferably more) should have recognized, > >> "official" releases. Although language-specific bindings are welcome, > >> any official release should be conveniently usable by applications that > >> use other languages and/or frameworks. A message-based interface which > >> supports streaming of structured data seems like an obvious choice. It > >> should build on popular, well-supported standards, whenever possible. > >> > >> To qualify as an official release, an implementation should pass a > >> specified set of tests. That is, I'd like to see a language-neutral, > >> executable specification that contains both required and optional tests. > >> > >> > >> Languages and Frameworks > >> > >> In large part, these are a matter of taste. I like Elixir, for various > >> reasons, but I don't argue with aficionados of other languages. > However, > >> Elixir inherits some unique features from Erlang, BEAM, and OTP. OTP, > >> for example, provides a well developed and thoroughly tested concurrency > >> and process management framework. I don't know of anything equivalent, > >> either in the JVM or elsewhere (eg, Golang). > >> > >> > >> Of course, Elixir may just be my current "Blub" (:-): > >> > >> Blub ... was used by Graham ... to illustrate the difficulty of > >> comparing a programming language one knows to one that one does not. > >> > >> -- Paul Graham (computer programmer) / Blub > >> > https://en.wikipedia.org/wiki/Paul_Graham_(computer_programmer)#Blub > >> > >> See also: Blub Paradox > >> http://c2.com/cgi/wiki?BlubParadox > >> > >> > >> -- > >> http://www.cfcl.com/rdm Rich Morin [email protected] > >> http://www.cfcl.com/rdm/resume San Bruno, CA, USA +1 650-873-7841 > >> > >> Software system design, development, and documentation > >> > >> > >> > > > >
