POPxf: An Exchange Format for Polynomial Observable Predictions

1-give a common format for prediction to allow reproducibility/further usage/validation

1-The format is not very readable for large polynomials/large number of polynomials/observables
2-Several explanations/examples are not very clear
3-Format is not easy to implement and can be error-prone

The proposed format does not seems very readable and therefore more prone to errors.
The explanations are sparse and the reader need to guess a number of things.
More details are given in the list of requested changes

1-Last sentence of third 3rd paragraph of p3 "The format supports ..." is not clear 2-Many array are, I believe, 1D array, this should be made clear 3-Discuss the polynomial observable assumption for uncertainties and correlation, why is it a good one, when does it breaks,... 4-Define what is a sector of related observables 5-Justify the use of multiple files and how to make sure that they all remain consistent with each other 6-Clarify last sentence of the first bullet point (maybe with an example) 7-Beginning of p6, why define o_m^n and p_m^n if they are equal 8-Since the user define the expression and the Taylor expansion of FOP, they could not match, could it be done automatically or could it be tested 9-Why only one expansion parameter (epsilon) in Eq .15?Justify and can it be expanded? 10-Why the assumption of Gaussian uncertainties since theory uncertainties are rarely Gaussian, why not using multiple value of the variable as a function of the renormalisation scale, pdf, ... 11-In 3.2, exchanging 1 (FOP) and 2 (polynomial) would probably improve the comprehension 12-last sentence before 3.3, is it checked or just assumed that the user did so 13-for the reproducibility, why not use the full banner of the tools as done by the les houches formats to have the full information and not only the one the user think is relevant 14- To make the paper self-contained, add a brief explanation of WCxf 15-add an explanation for each example : what they mean 16-p16length and order of the array must match.... error-prone and not readable if large. 17-p16 why introduce a variable name for the polynomials and not have a 'python name' for them only 18-last sentence is not precise enough, which functions/packages ... 19-End of p17 P_k and O_m seems redundant 20-There seems to be a scale for each polynomial, how is this treated in the correlation between them? 21-why write c^4 as {c,c,c,c}, 1 as {'',''}, it is much harder to read and more error-prone, the real and imaginary at the end of the monomial is going to be hard also if it is long. The polynomial coefficients are arrays of all the polynomials for 1 monomial, again, it is hard to read if they are many polynomials 22-p33, why is there 12 digits for some coefficients and 3 for some others 23-top example, how is this file connected to the other one, through the long code at the second line, there should be a file name and version.

Ask for major revision

The authors present a novel format to exchange observables in a polynomial form that is suited for high-energy computer tools. The format is based on the JSON standard or alternatively on the HDF5 format in the case of larger sets of observables. Such types of formats that are endorsed by a large part of the community have proven to be useful in the past. The effort of the authors to opt for such a common format that facilitates data exchange among different implementations is commendable. Before recommending the article for publication I suggest to consider a few points.

1. In sec. 2.3 the notation gets a bit heavy on indices, especially between eq.(16)-(19). A simple example would be helpful to illustrate what is meant.

2. Since one of the goals of the format is reproducibility of the results, it might be beneficial that the documentation part in a POPxf file becomes a mandatory field to be filled in. This would enforce best practice in the community.

3. In the future it might be beneficial that users of this format can upload their observables on a common platform. This could for example be the github webpage where the format is already hosted.

Furthermore, I suggest a few minor alterations to the manuscript.

1. Some standard references should be included, for example to the SMEFT/WET, Warsaw basis etc.

2. On p. 17 at the bottom, it is not clear why the $a_k$ do not depend on the renormalization scale. The authors might want to elaborate on it.

3. In fig. 1 it would be helpful to indicate in the legend that the white boxes are optional.

4. One might also mention in the article which codes do already support this format and which ones might be likely/suitable to implement it in the (near) future.

5. Punctuation in eq.s (21), (23), (24), (27), (28), (33) is missing.

6. p. 6. line 2: coefficient -> coefficients

Ask for minor revision