yoda is hosted by Hepforge, IPPP Durham
close Warning: Can't synchronize with repository "(default)" (Repository path '/hepforge/hg/yoda/public/yoda' does not exist.). Look in the Trac log for more information.

Roadmap

Milestone: Full 2D histos

9 years late (Jan 20, 2015, 6:00:00 PM)

2D histograms should have fully functional outflows, and projections into 1D marginal histograms and profile histograms in both directions. This should work for both Histo2D and Profile2D. A universal (pair) indexing is needed for accessing the outflows in a coherent way.

To divide 2D histograms & profiles, Scatter3D/Point3D need to be persistable. This requires improving the YODA format parser since there is an ambiguity between Profile1D bins and Scatter3D points in the current, context-insensitive implementation.

A later milestone will completely rework the binned object storage implementation, but this milestone should establish an API that will be unchanged by that implementation detail. It'll be best to use public bin accessor functions as much as possible when marginalising/projecting, to minimise the re-engineering work.

Milestone: Reworked scatters

9 years late (Feb 20, 2015, 6:00:00 PM)

Scatters should not treat any axis specially (except perhaps in the case of booking binnings from them, and maybe that could be done via a helper function). The current code assumes that Scatters are "secret" histograms in various places, and concepts like scatter division should be removed.

The addition + and += operators should be removed at the same time, since they behave like "combine(a,b)" and "combineWith(other)", not addition of corresponding points and the explicit name for the relatively uncommon combination operation will avoid confusion.

Multiple errors would also be good to have, and maybe we could reinstate the Scatter<N>, as a generic base class to be specialised with "x,y,z" accessor names for 1, 2, and 3D cases?

The current class structure requires a lot of duplication since we don't use inheritance very much and then have to forward nearly all methods from BinSearcher? to Axis to Histo, from Dbn to HistoBin?, etc. Overflows are also awkward and we can't use polymorphism to handle all 2D binned types equivalently, for example.

Proposal: use current BinSearcher? to implement a generic Binning1D, Binning2D which gives fast lookups into arrays of N+2 bins in each direction, with the underflow and overflow automatically treated as bins extending to infinity. Will require some care in how we add bins... perhaps set up first as pairs of (pairs of) edges in the bin searcher and then use that to finally create bin objects & lock. The bin(i) accessor should return the in-range BIN objects, and outflows will be accessed by returning the bin's DBN, not exposing the bin itself.

Binned histo types will inherit from Binning1D,2D and add a total DBN to be stored on the histo object itself. There should be only a few methods (notably fill(...) and various stat functions) specific to the derived classes. The bins will inherit from Bin1D,2D as now, with as much common functionality in the base classes as possible.

We should reduce the header file content at the same time, to minimise forcing of large rebuilds in client code.

Note: See TracRoadmap for help on using the roadmap.