SetBinContent in overflow bin doubles nBins in htemp


I ran into a strange problem that caused me hours of grief. Given a TTree, I draw a branch into an un-initialized histogram htemp. Then, after I SetBinContent the overflow bin, the number of bins in htemp doubles! See the following CINT session to understand the effect:

pb-d-128-141-131-37:roottalk jribnik$ root -b gaus_TTree.root 
* Welcome to ROOT v5.18/00   *

* Welcome to ROOT v5.18/00   *

root [0] 
Attaching file gaus_TTree.root as _file0...
root [1] .ls
TFile**		gaus_TTree.root	
 TFile*		gaus_TTree.root	
  KEY: TTree	tree;1	tree
root [2] tree->GetListOfBranches()->ls("*")      
OBJ: TBranch	gaus	gaus/D : 0 at: 0x282a440
root [3] tree->Draw("gaus>>htemp")
<TCanvas::MakeDefCanvas>: created default TCanvas with name c1
root [4] htemp
(class TH1F*)0x20be200
root [5] htemp->GetNbinsX()
(const Int_t)(100)
root [6] htemp->SetBinContent(101, 1)
root [7] htemp->GetNbinsX()          
(const Int_t)(200)
root [8] htemp->SetBinContent(201, 1)
root [9] htemp->GetNbinsX()          
(const Int_t)(400)
root [10] 

If I draw the branch into a histogram initialized with the number of bins, i.e. >>htemp(100), the same problem occurs. However, if I draw the branch into a histogram initialized with axis limits, i.e. >>htemp(100, 0, 10), the problem goes away, but then I loose the flexibility of not having to know my axis limits a priori.

I have attached a ROOT macro that creates a simple TTree and demonstrates the effect. From the resulting histogram you can see that it also adds an entry and drastically changes the axis limits. I discovered this in compiled code on a Mac in 5.18/00, and have seen it also on Linux in 5.14/00e.

Does anyone know what is going on here?


roottalk.cpp (610 Bytes)

I guess the explanation why the number of bins increases is given here: … BinContent

Sigh, thanks. I got too caught up in gathering evidence to properly read the documentation. ResetBit(TH1::kCanRebin) does the trick.


As a follow up to this, the automatic re-binning of a histogram after a TTree::Draw is still not the behavior I would expect for my use case:

After the TTree::Draw has completed, I would expect the resulting histogram to have a well-defined number of bins and axes limits (I am done filling the histogram after the TTree::Draw), and so would expect the TH1::kCanRebin bit to be turned off.

The only time I would expect this bit to remain set after a TTree::Draw is during a TChain::Draw which must leave the histogram parameters open while it is being filled across multiple trees. But again, once the TChain::Draw is complete I would expect the resulting histogram to be “final” and have well defined parameters and no TH1::kCanRebin bit.

Is this unreasonable?


[quote]Is this unreasonable?
It is reasonable. This bit is now reset automatically after drawing the histogram. in SVN.