# Methods for predicting multiple output fields

**URL:** <https://discourse.numenta.org/t/methods-for-predicting-multiple-output-fields/7712>\
**Category:** Engineering\
**Created:** [July 9, 2020, 6:33am UTC](https://discourse.numenta.org/t/methods-for-predicting-multiple-output-fields/7712 "2020-07-09T06:33:03Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Andrew\_Stephan](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.numenta.org/andrew_stephan/32/4553_2.png) [@Andrew\_Stephan](https://discourse.numenta.org/u/Andrew_Stephan)\
**Post date:** [July 9, 2020, 6:33am UTC](https://discourse.numenta.org/t/methods-for-predicting-multiple-output-fields/7712/1 "2020-07-09T06:33:03Z")

</div>

Hi folks. As the title says, I’m wondering how to predict multiple output fields from a temporal mmory’s SDRs. For example with the well-known hotgym example, one can use a simple ML regressor to translate from the minicolumn or cell SDRs into a scalar power value, but those SDRs also contain timestamp data. What’s a practical way to simultaneously extract all of that information?

I’ve glanced through the thread here [https://discourse.numenta.org/t/predicting-multiple-output-values](https://discourse.numenta.org/t/predicting-multiple-output-values) but didn’t gain any insights about the methods used.

---

<div class="post-metadata">

**Author:** ![pkuderov](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.numenta.org/pkuderov/32/6449_2.png) [@pkuderov](https://discourse.numenta.org/u/pkuderov)\
**Post date:** [July 9, 2020, 4:01pm UTC](https://discourse.numenta.org/t/methods-for-predicting-multiple-output-fields/7712/2 "2020-07-09T16:01:39Z")

</div>

I’m wondering would n ML regressors, one for each kind of variables mixed in SDR, perform well in this case? Have you already tried it?

I think the information is still pretty separable, because each output bit:

- either mixes values of different kinds and then these mixed values are somehow correlated, i.e. loosely interchangeable (= output bit provides almost the same information regarding each of the mixed value)
- or it doesn’t mix them and they’re separate

So, as I understand, SP is a pretty good encoder in terms of preserving information.

---

<div class="post-metadata">

**Author:** ![Andrew\_Stephan](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.numenta.org/andrew_stephan/32/4553_2.png) [@Andrew\_Stephan](https://discourse.numenta.org/u/Andrew_Stephan)\
**Post date:** [July 9, 2020, 4:16pm UTC](https://discourse.numenta.org/t/methods-for-predicting-multiple-output-fields/7712/3 "2020-07-09T16:16:14Z")

</div>

That was my first thought too–I’ll try it out and see what happens.

---

<div class="post-metadata">

**Author:** ![sheiser1](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.numenta.org/sheiser1/32/766_2.png) [@sheiser1](https://discourse.numenta.org/u/sheiser1)\
**Post date:** [July 9, 2020, 6:55pm UTC](https://discourse.numenta.org/t/methods-for-predicting-multiple-output-fields/7712/4 "2020-07-09T18:55:15Z")

</div>

> [@Andrew\_Stephan](#):
>
> What’s a practical way to simultaneously extract all of that information?

I’m not sure there is a straightforward way to do that.

I think the shortest route to your goal would be to just make multiple copies of the model, one for each field you want to predict. You’d just have the tweak the `inferenceArgs` in the config file – specifically the `predictedField`.

There’s a GitHub issue for this too:

> <https://github.com/numenta/nupic-legacy/issues/1712>
>
> It would be nice if you could specify multiple fields to make predictions for.
> 
> …This will require a change to the CLAModel to support multiple classifier regions. It currently supports only one with the region name "Classifier":
> https://github.com/numenta/nupic/blob/0cc904e5835a45e541eb0cac92901271b8f91108/nupic/frameworks/opf/clamodel.py#L1117
> 
> Additionally, the OPF and description.py format will need to be updated to support multiple fields to predict. It require some changes to metrics or swarming so it knows which field (or fields?) to use for optimization.
> 
> There are two implementations of the classifier, so we will need a task in nupic.core for the C++ implementation.

It seems to be implemented in htm.core but not NuPIC if I understand, which is believable since NuPIC has been in maintenance mode for some time.