A very simple approach would be to trade speed for memory. Instead of storing a map between buckets and SDRs, we can go through the bucket generation process every time we want to find the SDR for a bucket. From what I understand, this bucket generation process is linear in speed with the number of buckets you want to generate. So the linear memory requirement would be translated into a linear speed requirement.
In a nutshell, walk through the number line, generating buckets until you hit the target bucket you want a representation for, *every time* you want to get a representation, and don't store anything. You'll need to use the same seed for the random number generator though, to get consistent results. The advantage of this is that it's a simple modification to what is already implemented. On the other hand, it's slightly slower when outputting SDRs for previously-seen buckets. On Mon, Feb 17, 2014 at 5:15 PM, Scott Purdy <[email protected]> wrote: > Hi all, I thought some of you might enjoy trying to come up with a > solution for this problem. If you watch Chetan's presentation about the > random distributed scalar encoder (RDSE), you will see that we are keeping > a mapping between all buckets computed so far and the bits that represent > them. This was Subutai's implementation of Jeff's general idea for the > encoder. This design has a memory usage for the encoder that increases > linearly with the number of buckets that it has to represent. > > When originally discussing the design, I was trying to find a way to > statically compute the mapping so that you don't have to store anything. > But it has to have the property that buckets i and j have w-(j-i) > overlapping bits if j-i<w and also that a given index is never assigned > multiple times to the same bucket. I came up with a solution but it would > likely have more random collisions than Subutai's linear-memory solution > because it was limited in the number of possibly combinations of bits the > buckets could have. Curious if someone can come up with something better! > > And be sure to watch Chetan's presentation on the RDSE that Subutai > designed and implemented for background. > > *Note: the current implementation is fine for all practical scenarios so > this is just a fun exercise for those interested* > > _______________________________________________ > 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
