TGraph not displayed in output pdf, only in ps or png or other formats


I’d like to draw the TGraph in the attached files into pdf files.
It appears the last TGraph (named “PtEtaBins_sub0_mR_0_4”) does not appear in the output pdf file when doing :


The file “out4.pdf” only contains an empty frame. All other TGraph can be saved just fine. Also saving as png or ps works fine for all graphs.

Is there something wrong with this particular “PtEtaBins_sub0_mR_0_4” TGraph ? a bug in the pdf writer ?

Thanks for any hint !


test.root (7.3 KB)

ROOT Version: 6.18/00
Platform: fedora 30
Compiler: Not Provided

Get rid of any “nan” in your graph. See:

root [3] PtEtaBins_sub0_mR_0_4->Print();
x[0]=175, y[0]=0.452993, ex[0]=0, ey[0]=0.0094287
x[1]=300, y[1]=0.339418, ex[1]=0, ey[1]=0.00400727
x[2]=500, y[2]=0.345778, ex[2]=0, ey[2]=0.00563489
x[3]=700, y[3]=0.38319, ex[3]=0, ey[3]=0.00559225
x[4]=1000, y[4]=0.434497, ex[4]=0, ey[4]=0.00638541
x[5]=1350, y[5]=0.465726, ex[5]=0, ey[5]=0.00923771
x[6]=1750, y[6]=0.509907, ex[6]=0, ey[6]=0.0102839
x[7]=2250, y[7]=0.517699, ex[7]=0, ey[7]=0.0153527
x[8]=2750, y[8]=0.522154, ex[8]=0, ey[8]=0.0303742
x[9]=3250, y[9]=0.541069, ex[9]=0, ey[9]=0.0746499
x[10]=3750, y[10]=nan, ex[10]=0, ey[10]=nan
root [4] 

Change the y value and the y error of point [10] … or remove it

Thanks, this was indeed the issue !
I didn’t notice the nan in the visual, since the last value simply appeared to be out of the frame and that could be expected in this case.

It’s surprising the pdf output behaves differently than other outputs though… May I humbly suggest this is harmonized or that a clear warning is displayed in this case ? (I’m happy to submit a ticket if it helps)

Thanks again.


In the case of pdf I do see the graph. In my case the final point is clipped. It is very difficult to predict what will be the behavior of a computation involving NaN. What you are asking would imply to test all the graph values against NaN which might be a big penalty for all the graphs containing only good values. We think it is the responsibility of the user to check the validity of numbers put in graphs histograms etc … Note also that, in your case, the fact the two outputs behaved differently pointed something was wrong. You may have never noticed it otherwise.

Ok, fair enough !
But just by curiosity, the ROOT graphic stacks decides to set the nan point at +infinity (and draw the line to there), so it must be somehow aware of the nan ? Maybe issuing a warning there would help ?


No, nothing is “decided” … The graphics backend for screen and pdf are different that’s why you might see different things on screen and pdf output (or not). Also that sort of thing is very machine dependant… So the only thing we can say for sure, is that the result is unpredictable.

In computer science, it’s simply called GIGO.

1 Like

Well, this example was actually extracted from a set of pyroot scripts producing hundreds of plots : in these conditions it’s difficult to understand if your “GO” is due to “GI” or a bug in the (huge) set of code producing the output :smile:

Now it seems to me the graphic backend “decides” where to draw the nan in TPad::YtoPixel … is it possible to check for a nan there ? a warning there could be a useful indication, but from the previous answers, I understand it might be too costly or not appropriate ?


The method YtoPixel simply does a simple computation to transform the Y value into Pixel value. That’s simple arithmetic . If you give it a NaN or an Inf it will return some unpredictable value as would any computing in any program.

Basically you are asking we call TMath::IsNaN() for you… It is not possible. That’s to costly. As I said it is up to you (or the program filling the TGraph) to make sure it is not filling the TGraph with garbage values.

ROOT provides all the tools to make that sort of test.

Moreover … why should it be done on the Graphics side ? … you can also imagine to do it earlier at the SetPoint() time ? … But there also it far more to costly ! this will penalise users who are carefully testing the validity of there data … And that’s not only that: if we test for NaN why not testing for Inf ? … Etc … Etc …

indeed, that’s why I wrote decides into quotes. But I get your arguments. I was trying to find an ideal place where those nan could be detected, and I realize there’s probably none…


That is weird…
At some point this graph must be filled … That’s the place to call IsNaN …
I understand you do not have access to the place the graph is filled ?

No, no I meant : no ideal place within ROOT.
There’s always the case where you receive the data from a code you can’t /don’t want to touch, but I now understand it’s probably not possible for ROOT to do the garbage sorting job…

If you are not confident into the data (graphs) you are receiving from the 3rd party program, you can always make a small utility scanning the graphs (basically a loop over all the points) to detect NaN Inf etc …

The following little script does the job:

void IsGraphValid(TGraph *g) {
   int n = g->GetN();
   double x,y;
   for (int i=0; i<n; i++) {
      if (TMath::IsNaN(x)) printf("x[%d] is a NaN\n",i);
      if (TMath::IsNaN(y)) printf("y[%d] is a NaN\n",i);


$ root test.root
  | Welcome to ROOT 6.19/01               |
  | (c) 1995-2019, The ROOT Team; conception: R. Brun, F. Rademakers |
  | Built for macosx64 on Aug 23 2019, 12:28:37                      |
  | From heads/master@v6-19-01-984-g389f0c87c6                       |
  | Try '.help', '.demo', '.license', '.credits', '.quit'/'.q'       |

root [0] 
Attaching file test-4.root as _file0...
(TFile *) 0x7fd4e5ced300
root [1] auto g = (TGraphErrors*)_file0->Get("PtEtaBins_sub0_mR_0_4")
(TGraphErrors *) @0x7ffeef0ab638
root [2] .x IsGraphValid.C(g)
y[10] is a NaN
root [3] 

And of course you can elaborate this script to “fix” the problematic entries…

ok, thanks for the suggestions and discussion !

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.