Use relative time while computing the background

[israelmcmc]

I run into an issue with background estimation, which I tracked down to using untriggered TTE. The root of the issue was that I did not subtract the trigger time or some other form of t0 close to the time range of the data. In my case, this caused the times to be of the order ~1e8. When you fit it with a polynomial of order e.g. 2, differences in the coefficients of order ~1e-16 start to matter, and this is already within floating point precision.

These plots correspond to the same data, the only difference is subtracting t0 before the background calculation.

Although this can be solved on the user side by always subtracting t0, I instead add this fix to the background calculation itself. I think this is less error prone, and will save time to other users that are puzzled like I was from this unexpected behavior.

I also modified the function interpolate() so that the user can still input the regular times. All other methods use the relative time, but these start with _, so presumably the user shouldn't access them anyway.

This is only for the binned Polynomial background fit. The same fix might also be needed for unbinned classes and for other binned classes in the future.

[BillCleveland-USRA]

TZERO should be handled by the data class. This way the floating point significant digits will be uniform throughout the life of the data object and all of the various analysis performed.

I recommend this to be handled uniformly by the library with the defaults being tzero = tstart for non-triggered data.

[BillCleveland-USRA]

This issue remains open until the fix is implemented in the data classes.

[israelmcmc]

Thanks @BillCleveland-USRA for checking this one as well. I'd like to clarify that, while I found the issue while handling TTE data, the issue can be isolated to the Polynomial class. It doesn't matter where the input data comes from. I wrote this example to illustrate my point: https://gist.github.com/israelmcmc/94549b65442e80b7e3b2e02053463617

The only thing I'm importing from GDT is the Polynomial class, and I'm creating the data on the fly. When t0 = 0 (or a relatively small value), the result of the fits is as expected, both in the main branch (c35733b) and this PR, e.g.:

However, when I uncomment line 6 to set t0 = 1e8, I get this misfit with the main branch, e.g.:

The exact result jumps around depending on the random sampling, but it's pretty bad most of the time. Here are a couple more realizations:

On the other hand, my branch in this PR gets the expected result consistently, e.g.:

I thefore think that, while the data class can also be updated to handle TZERO in a more robust way, as you suggested, this PR can be merged independently.

Please let me know what you think and I can start working on the unit tests.