You could use the OPF for this. What warnings about the state of the code
are you referring to?

If you want to make predictions about many fields at the same time, you'll
need to create a model for each field you want to predict. Remember that
swarming is not a part of running NuPIC, it is just a step you might want
to run before you create a NuPIC model so you can find the best model
parameters for your data. You don't need to swarm, and in fact the swarming
logic is not a part of the OPF.

It is hard to find the right model parameters for your data without running
a swarm. Without it, you end up manually tuning the model params starting
from a best guess in your head. The swarm will provide a best guess that is
more likely to be successful, and then you can manually tune the model
params from there.

My suggestion is to create one data set with all the sensor data you want
in columns, each row marked with a timestamp, aggregated and normalized so
that each row has a data value for each column (this is not necessary, as
far as I know, a value within a row might be empty if there is no data).
Then for each field you want to predict, run a swarm that defines that
predicted field, saving the model params off to the side to use later. Then
when you have model params for each field, instantiate CLA models through
the OPF for each model param, and go through your data and pass each row
into each model. Each model will be tuned to predict a specific field in
the data, so you'll have your predictions for each field.


---------
Matt Taylor
OS Community Flag-Bearer
Numenta


On Thu, Jun 26, 2014 at 2:51 PM, Beau Cronin <[email protected]> wrote:

> Hi nupic-land!
>
> I will be gathering data over a long period of time from multiple sensors
> mounted on a common platform - GPS, sound level, light level, humidity,
> temperature, accelerometer - as well as gathering data from public APIs,
> including weather and transit conditions. So, my dataset will consist of
> multiple measurement streams, measured at different temporal resolutions
> (maybe 100-1000 Hz for accelerometer, 0.1 Hz for GPS, once a minute for
> transit, etc.). Each stream will have timestamps that allow me to keep them
> in register, so I'll know how they line up.
>
> I want to build a system that learns the joint structure of these streams,
> as well as making predictions about their values in the future. I expect
> this structure to be rich and hierarchical.
>
> My question is: which level of the NUPIC API should I use to build this? I
> suspect I'll want a non-trivial region topology to capture phenomena at
> different levels and time scales, which makes me think I should at least
> use the Network level. But that's in C++, if I understand correctly, and
> I'd much rather use python. This would suggest the OPF, but the warnings
> about the current state of that code scare me - and I'd like to be close
> enough to the action that I can dig in and understand what's going on,
> rather than, say, use swarming to treat the system as more of a black box.
>
> Any suggestions appreciated.
>
> Best,
>
> Beau
>
> _______________________________________________
> nupic mailing list
> [email protected]
> http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org
>
>
_______________________________________________
nupic mailing list
[email protected]
http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org

Reply via email to