This is a quick followup to The Life and Times of a Dendrite Segment.

The original:

Here are segment lifetimes in the classic version of Temporal Memory,

Here I performed the same experiment:

  1. Feed an HTM some data with sequencial patterns (hotgym).
  2. Feed it random garbage.
  3. Feed it the first data again.


  • This doesn’t show segment matches (light green). doesn’t compute these, it only computes matching segments for active columns (dark green).
  • For those of you familiar with I’ve disabled backtracking, sequence length limits, “pay attention mode”, and global decay. So it’s similar to pure Temporal Memory, but it still has differences, e.g. “start cells” and implementing “winner cells” differently, not actually bursting unpredicted columns but instead choosing a single cell immediately. Since we’re never activating all cells in a column, segments are less likely to be matching, so we’re more likely to add new segments. This is one reason there’s a higher segment learning rate, but there may be other reasons I’m not thinking of.

Success! It keeps itself tidy, and it doesn’t discard its useful segments when it sees white noise. Looking at it from this angle, this implementation of segment cleanup is superior to that of the new / TemporalMemory.cpp.

The segment cleanup rules

  • When a segment’s synapse count falls below the activation threshold, the segment is removed.
    • …but with global decay disabled, there’s no learning rule that would cause this to happen. Incorrect predictions are not punished.
  • When a cell exceeds its maximum allowed number of segments, it removes the segment with the lowest duty cycle.

So this all depends on how we calculate the duty cycle.

Every time a segment is created or activated, it is considered active for this timestep. A segment’s duty cycle is, roughly, the fraction of timesteps it is active. uses this formula:


  • is the duty cycle at time .
  • , “alpha”, is a multiplicative factor. It’s implemented as a lookup table for constants, based on the current timestep (scroll down).
  • is whether the segment is active at time . It’s 0 if no, 1 if yes.

Let’s make sense of the formula.

One way to calculate duty cycle would be:

All timesteps would be created equal. All segment activations have equal impact on the duty cycle.

You’re still reading, so you’re smart enough to know that the incremental version of this formula is:

This formula makes intuitive sense. For example, if is 1000, this rule says:

“The duty cycle is of the previous duty cycle, plus of the segment’s current state.”

So corresponds to . It’s interesting to see how they differ.

Here are the values that uses, compared to .

range range

and so on.

This table shows that most of the time . For example, at timestep 1000, , so this rule basically says:

“The duty cycle is of the previous duty cycle, plus of the segment’s current state.”

In other words, it starts with a duty cycle that was established in 1000 timesteps, but it gives this previous value the weight of 3200 timesteps. So this segment’s duty cycle will take a disproportionately long time to change. Hopefully this Temporal Memory had a happy childhood.

How I got this data

Here’s my Jupyter notebook:

I used a private throwaway version of that added segment event hooks.

Oh, in case you don’t know:

  • / are the production implementations of Temporal Memory. They combine Temporal Memory with some nonbiological features. TP10X2 is mostly written in C++ and produces identical results to
  • / TemporalMemory.cpp are recent pure implementations of Temporal Memory.

Yes, this post lied a little bit about the value at step 1000. This one made a better story.