views:

585

answers:

3

I'm a modest graduate student in a high energy particle physics department. With an unfounded distaste for C/C++ and a founded love of python, I have resorted to python for my data analysis so far (just the easy stuff) and am about to attempt backing python scripts against ROOT libraries and, particularly, utilize MINUIT for some parameter minimization.

As well as asking if anyone has any tips for the installation and usage of these, I wondered if it was worth it to even attempt it or just to slip into the "norm" of using C/C++, or if things like pyminuit are usable. Or do you think I could wrap entire C/C++ scripts into python code to make use of my existing self-written analysis methods (I have no wrapper experience as of yet). Sorry for the vagueness; I'm headed into a great unknown that far outweighs my current experience.

+2  A: 

I think that you will get more ideas at Root Talk.

Anonymous
A: 

It's not really an answer per se, but coming from someone in a similar situation (grad student in physics who loves Python ;-) it would be fabulous if you can come up with a good interface between Python and popular C/C++ physics software like ROOT, especially if you can make it compatible with Numpy/Scipy where applicable. As I'm sure you know, Python is a whole lot easier to work with than C or C++, especially because the interpreter allows us to test things out quickly and determine algorithms by trial-and-error a lot more efficiently than with C or C++; it's also great not to have to worry about things like memory management. Really, the only reason that scientists are still stuck on Fortran and C is that nobody's had the time to wrap the large libraries of existing code into newer, more user-friendly languages.

David Zaslavsky
"[we're] still stuck on [old languages is] nobody's [] wrap[ed] the [] existing code into newer [] languages." Don't underestimate the raw processing demands of both data acquisition and analysis in large projects. There are times when you code close to the hardware for a reason.
dmckee
Come to think of it, the computational guys really beat up their clusters, too.
dmckee
Believe me, I know... that's why we have things like Numpy/Scipy, to take advantage of the raw power of C or Fortran while maintaining the friendly interface of Python.
David Zaslavsky
Even then, I think that pure C/C++ or Fortran codes win on the speed front. We have to bow a bit in that way to enjoy our wonderful syntaxes and interfaces. If you're clever and resourceful, you can close the gap with Python; remember Python's roots, too! (Ha. root.)
vgm64
@vgm64: The "easy stuff" is done in ROOT's macros by most people anyway (ugly but easy), and most "heavy stuff" is done in the compiled libraries. There is no reason one shouldn't use pyROOT which makes writing macros a lot cleaner since one doesn't have to take care of ROOT strange pointer-centric interfaces. And in newer ROOT versions pyROOT allows you to do pretty much anything you could do in ROOT macros (you will probably need python's array module though).On top of that, `ipython` is so much more pleasant than `cint`.
honk
@honk: Agreed. pyROOT wouldn't compile/import correctly on my system when I tried it a few months after this post (and I learned a significant amount about it), and only just recently did I get it up and running. For doing ROOT with python, nothing is better.
vgm64
+2  A: 

You are aware of pyROOT, right?

Never tried it myself, so I don't know how it might stack up against your needs.

dmckee
It took nearly a year but I finally got pyROOT working and find it is the best solution.
vgm64