-
Notifications
You must be signed in to change notification settings - Fork 3
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
Refact: StreamTask, OATask - order of processing/adaption on new/obsolete instances #988
Comments
@steveyuwono @syamrajsatheesh this heavy design weakness came to my notice during working on SPARCCStream. Unfortunately, the resulting changes are extensive. But better now than after releasing MLPro 2... What is your opinion? Do you see a better way to solve this? |
Hi @detlefarend , what do you mean by block-wise? Regarding the order of processing the instances, I agree with the idea of ordering based on its timestamp rather than first the addition and then the deletion. Regarding the proposed solution, a dict is a good solution as the new parameter. |
Hi @steveyuwono, with block-weise I mean that we currently process all new instances in method _adapt() before we process all obsolete instances in method _adapt_reverse(). Ok, I will do the refactoring tomorrow in a separate branch. The best is to merge everything to main before. Any doubts, better ideas, last words? |
Okay, sounds good! Nothing else from my side... |
@laxmikantbaheti I already refactored the normalizers due to the new stream instance management (see oa.streams.tasks.OATask, run() and adapt()). I also added numerous further howtos to validate every single oa task in 2d/3d/nd mode. Two things are not yet solved:
|
@laxmikantbaheti I also started refactoring oa.systems. Here further things are to do. I added a brief description to the issue. |
Motivation
Currently, methods StreamTask.run() and OATask.adapt() get instances to be processed in two different parameters
As a result, both lists are processed separately and block-wise.
Since an instance has a unique time stamp (see issue #987) the processing/adaptation should take place in an overall order by time stamp.
One possibility is to replace parameters p_inst_new, p_inst_del by a new parameter
Benefit
Processing/adaptation is much more plausible than before.
Are the proposed changes backward compatible?
Related development objects
Plot raw/normalized should be identical (except scaling)...
Plot raw/normalized should be identical (except scaling)...
Plot raw/normalized should be identical (except scaling)...
The text was updated successfully, but these errors were encountered: