Additional dtype checking on SP compute input

We are about to merge a PR that will enforce stricter type checking on SP compute. It could break current clients of NuPIC if you happen to be sending in the wrong array type. If so, you’ll get an error that looks something like this:

Expecting 'unsigned int' but got 'f' [/path/to/nupic.core/src/nupic/py_support/NumpyVector.hpp line 462]

or:

Expecting 1D array but got 2D array [/path/to/nupic.core/src/nupic/py_support/NumpyVector.hpp line 454]

This means you are sending floats instead of ints (or the wrong array dimension).

Thanks for notifying us! Currently, I’m expecting a numpy array of type nupic::UInt . Do you think I should change that to UInt32?

BTW, in python 3 sending floats doesn’t work anyways, I think.

I don’t think you need to do anything. We did not make that change in nupic.core, so I don’t think you’ll need to. Do you have a view on that @lscheinkman?

Currently nupic::UInt is defined as nupic::UInt32 so there is no need to change anything.

When you define “NTA_BIG_INTEGER” nupic::UInt can become NTA_UInt64, no? I’m looking at types/Types.h

This whole logic of defining single or double precision OR big or normal integer seems a bit sketchy. Has this ever been tested?

Yes this is older “legacy” code and it could be sketchy. I’m not sure how well it is tested. I have not run a NuPIC core test coverage report in years.