Skip to content

Fix nearest_neighbor interpolation rounding (#163)#164

Open
sametSeckiiin wants to merge 1 commit into
sensorium-competition:mainfrom
sametSeckiiin:fix/nearest-neighbor-rounding
Open

Fix nearest_neighbor interpolation rounding (#163)#164
sametSeckiiin wants to merge 1 commit into
sensorium-competition:mainfrom
sametSeckiiin:fix/nearest-neighbor-rounding

Conversation

@sametSeckiiin

Copy link
Copy Markdown

Currently, nearest_neighbor interpolation uses np.floor, which ends up mapping timestamps to the previous index rather than the actual nearest neighbor. For example, querying 0.9s (with a 1.0s delta) returns the data from 0.0s instead of 1.0s.

This PR replaces np.floor with np.round so it correctly resolves to the closest time index. I also added np.clip to 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.

@gitnotebooks

gitnotebooks Bot commented Jul 5, 2026

Copy link
Copy Markdown

@sametSeckiiin

Copy link
Copy Markdown
Author

Hi @pollytur, 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!

@sametSeckiiin

Copy link
Copy Markdown
Author

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!

@reneburghardt

Copy link
Copy Markdown
Member

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).

@sametSeckiiin

Copy link
Copy Markdown
Author

@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 floor acts more like a "previous neighbor" step.

Since linear interpolation already looks ahead anyway, what do you think is best here? We could either stick with np.round for standard nearest behavior, or keep np.floor and maybe just clarify in the docs/naming that it avoids future leakage.

Let me know which direction you prefer and I'll update the PR!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

keep_nans=False ignored in nearest_neighbor mode

2 participants