uproot5
Pluto.jl
uproot5 | Pluto.jl | |
---|---|---|
2 | 78 | |
218 | 4,880 | |
1.4% | - | |
9.2 | 9.5 | |
5 days ago | 4 days ago | |
Python | JavaScript | |
BSD 3-clause "New" or "Revised" License | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
uproot5
-
Potential of the Julia programming language for high energy physics computing
> I wasn't proposing ROOT to be reimplemented in JS. That was what the GP attributed to me.
Sorry for assuming that. I really felt the pain of thinking of possibility of combining two things I hate so much together (JS+ROOT)
> "Laypeople" may also think that code is optimized to the last cycle in something like HEP simulations. It's made fast enough and the optimization is nowhere near the level of e.g. graphics heavy games.
I understand that in other areas there might be more sophisticated optimizations, but does not change things much inside HEP field community. And it is not optimized only for simulations but for other things too. It is not one problem optimization.
> Real-time usage like high frequency large data collection will probably never happen on the "single language". But I'd guess ROOT is not used at that level either? Also at least last time I checked, ROOT is moving to Python (probably not for the hottest loops of the simulation though).
I did not mean to indicate that ROOT is being used to handle the online processing (In HEP terms). It is usually handled via optimized C++ compiled code. My idea is that you will probably never use JS or any interpreted language (or anything other than C++ to be pessimistic) for that. ROOT at the end of the day is much closer to C++ than anything else. So learning curve wouldn't be that much if you come with some C++ knowledge initially.
> Also at least last time I checked, ROOT is moving to Python (probably not for the hottest loops of the simulation though).
I think you mean PyROOT [1]? This is the official python ROOT interface It provides a set of Python bindings to the ROOT C++ libraries, allowing Python scripts to interact directly with ROOT classes and methods as if they were native Python. But that does not represent and re-writing. It makes things easier for end users who are doing analysis though, while be efficient in terms of performance, especially for operations that are heavily optimized in ROOT.
There is also uproot [2] which is a purely Python-based reader and writer of ROOT files. It is not a part of the official ROOT project and does not depend on the ROOT libraries. Instead, uproot re-implements the I/O functionalities of ROOT in Python. However, it does not provide an interface to the full range of ROOT functionalities. It is particularly useful for integrating ROOT data into a Python-based data analysis pipeline, where libraries like NumPy, SciPy, Matplotlib, and Pandas ..etc are used.
> Off-topic: C++ interpretation like done in ROOT seems like a really bad idea.)
I will agree with you. But to be fair the purpose of ROOT is interactive data analysis but over the decades a lot of things gets added, and many experiments had their own soft forks and things started to get very messy quickly. So that there is no much inertia to fix problems and introduce improvements.
[1] https://root.cern/manual/python/
[2] https://github.com/scikit-hep/uproot5
-
Root with python
Besides PyROOT, you can also use uproot to read ROOT files, if you want to avoid the ROOT-dependency. The current version (uproot4) does not yet support writing ROOT files, but the previous/deprecated version (uproot3) does. (Please note: uproot is not maintained by the ROOT project team).
Pluto.jl
-
Potential of the Julia programming language for high energy physics computing
I thought that notebook based development and package based development were diametrically opposed in the past, but Pluto.jl notebooks have changed my mind about this.
A Pluto.jl notebook is a human readable Julia source file. The Pluto.jl package is itself developed via Pluto.jl notebooks.
https://github.com/fonsp/Pluto.jl
Also, the VSCode Julia plugin tooling has really expanded in functionality and usability for me in the past year. The integrated debugging took some work to setup, but is fast enough to drop into a local frame.
https://code.visualstudio.com/docs/languages/julia
Julia is the first language I have achieved full life cycle integration between exploratory code to sharable package. It even runs quite well on my Android. 2023 is the first year I was able to solve a differential equation or render a 3D surface from a calculated mesh with the hardware in my pocket.
- Pluto.jl: Simple, reactive programming environment for Julia
-
Ask HN: Why don't other languages have Jupyter style notebooks?
Re Julia there is also pluto.jl that is another notebook-like environment for julia. It's been a few years since I played with it but it looked cool, for example it handles state differently so you don't get into the same messes as with ipython notebooks. https://plutojl.org/
- Pluto: Simple Reactive Notebooks for Julia
-
Looking for a Julia gui framework with a demo like EGUI
For this, Notebooks are often used. Julia offers a uniquely nice and interactive Pluto notebook for the web https://github.com/fonsp/Pluto.jl
- Excel Labs, a Microsoft Garage Project
-
IPyflow: Reactive Python Notebooks in Jupyter(Lab)
I believe this is what Pluto sets out to do for Julia.
I used it as part of the “Computational Thinking” with Julia course a year or two back. Even then the beta software was very good and some of the demos the Pluto dev showed were nothing short of amazing
https://plutojl.org/
- For Julia is there some thing like VSCode's python interactive window?
-
What have you "washed your hands of" in Python?
I think what you want is Pluto!
-
Show HN: Out of order execution in Jupyter notebooks is a solved problem
I like how Pluto.jl handles this:
> Pluto offers an environment where changed code takes effect instantly and where deleted code leaves no trace. Unlike Jupyter or Matlab, there is no mutable workspace, but rather, an important guarantee:
> At any instant, the program state is completely described by the code you see.
[1] https://github.com/fonsp/Pluto.jl
What are some alternatives?
uproot3 - ROOT I/O in pure Python and NumPy.
vim-slime - A vim plugin to give you some slime. (Emacs)
awkward - Manipulate JSON-like data with NumPy-like idioms.
rmarkdown - Dynamic Documents for R
pyhf - pure-Python HistFactory implementation with tensors and autodiff
Weave.jl - Scientific reports/literate programming for Julia
vaex - Out-of-Core hybrid Apache Arrow/NumPy DataFrame for Python, ML, visualization and exploration of big tabular data at a billion rows per second 🚀
Dash.jl - Dash for Julia - A Julia interface to the Dash ecosystem for creating analytic web applications in Julia. No JavaScript required.
iminuit - Jupyter-friendly Python interface for C++ MINUIT2
IJulia.jl - Julia kernel for Jupyter
vddfit
Tables.jl - An interface for tables in Julia