Skip to content

Instantly share code, notes, and snippets.

@cogmission
Last active August 29, 2015 14:09
Show Gist options
  • Save cogmission/25aebc26a8f464c06298 to your computer and use it in GitHub Desktop.
Save cogmission/25aebc26a8f464c06298 to your computer and use it in GitHub Desktop.
Encoder terminology is (i.e. variable names) confusing
Dylan Wilson asked this question:
> Also, I wanted to bring up a larger question about what our goals with the Java version is. For
> example, the variable names in the ScalarEncoder are pretty bad... w is described as "width" but
> getWidth returns n. Are we trying to maintain some connection to the Python code or are we free to
> fix these kinds of things ?
Good question. Yes we should maintain a definite connection with the Python code, and if we detect
"issues" with it, we should also correct the Python version and keep them in lock step. The main goal
is to provide a 100% compatible version of NuPIC, just in another language. Both the Python, and the
Java version should benefit from any issues discovered. This has been my treatment and has resulted
in the correction of a few issues in the Python version thus far.
Specifically wrt your question. "w" is the number of on bits used in the output encoding, and there
is a "bug" in the documentation describing it as the "width" - which shouldn't be. "Width" in the
context of the "getWidth()" method is actually a reference to the total number of output bits and
should be "getNumOutputBits()" or something... You should bring this up to Matt (@rhyolight) and he
can direct you as to how to get this handled. I agree, the terminology is confusing and the variable
names need to be made more clear. In my opinion we should refrain from using the term Width or W
because it breaks down when you have a topology of more than one dimension anyway.
@david-ragazzi
Copy link

How about
w=>valueWidth
n=outputWidth
?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment