Fix nearest_neighbor interpolation rounding (#163)#164
Conversation
|
Review these changes at https://app.gitnotebooks.com/sensorium-competition/experanto/pull/164 |
|
Hi @reneburghardt , whenever you have a moment, could you take a quick look at this PR? It fixes the nearest_neighbor interpolation logic discussed in #163. Thanks! |
|
Hi @sametSeckiiin we are all not full-time working on Experanto and hence most of the time need a bit until we can answer and/or review PRs. Regarding this PR, I actually thought the original behavior was intended to avoid leakage from future data points (though we are arguably not fully consistent with this wrt linear interpolation anyways). |
|
@reneburghardt No worries at all about the timing! That makes total sense regarding the future data leakage. My thought process was just that people usually expect "nearest" to mean the mathematically closest point, while Since linear interpolation already looks ahead anyway, what do you think is best here? We could either stick with Let me know which direction you prefer and I'll update the PR! |
Currently,
nearest_neighborinterpolation usesnp.floor, which ends up mapping timestamps to the previous index rather than the actual nearest neighbor. For example, querying0.9s(with a1.0sdelta) returns the data from0.0sinstead of1.0s.This PR replaces
np.floorwithnp.roundso it correctly resolves to the closest time index. I also addednp.clipto make sure rounding up doesn't cause an out-of-bounds error at the end of the array.Fixes #163
Tested locally by querying intermediate timestamps to verify they pull from the nearest data point.