Note that in this VERY OLD “bug report”, one claims that this “brutal fix” should work: TFile *f = new TFile("sferiche_nt.root");
TTree *t; f->GetObject("t", t);
TCanvas *c = new TCanvas("c", "c");
if (t) t->Draw("z:y:x:p","","colz");
TH3F *ht=(TH3F *)gROOT->FindObject("htemp");
if (ht) {
ht->GetXaxis()->SetLimits(-0.5, 0.5);
ht->GetYaxis()->SetLimits(-0.5, 0.5);
ht->GetZaxis()->SetLimits(-0.5, 0.5);
c->Modified(); c->Update();
}
I’ve just been able to “reproduce” the (more than two years old) https://sft.its.cern.ch/jira/browse/ROOT-4508 bugs without any problems with ROOT 5.34/18 (actually “heads/v5-34-00-patches@v5-34-18-531-g9e42712”).
Execute the unchanged original macro from [url]Problem with logarithmic X/Y axes with TNtuple then try “h->GetNbinsX()” and/or “h->GetNbinsY()” -> you will get 20, while you should have got 100.
Edit the original macro from [url]Problem with logarithmic X/Y axes with TNtuple and comment out BOTH lines “h->Get[XY]axis()->SetLimits([xy]min, [xy]max);” then execute the modified macro and you will immediately see that 3 points with X <= 1 are missing in the canvas.
BTW. I tried this macro with the newest ROOT 6.00/01. If I enable the line “Double_t xmin = 0.01, xmax = 50, ymin = 0.01, ymax = 50;” (just change the first “#if 0” into “#if 1”), I immediately get “*** Break *** segmentation violation”.
1- Yes the histogram is deleted but it is clearly said with a warning. I guess there is a good reason to have done it this way. ie: redefining the histogram and printing a warning. I am not the author of this code. I cannot tell why.
2- I am getting a weird behaviour. Depending if SetEstimate is used or not I get the right limits or not . Again I am not the author of this code. Hard for me to tell why it behaves like that.
If you change “b:a:c>>h” into “b:a:c>>+h” you will also notice that even in this case, in which is it just supposed to “append data to an existing histogram”, it simply recreates the histogram. So maybe you could notify the one who is the “author of this code” that there are serious problems around.
P.S. Just to make it clear -> if “h” already exists then in case “b:a:c>>h” I expect that “h->Reset();” is automatically executed (just the integral, contents, errors, statistics, minimum and maximum of the histogram are “reset”, but everything else, including the binning, remains untouched).
Your fix seems to work well in case the “h” histogram was manually created be the user.
There’s still a “display” problem in case when the automatically created “htemp” is used.
In order to reproduce it, change the second “#if 1” into “#if 0” then run the macro. You will see all points drawn in the canvas. Then comment out BOTH lines “htemp->Get[XY]axis()->SetLimits([xy]min, [xy]max);” and execute the modified macro again and you will immediately see that 3 points with X <= 1 are missing in the canvas.
I guess this is a “side effect” of the fact that “htemp->GetXaxis()->GetXmin()” returns 0 and then the procedure which creates the axis in logarithmic mode “misbehaves” (so this problem will appear for any histogram for which “Xmin == 0”, and it’s possible that the same will happen for the “Y” axis if “Ymin == 0”).
If I remember well … in the “old times”, also the point with the highest “X” was missing in the canvas, but some time ago (not that very long ago, several months maybe) you fixed something in the automatic procedure which calculates automatic axes limits and now this point is always present (but the 3 points with “X < 1” are still missing). But maybe I remember it wrong.
