-
Notifications
You must be signed in to change notification settings - Fork 75
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SDRClassifier: fix precision by using Real64 for PDF #667
Conversation
without this, the scores never correctly converge(learn). Thanks @Thanh-Binh for finding and solving this bug. Additionally, add some docs to the class.
use Real64 for weights_ too, make some methods const
as inference should never change internal state,
this removes updateHistory_() from inference, updateHistory code was moved directly into learn() and rest split to a new method checkMonotonic_()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- use
Real64
for weights and PDF - newly makes
infer()
const
src/htm/algorithms/SDRClassifier.cpp
Outdated
{ | ||
updateHistory_( recordNum, pattern ); | ||
Predictions Predictor::infer(const UInt recordNum, const SDR &pattern) const { | ||
checkMonotonic_(recordNum); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ctrl-z-9000-times please have a look on the last 1,(2) commits, I intended to make infer
const, as it imho should have been. For Classifier that was easy, for Predictor I had to remove the updateHistory_
from infer (no tests visibly broken).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why does it matter if infer is constant? I doubt it will have any performance impact, and I don't think this will prevent any programming mistakes.
Consider the following chain of events:
infer( t, SDR-A ) -> PDF
learn( t+1, SDR-B, Labels )
The method updateHistory
stores the given SDR inside of the predictor. Previously the call to learn
would have associated SDR-A
with Labels
since that SDR was given to infer with. Now that will not happen.
Also, these changes allow the timestamps to the infer method to go backwards.
infer( t + 2, ... )
infer( t, ... )
I'm not saying the new behavior is wrong, just that it changed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I doubt it will have any performance impact, and I don't think this will prevent any programming mistakes.
right, there won't be any performance gains, and the behavior has changed. I think it adds (expected) semantics, and better separates responsibilities of those 2 functions:
- you know only what you
learn()
- and you can
infer() const
anytime without any worry of changing the state (comes with loosened requirement for monotonic timestamps)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, that makes sense +1
@Thanh-Binh Can you please test that this branch fixes the problem with Predictor you describe in #646 ? Also, how is going your work on publishing the reproducible example for this issue? In the meanwhile, I'll try to add Predictor to the hotgym example (that also uses sine waves). |
@breznak |
the strange thing is debug mode (and gdb) is not able to detect/crash, that's a strange issue. A different solution would be removing recordNum altogether. I find it unneeded for the inference (maybe also learn) where I want to set a SDR and predict N-th next pattern/label. #675 (comment) EDIT: and actually no, this PR (removes updateHistory) does not crash, while #675 does (with update h) |
as numRecord is no longer needed for inference. API changes to bidings and tests to reflect the change. Several fixes from earlier commits in this PR, this fixes the segfaults.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- fixes
- refactored infer() to drop recordNum argument
This is now ready for your reviews.
} | ||
return result; | ||
} | ||
|
||
|
||
void Predictor::learn(const UInt recordNum, const SDR &pattern, | ||
void Predictor::learn(const UInt recordNum, //TODO make recordNum optional, autoincrement as steps |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for sequential use, even in learn()
recordNum could be made optional
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea, recordNum
is only useful if the user wants to skip time steps, which is not the common case. However when working with time series data sets, there are valid situations where you don't want to learn about a specific time-step so we should keep the time-skip capability in some form.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks fine to me.
Thanks for reviewing, followup TODOs are:
|
@breznak I do not think if remove updateHistory() from infer() is good idea, because it is thought for dynamically changing the learn and inference mode in the real-time. |
I don't understand, can you explain, please? |
without this, the scores never correctly converge(learn).
Thanks @Thanh-Binh for finding and solving this bug.
Additionally, add some docs to the class.
Fixes #646
TODO: