I’ve spent quite a lot of time trying to understand why in some cases a TSpline5 created from a TGraphSmooth::Approx graph misbehaves around the maximal “x” value.

In the end, I realized that there is a very nasty problem in TGraphSmooth::Approx (both ROOT 5 and ROOT 6 have the same problem).

When the input parameter “xout = 0” (if “yright = rule = 0” or “rule = 1”), then:

`delta = (fMaxX - fMinX)/(fNout - 1);`

Later in the “`for (Int_t i=0;i<fNout;i++)`

” loop:

`x = fMinX + i*delta;`

Due to “floating point rounding errors”, it happens sometimes that the very last calculated “x” value (i.e. when “i = fNout - 1”) SLIGHTLY EXCEEDS the “fMaxX” and then the call to “Approx1” immediately returns 0 (if “yright = rule = 0” or “rule = 1”).

As a result, the very last point in the newly created “fGout” graph will have “y = 0”.

I guess a simple fix would be to replace:

`if (xout == 0) x = fMinX + i*delta;`

with something like this:

`if (xout == 0) x = ((i < (fNout - 1)) ? (fMinX + i*delta) : fMaxX);`

Could you, please, fix it in both, ROOT 5 and ROOT 6.

An alternative for avoiding “rounding-extrapolation” problems could be to use:

`x = fMinX + (fMaxX-fMinX)*(i/Npoints);`

By writing explicitly the expression of delta=(fMaxX-fMinX)/Npoints I guess the problem is also avoided.

Your formula is wrong.

Better so?

`x = fMinX + i*delta = fMinX + (fMaxX - fMinX)*(i/(fNout - 1));`

The “edited 1 time in total” formula is still wrong.