SpatialPooler and TemporalMemory API change. about etaler HOT 8 OPEN

@gaolaowai Thanks for taking interest.

My main motivation to have statfeul encoders is therefor we can have RDSE and SimHashEncoder. It's nice to have what HTM.core is offering. However I don't see myself using them in any way, shape or form; Grid Cells are a better solution to RDSE.

I prefer stateless encoders better too. Let's keep encoders stateless and add stateful ones when we really need one.

from etaler.

The next release will not be compatible with v0.1.4. I'm starting to work on this.

from etaler.

Design doc

// The main namespace to store everything
namespace et {
namespace F; // functional APIs. i.e. They are state-less
namespace htm; // HTM layers, they may be state-ful
namespace encoder; // encoders
namespace decoder; // decoder, if possible
}

This also begs the question. Should we keep the encoders stateless like they are now? Or NuPIC's stataful encoders are a better design?

from etaler.

Random 2 cents: keep encoders stateless; I like how they're more "functional" and predictable in their behavior.

What would be any benefit in adding state? I'm not sure I can think of any.

from etaler.

Updating on the subject. I'm making progress. But I'm more focused on delivering my project report so I can graduate. (The report is based on the current release, well, I don't have too much time on hand to think about the API)

from etaler.

Updating on the subject. I'm making progress. But I'm more focused on delivering my project report so I can graduate. (The report is based on the current release, well, I don't have too much time on hand to think about the API)

Hi @marty1885!

Thanks for sharing Etaler with the HTM community! I think I'll learn a lot just by diving into your code base and trying to understand how it works and gain further insight into the rationale between design decisions. I especially appreciate that you've written test cases, that you've verified by hand calculations.

Just to let you know, once you've handed in your report I'd be most curious to read it!

Wish you all the best and happy coding!

Cheers,
Robin

Edit: P.S. there's a minor typo in #59 (comment) (I think):

-Tensor y = F::globalInhibition(sp.compute(x), 0);
+Tensor y = F::globalInhibition(sp.compute(x), 0.1);

from etaler.

I properly should find typos in variable names and values... Kinda expect them exist but should have done something.

Just to let you know, once you've handed in your report I'd be most curious to read it!

Thanks for you appreciation! 😸 My report is available on the forum here. There might be more typos in the report tho. English isn't my first language and (since it's just a BS graduation project) I've written it in a half-joking tone :(

Also uploaded to GitHub in case Google Drive filed in the future.
Hierarchical Temporal Memory Agent in standard Reinforcement Learning Environment.pdf

I have ongoing/proper research regarding Etaler and HTM that I hope I can share in the near future.

from etaler.

Design doc for myself:

Generalized autograd

I have being thinking about how exactly I'm going to build a sane functional API for Etaler. A big problem of Etaler is that the "layers" may use a sequence of tensor ops (ex: overlap then global inhibition) but learn using results tenors from later steps (overlap needs the result of global inhibition to learn). However I don't think NuPIC's Network API is a good approach either. Network API is very verbose and requires a lot of know-how to work. I gotta make a new system.

Mostly inspired by the autograd system from various DL libs. Throwing the calculus portion out of the window; autograd is a system sending information is later nodes in a DAG to earlier node. Which is almost what I need. But also presents a few problems.

• autograd produces a DAG.
  • Not impossible to parallelize, but need special care
• I don't need the entire chain as a single object. But all of it's part broken into sub chains.
• Handling data across backends

It is easier to just build a HTM-native, autograd like system to handle it. But I don't want Etaler to be too specialized and the new system should still be able to function as autograd if it wants to. The new generalized autograd should

• Work like autograd
• We scan the DAG before the backward pass to segment it
• There should be a way for a node to send output to later nodes but specify the later nodes have nothing to do with it.

I'm gonna keep workign on this. Then the code (from app dev's view) should be a lot cleaner.

from etaler.