I added support for python's long type; however, (py)ROOT is not writing out branches properly when they are given np.int64 types. As a temporary fix, pytree will cast long to int, but this is not ideal.

This doesn't really describe what it does; generically, it just manages an underlying data object (and a fallback manager), and calculates things on-demand.

need to add a feature so that each Variation run can output to its own TTree (within a global output file?). Each variation should output only the minimal amount (i.e. don't duplicate "nominal" calculables, or input branches).

Currently pytree can infer nested types and create branches for them, but I need to do a bit more work to actually automate the write-out. Mostly this is problematic because nested vectors implies you'll have to create new vector objects for every fill. And often this is not exactly what we want; it would sometimes be better to only clear()/push_back() on the innermost vectors. How to deal?

It would be good to have a more quantitative idea of how much an effect the profiler will have on a real analysis. I am sure it will slow things down a bit, but it's unclear whether it is significant.

I haven't done this myself before, so I'll have to look into it...

right now everything's in the top-level directory, which makes imports awkward (i.e. you have to add path containing analysis_utils to PYTHONPATH...)

time to reorganize and write a distutils setup.py script!

As detailed in c63ae63, the new DPDObject copy semantics make use of a shared dictionary object to cache TTree lookups. This means less memory and less copying time for (variational) analyses which carry around multiple copies of the object, resulting in a significant speedup over the old copy semantics.

However, this method relies on a try/except dictionary lookup. In cases where the objects are not copied, or the copies are seldom used, this results in a lot of failed exceptions and is slower than the previous setattr() scheme.

In both cases, overriding the __copy__ method (which caused a lot of __getattr__ recursion) is already a considerable speedup!

TODO: research benefits of shared cache vs. setattr cache; and perhaps provide two implementations of DPDObject so the user can choose the appropriate one for each application.

Specifying the type in write_branch() should be optional. It will be easy to infer whether a type is iterable/numeric but there could be problems identifying float vs. int due to the loose type system.

something like write_object(obj, attr_list, prefix); the attributes in attr_list will be read from obj, and written to a branch called <prefix>_attrname.

Can implement once #4 is finished (need to infer object attribute types).

Just an idea: would it be possible to replace defer()/defer_unless() with a method decorator? So something like:

def _get_foo(self):
    self.defer_unless( someproperty )
    # calculate...

becomes

@depends_variation( someproperty )
def _get_foo(self):
    # calculate...

It may even be possible to automatically trace dependencies.