-
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
Improve pineappl plot
Python interaction
#249
Comments
This is not urgent at all, it is just a consideration that came to my mind reading #248, nothing more. |
I had similar considerations in the past, but
That being said I believe the plotting script(s) and functionality can be significantly improved. I was thinking of using a templating engine in such a way that the template is really kept in one file. This mostly is the case right now (in this file: https://github.com/NNPDF/pineappl/blob/master/pineappl_cli/src/plot.py), but writing out the data could be improved, for instance. |
Regarding the data handling, I see your point. However, I prefer to keep things separate, and rather gather through other means (e.g. folders or archives), since it makes it easier to consume them even for further purposes. The idea of moving to Python is really to avoid the template (with or without a suitable engine). This is because I appreciate more libraries than code generators (less copy-paste, version management, and similar benefits). They are even easier to test and debug, because they are native in the language they are written in (while you'd need to use Python to test the script generated from Rust). Since this part of the CLI functionality is already mostly Python, I would expose the interface through Python. P.S.: regarding point 4., the proposal was to write a Python function |
I think the crucial point that you dispute is whether we want to directly output the generated plot or a plotting script that in turn generates the plot (where the code sits is another question). I chose the latter for several reasons:
I don't think you can avoid having a code generator, unless you invent an API that sits on top of matplotlib, for instance (is that what you meant?). However, I don't see the added value of that - for me matplotlib IS the API to plot the data. Which advantages do you see? |
Actually, this is the whole point, and nothing else. Consider that partly you're already making such an API: pineappl/pineappl_cli/src/plot.py Lines 104 to 161 in e71b39a
and the functions present have already enough arguments to be very customizable, without the need of patching them pineappl/pineappl_cli/src/plot.py Lines 275 to 284 in e71b39a
The idea is that, if you want to do something very basic, your script could be a regular Python script, possibly with 3-4 lines only, importing |
The API would be just the script, maybe slightly rearranged, but no more. I.e.:
Content of 2. and 3. are most likely always repeated. The last is just what we were discussing at the beginning. |
Currently,
pineappl plot
relies on Python and Matplotlib. This is actually quite nice, because people using PineAPPL are often familiar with Python, and know how to plot the information, once given.A current mild pain-point is that there is a lot of string manipulation involved in the call, since a Python script is generated everytime, embedding the data:
pineappl/pineappl_cli/src/plot.rs
Lines 508 to 521 in 3476629
However, dumping the script is a design featured, in such a way that people are able to customize it.
I see a few possible ways of improving:
pineappl plot
operations: dump the script and the data separately (in a common data format, like CSV)pineappl_py
in the script, and directly extract the data from the grid (requires the installation of the PineAPPL python extension)pineappl_py
itself (possibly with apineappl-plot
CLI, but it would be installed separately, at least until Distribute CLI as a Python package #176 will be completed)The text was updated successfully, but these errors were encountered: