Greetings Earthlings (and otherwise affiliated),

This new tip is more of a recommendation. Actually, its more of an extreme “urging”… 🙂

Within algorithmic process, there are many calls to the random number generator (RNG) during both phases:

  • Initialization: In order to choose which inputs in the input vector get mapped to which receiving columns of the SpatialPooler. Also in order to setup up the vector containing a pre-configured random noise amount to apply to “ties” for those times when the inhibition phase has more than one column with the same highest permanence. In addition, the “amount” of permanence a given proximal synapse (synapse connected to the SpatialPooler’s columns and to the input field vector; as opposed to a distal synapse which is a synapse between cells in a column and which form lateral connections) – as its initial permanence.
  • Runtime: In order to select the set of learning cells for a given distal dendrite, eliminating the formation of synapses to duplicate target cells; and in order to select a cell to “learn on” from all bursting cells for active columns which weren’t predicted by cells in t – 1.

So as you can see, the RNG is called a lot during the execution of an HTM’s algorithms; and therefore there is an opportunity for optimization of those features if we can find a more efficient implementation.

Luckily, Mike Lucchetta (@antidata on github), 2nd place winner of last November’s Numenta HTM Challenge (see all the challenge winners here) found an RNG algorithm that increases performance by an incredible amount (enough to write a whole blog about!). Here’s what Mike says:

The experience was similar to the traffic example, I only replaced the Random Number Generator with a different one to gain ~600% of processing speed and less memory consumption…



So our recommendation is to use the new RNG called (instead of the project’s default: by specifying it within your Parameters object via:

Parameters params = … (for info on the many ways and forms of creating a Parameters object)

params.setParameterByKey(KEY.RANDOM, new FastRandom(42)); // Use a seed (42 or other) for determinacy.


Taking advantage of this easy tip could really increase the performance of within your application. The only reason is it not yet the default is because we’d have to go through and change a great deal of unit tests to account for the expected difference in determinant outcomes (which we will have to eventually bite the bullet and do anyway) :-/


Happy Hacking!




Leave a Reply Text

Fork me on GitHub