Fix for mid date interpolation

[douglasmacdonald]

steps[0, 1:-1:2] = steps[0, 2::2] = (x[:-1] + x[1:]) / 2

This does not work for interpolating datetimes. This is because adding date does not makes sense and Numpy will throw an error

TypeError: ufunc add cannot use operands with types dtype('<M8[us]') and dtype('<M8[us]')

By changing it to an equivalent form

steps[0, 1:-1:2] = steps[0, 2::2] = x[:-1] + (x[1:] - x[:-1])/2

it adds a datetime and a delta datetime.

This works equally well for numbers.

With a bit of help I could also write tests.

[jbednar]

Very clever! Thanks for the fix! The failing test doesn't seem related?

[philippjfr]

I've been puzzling over this for a while so this is great. Do the pre- and post-step function need similar fixes or do they already work with datetimes?

[douglasmacdonald]

For the other interpolations datetimes should just work. I think I have tested this in the past but have just had a look and I think the others just use indexing and do not need to calculate a mid-point.

[philippjfr]

Great thanks. It would be great to add some tests for this in tests/operation/testoperation.py. They'd look something like:

    def test_interpolate_datetime_curve_mid(self):
        datetimes = ...
        values = ...
        interpolated = interpolate_curve(Curve((datetimes, values)), interpolation='steps-mid')
        curve = Curve(...)
        self.assertEqual(interpolated, curve)

[douglasmacdonald]

Okay. Will write some tests.

[philippjfr]

I've made some other changes by casting the data to ints/floats before applying the interpolation and then casting back. This has the benefit that it also works for pandas period types and others, but may mess with types that cannot be represented with a datetime64[ns] type. In any case, it's a major improvement and I've also added tests.

[jbednar]

If we find types that don't work, maybe we can add some exception-handling fallback to try another approach in those cases.

[philippjfr]

Made another change, it'll now use the native resolution if possible and only fall back to nanosecond resolution if the data is not a datetime64 type.

[douglasmacdonald]

I promise I was going to add tests. However, you are wise in not waiting, it would take me a while before I got the time. Thank you.

[philippjfr]

I promise I was going to add tests. However, you are wise in not waiting, it would take me a while before I got the time.

Haha, no problem, I know how it is and I thought it would be nice to get this into 1.10.6.

[douglasmacdonald]

This is an observation not a suggestion to change anything. If you are now casting to number before the interpolation then the fix I gave might not be necessary. As I did not know the greater context, I think I avoided casting in an attempt to touch as little code as possible and easier to fit in. However, your method will be a better fit with the project.

Thank you for getting the changes in quickly.

[philippjfr]

Thanks, I think we're fine leaving it the way it is now. Ready to review/merge.

[philippjfr]

Now also correctly handled additional value dimensions.

[philippjfr]

PR build failure can be ignored, it's not pulling the latest data for some reason.

[jlstevens]

PR build failure can be ignored, it's not pulling the latest data for some reason.

Agreed and the PR looks good. Thanks @douglasmacdonald!

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.