unintuitive behavior in multiple-dimension hists that have multiple input collections

[btcardwell]

When constructing multi-dimensional histograms with more than one input collection, the framework currently constucts the list of unique combinations of objects separately for each axis (see [0]). This implementation choice leads to unintuitive behavior in multi-dimensional histograms that use the same input collection in more than one axis expression.

If one plots muon d0 vs muon pT when using a dimuon selection, for example, one would generally want two entries per event (one for each muon). With the current implementation, the resulting plot has four entries per event: (pt_1, d0_1), (pt_1, d0_2), (pt_2, d0_1), and (pt_2, d0_2).

This undesirable behavior can be avoided by specifying an index for each axis (only plot the leading or subleading object, for example), but in the long run, it would probably be better to restructure the implementation to construct unique object combinations before evaluating the axis expressions.

[0]

OSUT3Analysis/AnaTools/plugins/Plotter.cc

Lines 416 to 428 in 7490cfc

	// If there is more than one input collection, then fill the 2D histogram for each combination of objects.
	// Warning: This histogram may be difficult to interpret!
	for(vector<Leaf>::const_iterator leafX = definition.valueLookupTrees.at (0)->evaluate ().begin (); leafX != definition.valueLookupTrees.at (0)->evaluate ().end (); leafX++){
	for(vector<Leaf>::const_iterator leafY = definition.valueLookupTrees.at (1)->evaluate ().begin (); leafY != definition.valueLookupTrees.at (1)->evaluate ().end (); leafY++){
	double valueX = boost::get<double> (*leafX),
	valueY = boost::get<double> (*leafY);
	if (!IS_INVALID(definition.indexX) && leafX - definition.valueLookupTrees.at(0)->evaluate().begin() != definition.indexX)
	continue;
	if (!IS_INVALID(definition.indexY) && leafY - definition.valueLookupTrees.at(1)->evaluate().begin() != definition.indexY)
	continue;
	fill2DHistogram(definition, valueX, valueY, weight);

[jalimena]

notice that this also applies to 3D histograms (a little farther down in OSUT3Analysis/AnaTools/plugins/Plotter.cc)

[btcardwell]

To clarify further, this is an issue for all multidimensional histograms with multiple input collections that don't specify an index for every axis. The example in the initial comment shows the behavior for a multidimensional histogram where the same input collection is used on more than one axis, but the behavior is similarly unintuitive for multidimensional histograms with different input collections on each axis.

For example, if one plots electron pT vs muon pT (without specifying indices) for events that contain 1 electron and 2 muons, one would generally expect two entries per event: (e_pt, mu_pt_1) and (e_pt, mu_pt_2). Instead, the resulting plot has 4 entries per event: two at (e_pt, mu_pt_1) and two at (e_pt, mu_pt_2).