-
Notifications
You must be signed in to change notification settings - Fork 18
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
Unbounded interval support #104
Conversation
Codecov Report
@@ Coverage Diff @@
## master #104 +/- ##
==========================================
+ Coverage 69.94% 72.28% +2.34%
==========================================
Files 8 8
Lines 376 415 +39
==========================================
+ Hits 263 300 +37
- Misses 113 115 +2
Continue to review full report at Codecov.
|
src/anchoredinterval.jl
Outdated
@@ -246,6 +266,8 @@ function Base.isempty(interval::AnchoredInterval{P,T}) where {P,T} | |||
return P == zero(P) && !isclosed(interval) | |||
end | |||
|
|||
# TODO: Not required but should be addressed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Optimized intersect
for AnchoredInterval
s. This function may need to be dropped as it it may no longer possible to return an AnchoredInterval
for unbounded results here. I need to think about this more.
88f26f6
to
70443cb
Compare
81c4663
to
1f9e74a
Compare
a59deb6
to
f24a406
Compare
1f9e74a
to
1220a2c
Compare
Rebased now that #102 has been merged. |
src/anchoredinterval.jl
Outdated
@@ -60,6 +60,17 @@ See also: [`Interval`](@ref), [`HE`](@ref), [`HB`](@ref) | |||
""" | |||
struct AnchoredInterval{P, T, L <: Bound, R <: Bound} <: AbstractInterval{T,L,R} | |||
anchor::T | |||
|
|||
function AnchoredInterval{P,T,L,R}(anchor::T) where {P, T, L <: Bound, R <: Bound} | |||
if P < zero(P) && R === Unbounded || P > zero(P) && L === Unbounded |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we really include support for unbounded AnchoredIntervals? Do you expect people to pass infinite periods? I think it makes sense to restrict AnchoredIntervals to finite P
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A very valid question. Just because we can support it doesn't mean we should. I'll give that some thought
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One argument for keeping this is that removing Unbounded
support doesn't stop people from using infinite periods. We'd have to add checks to disable that as well
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thinking about this more I think support for unbounded and infinity should be consistent. If we do want to remove unbounded support entirely from AnchoredInterval
we should also remove support for infinity.
My rational in why these go together is that I was planning on defining equality between infinite and unbounded intervals such that [∞,x] == (,x]
. Not having unbounded support but having infinity support seems wrong to me considering this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thinking about this more I think support for unbounded and infinity should be consistent.
Yeah I do agree.
Okay, I can imagine wanting this rather than just using Interval I guess. But it's hard to imagine why you'd want an AnchoredInterval with infinity as part of the type.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, I'm okay with keeping this functionality. But a MethodError
hurts readability for the error, since the user cannot see from the type signature why this is wrong. I think this should be a different type of error.
One way to keep it a MethodError would be to add yet another type parameter that's just the sign of the period, then all the relevant information would be available for dispatch.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll make it an argument error. Not entirely accurate but better
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
More thoughts on this: #104 (comment)
In reviewing the code again and taking this conversation into consideration. I've noticed that there are some cases with I've unfortunately run out of time to work on this and ensure the problem is solved correctly so I'll be holding off on merging this PR. I do believe the unbounded support for the |
09c3fef
to
d6cf602
Compare
end | ||
|
||
_isfinite(x) = iszero(x - x) | ||
_isfinite(x::Real) = Base.isfinite(x) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm attempting to get this functionality added to base: JuliaLang/julia#36380
@@ -3,7 +3,8 @@ interval_markers(L::Type{<:Bound}, R::Type{<:Bound}) = interval_marker.([L, R]) | |||
interval_marker(x::Type{Closed}) = :vline | |||
interval_marker(x::Type{Open}) = :none | |||
|
|||
@recipe function f(xs::AbstractVector{<:AbstractInterval{T}}, ys) where T | |||
# TODO: Add support for plotting unbounded intervals |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Open an issue and add to this comment?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, thanks. I did look into this and it got complicated quickly
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
The current implementation does not correctly support intervals with unbounded endpoints and from some basic attempts it will probably be an involved change.
Ensure that we can construct an AnchoredInterval where the computed endpoint is an non-existent or ambiguous ZonedDateTime.
61f8560
to
b055421
Compare
Rebased to apply documentation fixups and fixed typo in commit message. Just waiting on CI then will merge. |
Using the parametric bounds interface in #102 this PR adds the fundamentals for constructing and interacting with unbounded intervals.
Intervals with unbounded endpoints can be constructed by using
nothing
as a placeholder (e.g.Interval(nothing, 2)
creates the interval(,2]
). Explicitly stating the bound type requires that when supplyingnothing
that the respectively stated bound type isUnbounded
(e.g.Interval{Unbounded,Open}(nothing, 3)
creates(,3)
butInterval{Open,Open}(nothing, 3)
andInterval{Unbounded,Unbounded}(nothing, 3)
both raiseMethodError
s).As for the actual implementation for
Interval{T}
whereT
is the element type we always store values of typeT
and never storeNothing
. Doing this avoids using a union type which would result inInterval
no longer being a bits type. However, using thefirst
orlast
function on an unbounded endpoint does now returnnothing
.The current implementation has
span
throw an exception on unbounded intervals as discussed in #89 (comment).