infinite intervals

[tpapp]

Recently I came across a problem where it would have been nice to represent infinite intervals. Currently

ClosedInterval(1.0,Inf)

works, but

1. I feel this is a bug (constructor should check),
2. [x,Inf), (-Inf,x], and (-Inf,Inf) intervals should be represented by distinct types (I want to dispatch on them), and this type should be distinct from potential finite-width (half-)open interval types (cf Roadmap #1).

Would the maintainers be open to a PR that adds eg a ClosedPosInfInterval, ClosedNegInfInterval, RealLine, for the above interval types? I would be happy to do one. Just help me name them better.

[dlfivefifty]

Infinite endpoints are legitimate for intervals: https://en.wikipedia.org/wiki/Interval_(mathematics) So I don't agree that the current behaviour is a bug.

In ApproxFun I have domains for Line <: Domain and Ray <: Domain, with the following conversion to support 0..Inf to construct rays:

function Base.convert(::Type{Domain},d::ClosedInterval)
    a,b=d.left,d.right
    if abs(a) == Inf && abs(b) == Inf
        Line(d)
    elseif abs(a) == Inf || abs(b) == Inf
        Ray(d)
    else
        Segment(d)
    end
end

This pattern may be useful for your case: have convert routines from the current ClosedInterval implementation to your proposed ClosedNegInfInterval.

[tpapp]

@dlfivefifty : Infinite endpoints are indeed OK, but the resulting interval is not closed. So ClosedInterval(0,Inf) is nonsensical. Not to mention ClosedInterval(NaN,NaN).

I don't know the internals of ApproxFun, but for the problems I work with, it would be great to distinguish at the type level

1. finite, semi-infinite intervals and the real line,
2. whether the intervals are closed or not on finite endpoints.

so that one can dispatch on them. For example, if I am approximating something with Chebyshev polynomials, I would adjust the nodes to include endpoints depending on whether the interval is closed.

Whether this should be part of this package is a good question, but from the general types I see in the source my understanding is that this was planned for finite intervals at least.

The alternative is

1. doing this in (yet) another package,
2. each package working with rootfinding, optimization, approximation, etc devising a representation for its own purposes.

[dlfivefifty]

Infinite endpoints are indeed OK, but the resulting interval is not closed

It's closed on the compactified real line: ℝ ∪ {∞} .

if I am approximating something with Chebyshev polynomials, I would adjust the nodes to include endpoints depending on whether the interval is closed

This is off topic, but in my experience, you're better off always using the first kind Chebyshev points, which ApproxFun has changed to as the default. This avoids endpoint singularities. First kind points may be useful for collocation, but collocation is O(n^3) and unstable....

Whether this should be part of this package is a good question

What should be in this package is OpenInterval, OpenClosedInterval and ClosedOpenInterval. It sounds like your usage is less about infinity, and more about open endpoints, and so ClosedOpenInterval(0,Inf) would do.

I don't actually like that naming scheme, so maybe something like:

typealias ClosedInterval{T} Interval{true,true,T}
typealias OpenInterval{T} Interval{false,false,T}

[tpapp]

Sometimes the solution you describe fits the problems I work on, but sometimes it doesn't. Currently I am working on an MCMC problem, and the posterior sampler I am using can handle ℝⁿ→ℝ functions nicely, but my parameters are constrained, some on (0,∞), some on (0,1). It is customary to map these to ℝ using logistic and log transformations. Implementing this in Julia, it is nice to dispatch on (semi-)finiteness.

However, no matter how nice a unified type hierarchy would be for this, perhaps the needs of individual domains need to crystallize before we attempt that.

[dlfivefifty]

OK your usage is very close to mine, in that we are using intervals to represent domains, rather than, say interval arithmetic. Along with maps to project between domains. It might be worthwhile to have a unified package for this usage case, though this is relevant: https://github.com/zenna/AbstractDomains.jl

[dlfivefifty]

PS [0,Inf) is a closed set on R as its complement(-Inf,0) is an open set

[tpapp]

@dlfivefifty indeed, but AFAIK for intervals "closed" means "contains the endpoint". This is a convention, and as you pointed out, it does not map well to topological considerations, especially on the extended real line.

[ChrisRackauckas]

@dlfivefifty indeed, but AFAIK for intervals "closed" means "contains the endpoint".

No, it means any limit sequence limits inside of the set. So for this reason R is actually clopen. But this is weird stuff we work with in pure math that really doesn't mean much to reality...

I must say I like the typealias version. However, is there a way this extends to more general domains?

[hyrodium]

The original question is already solved, so I'll close this issue.

We may need some additional types to represent half infinite intervals such as {d | d < Date(2022,04,13)}, but this should be discussed in another issue.