-
Notifications
You must be signed in to change notification settings - Fork 9
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
predict.py node / probability accumulation : Usage clarifications #12
Comments
Hi, Apologies for answering only now. The
|
Hello,
As previously mentioned in the timeflux main repo issues, I'm trying to use the nodes exemplified in the c-VEP speller.
Beyond the classifier, I'm stumbling a little bit in correctly understanding how to use the different arguments properly and perhaps to correctly understand the functioning of the node (speller/CVEP/speller/nodes/predict.py).
Particular questions :
Digging into this node inner working, I believe I must change the "trigger" of the "epoch" node in my pipelines, so as to have one by cycle instead of one by trial (of several cycles) as I had until now.
One confusing aspect for me is also the "buffer-related arguments" of 3 nodes : epoch (param: buffer), classification (param: buffer_size), and predict (params, min_buffer_size and max_buffer_size). I understand that the 2 first ones are related to buffer normally unnecessary signal in case of delay of transmission of events, whereas the predict buffers are relating to number of repetitions minimal/sufficient to broadcast a probability/classification. However, the practical consequences of these 2 arguments are a not yet straightforward to me.
Finally, the necessity and ways to implement the "reset events" (in the i_reset port) are not clear to me neither. I believe I'm supposed to emit an event on this port at the end of a trial, but the format that these reset events must take is not crystal clear. I can see that it is possibly a dataframe with a "label" column "reset_{source}_accumulation". One ambiguity for me, it could be a reset of the accumulated 'calibration' data, or the reset of all the cycles after each trail is over during the test phase (predict_proba).
I hope that the uncertainties I raised are understandable in how I explained them, and am looking forward for clarifications of these various interesting nodeq which are core to the superiority offered by timeflux for live time-series ML pipelines.
Best,
Julien
The text was updated successfully, but these errors were encountered: