Paper: Real-time learning of decay trajectory of Higgs boson using reservoir-in-reservoir architecture (ICLR-2024)

Reviewer comment (Writing):
The paper's readability is really poor, due to several typos and incomplete descriptive content (just to mention one: figure 2 is not entirely described neither in the caption nor in the text).

Author response:
We have rewritten parts of the Introduction, Related works embedding into wider system identification literature. We have added descriptive caption to Figure 2. We have restructured the  Methods section, particularly included the learning convergence mathematics into the methods section to best explain our reservoir-in-reservoir training steps. This is in addition to the Algorithms that were available, to make the methods and algorithms tractable. We have added motivation into why this architecture has been chosen. We have also added Table 1 in the alignment that was suggested, more reservoir size exploration has been provided in the Appendix for the same. We also conducted a comparison of existing system identification algorithms pySindy, GPLearn and Monte Carlo Tree search which has been shown in Table 2. We have also updated our Results section to better describe our inferences from the tables and experiments section. We have tried to keep the sections precise and rewritten paragraphs (highlighted in blue) in the manuscript that has now been updated in the portal. We have also included an Ablation analysis of varying reservoir size, the training time steps and have reported the MSE in the Appendix section. A : We have restructured the Introduction, methods, Results and Discussion as well as Appendix. We have updated figure descriptions, addressed mathematical equations typos and grammatical errors to the best of our abilities.

Reviewer comment (Theory):
The mathematical description of the proposed approach is rather vague and not given in detail through a proper section in the paper.

Author response:
We have restructured the  Methods section, particularly included the learning convergence mathematics into the methods section to best explain our reservoir-in-reservoir training steps. This is in addition to the Algorithms that were available, to make the methods and algorithms tractable. A : In addition to the Algorithm 1 and Algorithm 2 that we had submitted which contained the mathematical steps to the reservoir-in-reservoir learning, we have added a section (marked in blue) under Methods detailing the learning convergence achieved by our forgetting enabled RLS to minimize error.

Reviewer comment (Experiments):
The experimental analysis does not provide a proper model selection approach for the crucial hyper-parameters of both the proposed model and the methods from literature; moreover, standard deviation across repetitions is not reported.

Author response:
•	Thorough model selection on both the proposed model and the baselines from the literature;  
A : We have added Table 1 for comparison of our architecture to other existing reservoir architectures

Reviewer comment (Experiments):
Thorough model selection is missing on both the proposed model and the baselines from the literature.

Author response:
•	Thorough model selection on both the proposed model and the baselines from the literature;  
A : We have added Table 1 for comparison of our architecture to other existing reservoir architectures

Reviewer comment (Experiments):
There is no comparison with fully trainable models outside the reservoir computing methodology.

Author response:
•	Comparison with fully trainable models outside the reservoir computing methodology;  
A : We have added Table 2 to compare our architecture to existing system identifiers outside RC methodology.

Reviewer comment (Writing):
The motivation of the proposed architecture, and of the reservoir computing approach overall, to the tackled problem is not clearly provided.

Author response:
•	Motivation of the proposed architecture, and of the reservoir computing approach overall, to the tackled problem;  
A : We have restructured and updated Introduction and methods section to address our motivation to this problem.

Reviewer comment (Theory):
There is no mathematical analysis of the introduced modular recurrent architecture.

Author response:
•	Mathematical analysis of the introduced modular recurrent architecture;  
A : In addition to the Algorithm 1 and Algorithm 2 that we had submitted which contained the mathematical steps to the reservoir-in-reservoir learning, we have added a section (marked in blue) under Methods detailing the learning convergence achieved by our forgetting enabled RLS to minimize error.

Reviewer comment (Writing):
Notations are overall a bit messy. For example: (1) for math symbols, sometimes they are written as math, sometimes as regular texts. (2) In Figure 2(d), the subscript range from numbers (0,1) to letters ("a","y","z"). I can't spot a consistent pattern for the notation; (3) Figure 3 (g), subscripts are missing; (4) Eq. (2), a right parenthesis ")" is missing.

