Let's look at the encoder parameters:
'sensorParams': {'encoders': {u'value': {'clipInput': True,
'fieldname': 'value',
'maxval': 6.0,
'minval': 5.0,
'n': 22,
'name': 'value',
'type':
'ScalarEncoder',
'w': 21}},
This represents how scalar input values will be encoded into bit
arrays for the spatial pooler. The "n" represents how many bits will
be in the representation of the value. "w" is now many ON BITS will be
in the representation. And you have provided a min and max value that
spans between 5.0 and 6.0. So the encoding for "5.0" might be
something like:
1111111111111111111110
That's 22 bits, 21 of which are ON. "6.0" might be encoded as:
0111111111111111111111
As you can see, the opposite extreme. "5.5" might be:
1111111111101111111111
Hopefully that makes sense. As you can see, there is **very** little
difference between the bit arrays for any representation. I don't
think these encoding parameters are best for this specific case. I
suggest you use a different encoder for your experiments that will
better represent different values. Try this:
'sensorParams': {'encoders': {u'value': {
'fieldname': 'value',
'resolution': 0.88,
'seed': 1,
'name': 'value',
'type':
'RandomDistributedScalarEncoder'}},
Here, we are using the "RandomDistributedScalarEncoder" (too see how
it works, watch this [1]) instead of the ScalarEncoder. See if that
helps your experiments?
[1] https://www.youtube.com/watch?v=_q5W2Ov6C9E
---------
Matt Taylor
OS Community Flag-Bearer
Numenta
On Tue, Apr 26, 2016 at 8:03 AM, Alexandre Vivmond <[email protected]> wrote:
> Here are parameters that I'm using for running a swarm
>
> SWARM_CONFIG = {
> "includedFields": [
> {
> "fieldName": "value",
> "fieldType": "float",
> "maxValue": 6.0,
> "minValue": 5.0
> }
> ],
> "streamDef": {
> "info": "value",
> "version": 1,
> "streams": [
> {
> "info": "Values",
> "source": "file://values.csv",
> "columns": [
> "*"
> ]
> }
> ]
> },
>
> "inferenceType": "TemporalAnomaly",
> "inferenceArgs": {
> "predictionSteps": [
> 1
> ],
> "predictedField": "value"
> },
> "iterationCount": -1,
> "swarmSize": "medium"
> }
>
>
> And here is the generated model_params.py file output
>
> MODEL_PARAMS = {'aggregationInfo': {'days': 0,
> 'fields': [],
> 'hours': 0,
> 'microseconds': 0,
> 'milliseconds': 0,
> 'minutes': 0,
> 'months': 0,
> 'seconds': 0,
> 'weeks': 0,
> 'years': 0},
> 'model': 'CLA',
> 'modelParams': {'anomalyParams': {u'anomalyCacheRecords': None,
> u'autoDetectThreshold': None,
> u'autoDetectWaitRecords': None},
> 'clParams': {'alpha': 0.00634375,
> 'clVerbosity': 0,
> 'regionName': 'CLAClassifierRegion',
> 'steps': '1'},
> 'inferenceType': 'TemporalAnomaly',
> 'sensorParams': {'encoders': {u'value': {'clipInput': True,
> 'fieldname':
> 'value',
> 'maxval': 6.0,
> 'minval': 5.0,
> 'n': 22,
> 'name': 'value',
> 'type':
> 'ScalarEncoder',
> 'w': 21}},
> 'sensorAutoReset': None,
> 'verbosity': 0},
> 'spEnable': True,
> 'spParams': {'columnCount': 2048,
> 'globalInhibition': 1,
> 'inputWidth': 0,
> 'maxBoost': 2.0,
> 'numActiveColumnsPerInhArea': 40,
> 'potentialPct': 0.8,
> 'seed': 1956,
> 'spVerbosity': 0,
> 'spatialImp': 'cpp',
> 'synPermActiveInc': 0.05,
> 'synPermConnected': 0.1,
> 'synPermInactiveDec': 0.09376875},
> 'tpEnable': True,
> 'tpParams': {'activationThreshold': 12,
> 'cellsPerColumn': 32,
> 'columnCount': 2048,
> 'globalDecay': 0.0,
> 'initialPerm': 0.21,
> 'inputWidth': 2048,
> 'maxAge': 0,
> 'maxSegmentsPerCell': 128,
> 'maxSynapsesPerSegment': 32,
> 'minThreshold': 9,
> 'newSynapseCount': 20,
> 'outputType': 'normal',
> 'pamLength': 1,
> 'permanenceDec': 0.1,
> 'permanenceInc': 0.1,
> 'seed': 1960,
> 'temporalImp': 'cpp',
> 'verbosity': 0},
> 'trainSPNetOnlyIfRequested': False},
> 'predictAheadTime': None,
> 'version': 1}
>
> On Tue, Apr 26, 2016 at 4:33 PM, Matthew Taylor <[email protected]> wrote:
>>
>> What are the encoder parameters you're using to encode these numbers?
>> 5 and 6 might be close enough that they get encoded as the same bit
>> array. What are your min/max values for the scalar encoder? Or are yo
>> using another encoder?
>> ---------
>> Matt Taylor
>> OS Community Flag-Bearer
>> Numenta
>>
>>
>> On Tue, Apr 26, 2016 at 3:32 AM, Alexandre Vivmond <[email protected]>
>> wrote:
>> > I've got a question regarding patterns and noise. I've experimented a
>> > bit
>> > with HTM now, and I can get it to learn a wide variety of varying
>> > patterns
>> > such as for example: 1, 2, 3, 1, 2, 3, 1,... or 5, 6, 5, 6, 5, 6, ...
>> > but
>> > patterns such as 5, 5, 6, 5, 5, 6, ... or 5, 5, 5, 5, 5, 5, 5, 5, 5, 6,
>> > 5,
>> > 5, 5, 5, 5, 5, 5, 5, 5, 6, ... are things that HTM struggles with, which
>> > is
>> > understandable considering HTM is really good at creating "links"
>> > between
>> > values with respect to time and context. But the previously mentioned
>> > example makes it really hard to create "links" between self-repeating
>> > values, even though HTM can manage to differ between contexts. So what
>> > exactly is the "line" between a pattern and noise? I fed HTM 20000
>> > values of
>> > 10 fives followed by one 6 (5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 6, 5, ...) and
>> > it
>> > still didn't manage to learn that pattern. Any ideas?
>>
>
