cogmission/gist:25aebc26a8f464c06298

## gistfile1.txt
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.
	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.