Author response:
We have revised the text to remove any math symbols written as  regular text and inserted math symbols for the same. For the notation used in Figure 2d, the clarification is as follows :- Each l-g pair inside the pool receives a specific time window containing timesteps of the momentum p in the x, y and z direction. The first window consists of 0,1,2,3,…..a timesteps of p_{x}, p_{y}, and p_{z} respectively. The second window consists of a+1, a+2, a+3, a+4,…b timesteps of p_{x}, p_{y}, and p_{z} respectively. Likewise, for as many l-g pairs there will be in the pool, there will be as many windows received by the pool. In the figure the third matrix shows that for ‘n’  l-g pairs, the nth window must consist of y+1,y+2,y+3,y+4…z timesteps of p_{x}, p_{y}, and p_{z} respectively. And these momentums are annotated as p1(x), p2(x), p3(x)…pn(x) for all n windows for each direction of momentum.  We have updated Fig 3 to make the subscripts visible. We have put the right parenthesis that was earlier missing in Eq 2.

Reviewer comment (Writing):
Motivations are not unclear, see the Questions part.

Author response:
We have restructured and updated our Introduction and Methods section to highlight and clarify our motivation behind this architecture and how it achieves learning convergence.

Reviewer comment (Novelty):
What's the motivation for having both a learner and a generator in the reservior? If I understand correctly, standard reservior only have one component instead of two. Is the idea similar to generative adversarial networks?

Author response:
The motivation for having pairs of learner-generator inside the pool stems from the problem that existing reservoir architectures have. Since only the readout layer is modifiable by training, it is hard to learn heavily aperiodic systems evolving over space and time, with little room for training internal connectivity. This problem was addressed using a similar mechanism that the full-FORCE mechanism addressed. By the introduction of a secondary network, we not only modify the readouts but the internal connection matrix with weight updates. The detailed description of the learning has been updated in the methods section and in Algorithm 1 and Algorithm 2 for stepwise understanding of the loss function and its minimization through forgetting recursive least squares.

Reviewer comment (Writing):
The introduction is very verbose, and _Related Work_ lacks embedding into the wider system identification literature.

Author response:
We have rewritten parts of the Introduction, Related works embedding into wider system identification literature.

Reviewer comment (Presentation):
The _Methods_ section lacks structure, and is only tractable due to the write-up of the algorithms.

Author response:
We have restructured the  Methods section, particularly included the learning convergence mathematics into the methods section to best explain our reservoir-in-reservoir training steps. This is in addition to the Algorithms that were available, to make the methods and algorithms tractable.

Reviewer comment (Experiments):
The experiments section would benefit greatly from citations to the algorithms the approach is compared to, and could be more brief.

Author response:
We also conducted a comparison of existing system identification algorithms pySindy, GPLearn and Monte Carlo Tree search which has been shown in Table 2.

Reviewer comment (Experiments):
The results section leaves a lot of questions unanswered with regards to the performance of the algorithm, further testing of which would improve the paper significantly. One such missing element is an ablation analysis over the number of reservoirs inside of the reservoir instead of just treating it as a hyperparameter, i.e., how does the quality of the result change over the number of reservoirs?

Author response:
We have also included an Ablation analysis of varying reservoir size, the training time steps and have reported the MSE in the Appendix section.

Reviewer comment (Experiments):
Why did you choose the 3 system identification approaches over other established approaches? Have you considered adding more comparisons to further system identification approaches?

Author response:
A : We have presently included three more system identification approaches to the comparison. While the earlier three were comparisons to SOTA reservoir architectures, additionally we have added non linear identification algorithms namely pySindy, GPLearn and Monte Carlo Tree search.

Reviewer comment (Experiments):
What do you estimate the performance of your algorithm to be like in the low-data limit? Have you considered "starving" your algorithm (and others it is compared to) of data to inspect their behavior?

Author response:
A: In the ablation study mentioned above we limit the training window to see how the testing performance varies  to different length of training steps of the system. We also test the performance on the number of l-g pairs in the pool.

Reviewer comment (Reproducibility):
What tool did you use for the search space exploration for the optimal size of the pool? If it is a commonly used hyperparameter optimization tool, I would suggest concretizing this part and citing the respective tool.

Author response:
A: We did not use any existing tool for the preparation of the optimal parameters in our architecture. Instead, we applied an algorithm provided as Algorithm 3 in the Appendix to measure

Reviewer comment (Reproducibility):
Which framework, and based on which stack did you write your approach in? As is, this is left completely open and would benefit from further clarification and citation to the respective libraries.

Author response:
A: We have highlighted our programming language framework with system specifics it was tested on in the methods section.