Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Boundary condition on trimming #204

Merged
merged 3 commits into from
Nov 24, 2019
Merged

Boundary condition on trimming #204

merged 3 commits into from
Nov 24, 2019

Conversation

bmcfee
Copy link
Contributor

@bmcfee bmcfee commented Aug 26, 2019

This PR fixes #203 by including observations which have end time coincident with the trimming start time.

I'm still not 100% sure this is completely correct. It works for @tomxi's example case, where there was a time=0, duration=0 observation being trimmed to start at 0. This should clearly be included.

However, if we have an observation [2, 2+1) with a trim of [3, 10), the modified logic will allow it to pass through, when it probably shouldn't, since [2, 3) ∩ [3, 10) = {}. The ambiguity here comes from our special-case handling of duration-0 observations, which we treat as closed intervals to allow a (Nyquist-style) sampling interpretation.

Perhaps we should explicitly handle this case, by only allowing the boundary condition end_time >= trim_start if the observation duration is 0?

@bmcfee bmcfee added the bug label Aug 26, 2019
@tomxi
Copy link
Member

tomxi commented Aug 26, 2019

Perhaps we should explicitly handle this case, by only allowing the boundary condition end_time >= trim_start if the observation duration is 0?

I would second this option.

@bmcfee
Copy link
Contributor Author

bmcfee commented Aug 26, 2019

@justinsalamon what do you think?

@justinsalamon
Copy link
Contributor

Sounds like a reasonable solution to me (explicitly handling), given that for events with any non-zero duration this becomes a non-issue.

@bmcfee
Copy link
Contributor Author

bmcfee commented Aug 27, 2019

Ok, done. Docs updated as well.

@bmcfee
Copy link
Contributor Author

bmcfee commented Sep 4, 2019

Shall we merge this then?

@tomxi
Copy link
Member

tomxi commented Sep 4, 2019

Not sure if it counts for anything.... but I took a quick peek at the changed files and it all LGTM. Thanks for addressing this.

Copy link
Member

@tomxi tomxi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All looks fine to me.

@bmcfee
Copy link
Contributor Author

bmcfee commented Nov 24, 2019

Looks like I dropped the ball on this, but at ~3 months it looks fine to me. :shipit:

@bmcfee bmcfee merged commit 255a5ee into master Nov 24, 2019
@bmcfee bmcfee deleted the trim-empty branch November 24, 2019 15:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

jams.Annotation.trim() doesn't include events with 0 duration that's on the trim boundary
3 participants