Anomaly removal, cleanup

[breznak]

I have revisited the Anomaly class and I'd like to propose a removal, cleanup of said class, keeping only the computeRawAnomalyScore() method, and possible a (new)
Anomaly::compute(SDR) which has only 1 parameter, and handles the bookkeeping of previous pattern for anomaly.

This will make the code simple, help some confusion in documantation of that class, ...

• implement TM::anomalyScore()
  • remove class Anomaly
    • what happens with AnomalyLikelihood?
• move VectorHelpers::columnsFromCells() to TM, as the method is only correct for TM's mini-columns, see Connections better use typedefed types Segment, Synapse, ... #331 (comment)
  • implement output const SDR TM::active/predicted/both
• figure predicted vs. pred + act for previous values

[ctrl-z-9000-times]

I haven't looked into this, but i was thinking anyways. Maybe the TM could have a conveience method to compute the anomaly?

[breznak]

Maybe the TM could have a conveience method to compute the anomaly?

yes, I'm thinking in this direction too.

• TM could have its anomaly
• SP could implement a spatial anomaly
• CP would do it as well

[breznak]

Maybe the TM could have a conveience method to compute the anomaly? [and Anomaly is removed]

This will also depend on decision in #95 , if TP/Cells are removed, Anomaly would be only used by TM, so it'd be trivial to move it there (and rm Anomaly class)
Otherwise we need to support TP, BackTM with anomaly, so a radical cleanup (of An class) would be a better option.

[ctrl-z-9000-times]

Ok, I looked into this some more. I think the best option would be to fully merge the anomaly class into the TM, and remove the anomaly class. There is too much logic that needs to be done to prepare the data for the anomaly class, for example from TM unit tests:

// Get the predictions from the previous cycle.
tm.activateDendrites(true, ... );
auto predictedColumns = tm.getPredictiveCells();
// Convert from cells to mini-columns
for(UInt i = 0; i < predictedColumns.size(); i++) {
  predictedColumns[i] /= tm.getCellsPerColumn();
  if(i > 0 && predictedColumns[i] == predictedColumns[i-1])
    predictedColumns.erase( predictedColumns.begin() + i-- );
}
// Calculate TM output
const auto &sparse = x.getSparse();
tm.compute(sparse.size(), sparse.data(), true);

// Calculate Anomaly of current input based on prior predictions.
anom = algorithms::anomaly::computeRawAnomalyScore(
                              x.getSparse(), predictedColumns);

Notice that in order to use the Anomaly class the user needs to use the split compute - activateDendrites & activateCells.

[ctrl-z-9000-times]

This will also depend on decision in #95

I posted a request for comments about the backtracking TM on the forum. In two weeks we should know if we're going to support or delete it. In the mean time I'm going to direct my attention to #335 and other things.

[dkeeney]

I posted a request for comments about the backtracking TM on the forum

Thank you. Nicely done by the way.

[breznak]

posted a request for comments about the backtracking TM on the forum.

can you post a link please, I couldn't find it at the forums.

[ctrl-z-9000-times]

Link to forum survey about backtracking TM: https://discourse.numenta.org/t/biological-constraints/5687

[ctrl-z-9000-times]

@breznak,

I think you can get started with, if you're interested that is. You don't need to wait until the survey I posted is complete. Regardless of what happens to the backtracking TM, we should still incorporate the Anomaly into the regular TM. For now, since we're not yet deleting any files, the TM can simply delegate the work to the Anomaly functions.

The method TM.rawAnomalyScore() would be immensely useful for testing the TM. It would also help us prototype a good API.

Also, the ColumnPooler does not need it's own implementation of Anomaly. The ColumnPooler contains a TemporalMemory instance and will call the TM's anomaly method.

[breznak]

Added TODO that VectorHelpers::columnsFromCells should be moved to TM, #331 (comment)

[breznak]

I'll start with this issue, one more thing we need to make clear:
"what is considered for 'activations' from previous step?"

• Anomaly works with TM's minicolumns, not cells directly!
• the definition in "py code for Anomaly" is vague, and the code-sample Anomaly removal, cleanup #347 (comment) is not 100% correct either (I wasn't certain when writing it)
  • you may want to revisit py code for Anomaly to get the clear definition
  • "The raw anomaly score is the fraction of active columns [at time T][Q1 only feed-forward activations-so output from SP, or also contextual activations from other cells- so current T TM active?] not predicted [at time T-1][Q2 predicted is taken from TM, is it only pred, or {pred + active}?]."
    • definition from Anomaly.hpp, [comments mine]

[ctrl-z-9000-times]

The raw anomaly score is the fraction of active mini-columns which were not predicted.

Q1: only feed forward activity. By the time the feed forward activity reaches the TM, it will be a list of active mini-columns.
Q2: only predictions. A mini-column is predicted if any of its constituent cells were predicted.