Passing a reset signal to TMRegion from a Python region triggers an assert
Linking the reset signal from a Python region to a TMRegion in a HTMNetwork triggers the assert:
NTA_ASSERT(reset.getType() == NTA_BasicType_Real32) in line 193 of TMRegion.cpp.
The reset field in the output of the Python region is correctly of the type float32. I am guessing that this may be a Numpy2 issue since this was not a problem with Numpy1.
I have temporarily removed this line from TMRegion.cpp and my project works correctly. All htm.core unit tests still pass as well so this suggests that a test for this use case could be added.
Oh, be careful here... If the data type is not Real32 ... like maybe Real64 (a double), and we cast it to Real32 (a float) then we are only looking at half of the bits in the value. We could get the wrong results. The layout of bits in the two are not the same.
However for the reset operation, we are only looking to see if it is 0 or something else. So if it is not 0 then it does the reset. I think, in most cases, the value will be either a 1 or a 0 and casting might accidentally get the correct answer just because a 0 is all bits off and a 1 value has some bits on in the lower part of the variable's field width.
A better solution would be to do the following:
// Handle reset signal
if (getInput("resetIn")->hasIncomingLinks()) {
Array &reset = getInput("resetIn")->getData();
if (reset.getType() == NTA_BasicType_Real32) {
if (reset.getCount() == 1 && ((Real32 *)(reset.getBuffer()))[0] != 0) {
tm_->reset();
args_.sequencePos = 0; // Position within the current sequence
} elseif(reset.getType() == NTA_BasicType_Real64) {
if (reset.getCount() == 1 && ((Real64 *)(reset.getBuffer()))[0] != 0) {
tm_->reset();
args_.sequencePos = 0; // Position within the current sequence
}
}
else {
NTA_ASSERT(false) << "the data type of resetIn of TMRegion was unexpected";
}
}
}
@dkeeney except for elseif instead of else if that works fine. All tests passed and my project runs correctly.
@fcr Sorry about the typo. Did you submit a PR for this? If so, let's merge it.
@dkeeney, I posted PR #1034