OPF time encoder parameter questions


For the model params, are ‘n’ and ‘w’ really equal to just 29 and 21? In the params file it says that for the scalar encoder, though I thought that ‘n’ had to be many times larger than w?

Also where can I find the ‘n’ and ‘w’ values for the time of day and weekend params? There are a couple of ‘21’ values there but they paired with ‘6.09’ and ‘1’, which seem strange. I’m trying to replicate NuPIC’s results with my own implementation and want everything to line up as closely as possible. Thanks!!

Here’s the file I’m referring to:

About hotgym demo

I’m not exactly sure where that snippet comes from, but I believe those values are forced into integers. The probably have decimals because they were produced by swarming years ago honestly.

Remember that this encoder is going to play a part in a larger encoding. To know if w is too large within n, you really need to know the combined n and how much space the sub-encoding takes up. :thinking:

Also, check out this cyclic encoder display I’m working on (not sure how long that link will be valid). In this viz, n = bits and w = range. I’m going to try and explain the concept of buckets with this visual soon.


Thanks @rhyolight

The code snippet comes from rec_center_hourly_model_params.py file in the ‘…hotgym/anomaly/one_gym/model_params’ folder.

So can I interpret the ‘21’ and ‘6.09’ values for ‘timestamp_timeOfDay’ as n and w? And the 21’ and ‘1’ values for ‘timestamp_weekend’ as n and w? If this were the case, then the total n = 29+21+21 (71) and total w = 21+6+1 (28)? Does this sound plausible?


Those values are not exactly n and w. Yes, the 21 is the number of bits the encoder produces, which is n. But 6.09 is actually the number of buckets, or unique values the encoder can recognize.

If you look at the same parameter set you showed, there is a weekend encoder in there with values [21, 1] which means 21 bits out, and 2 buckets (0 & 1). You only need two values to represent weekend or not.

Watch this space, I’m going to have a whole section on cyclic encoders and how they can be used both for discrete categorical encoding or continuous scalar encoding.


Ok that helps! So for the timeOfDay encoder ~6 distinct values over 21 bits would mean a w around 4, and for the weekend encoder 2 distinct values over 21 bits would mean a w around 10. These two n values of 21 plus the 29 from the scalar would mean a total n of 71.

Even with this concatenation, isn’t it still the case that the scalar values are totally capped within 29 of the bits? It just seems like this crams the whole scalar range into a really tight space, since the min value would be encoded by bits 1-21 and the max by bits 9-29. Doesn’t this effectively create too few buckets with too much overlap between them? Wouldn’t all mid-range values look nearly identical to the SP?