Stripping numbers after decimal point

Is there any (easy) to force ROOT to strip all numbers after decimal point when plotting TGraphErrors, TGraph, TMultiGraph objects on axes? I mean something like TStyle::SetStripDecimals() function but for all numbers nut only “0”. I am plotting number of TMultiGraph objects and once in a while it shows like 16043.2 17832.4 … instead 16000 17500 … How are these “major” divisions calculated in TMultiGraph? How do I force them to be nice round numbers like 16000 16500 …?


Could you send the shortest possible running script showing this problem?


Hi Rene,

I played with it a little and it seems like there is some problem with algorithm used to determine number of axis labels in function TAxis::SetNdivisions(). I included file problem.tar.gz with a simple macro and two txt data files. You can simply run it with .x Problem.C.

It seems like when you use numbers for SetNdivisions(): 503, 1006, 502, 1005 you get “weird” numbers on X axis for the left column but fine for the right column. Numbers like 806, 506 worked fine for me in both cases. So it must be just some strange combination of data points and number you use for divisions… One more thing in the upper row you have the same graph in TMultiGraph object - I wanted to see if there is any difference if I use different object - but it doesn’t make any.

One more thing: it seems to be marginal problem it occured only in app. 10% cases for my data plotted in the same fashion.

problem.tar.gz (1.45 KB)


I see the “problem”. It appears only when the canvas is divided. When you specify a number of division it is consider as a maximum value for each division level. The labelling is then optimized to look good. If you do not want to optimize you should specify a negative number of division. But then you will almost certainly get an ugly labelling. The number of divisions is also reduced (at optimization time) when the axis are small to avoid labels overlapping. I think you are in that case. Your number of primary division is already low (5), then you draw in small windows (2x2) so very likely the number of real divisions will be to small to make a correct optimization. Give an higher number for primary divisions (1010 for instance) and you will get something better.