Add length

[tpapp]

Add Base.length(::ClosedInterval), which returns the number of elements in an interval for types which can be mapped to integers (currently all integers and Dates).

[tpapp]

Travis seems to have stopped for some bogus error, and I don't seem to have the privileges to restart it.

[timholy]

Maybe add @test_throws MethodError length(1.2..2.4) just to indicate that the absence of such a method is deliberate?

[timholy]

Thanks! Very nice of you to tackle this.

[timholy]

Given this morning's discussions, I realize there may be one potential problem here:

julia> 1..3 == 1.0..3.0
true

But if we think of 1..3 as a discrete set and 1.0..3.0 as a continuous set, this isn't right anymore.

[timholy]

One option would be to change the parametrization to ClosedInterval{Space,T}. So ClosedInterval{Real,T} would be an interval of real-valued numbers (and length would not be defined), but ClosedInterval{Integer, T<:Integer} would be an interval of integers. Note that one could have ClosedInterval{Real,Int} (and that's what I'd personally favor for 1..3, but I could be persuaded otherwise).

[tpapp]

What would be the type for a ClosedInterval of Dates?

I was thinking along similar lines, except that I would have ClosedInterval{T,D} where D stands for "discrete" and is a boolean type parameter. length, iteration, etc would be defined for ClosedInterval{T,true} where T.

[timholy]

Dates are an interesting case. You definitely want to allow a continuous interval, but I agree we don't seem to have a way to express that now.

With discrete numbers, is there any reason you can't use a StepRange?

[tpapp]

Two reasons:

1. a lot of the operations I do map really well to intervals (eg being closed under intersection, union of contiguous intervals),
2. a practical one: I am working with dates compressed to 16 bits, on a large dataset (2e10 observations). An extra field would cost me gigabytes.

If ClosedInterval is not a good match for this, I can just start an analogous library.

[timholy]

If point 2 means that what you effectively want is a step that's specified via the type system, then you are probably better off writing your own:

struct TimeStepRange{T} <: OrdinalRange{T,Dates.Nanosecond}
    start::T
    stop::T
end

Base.step(::TimeStepRange) = Dates.Nanosecond(1)

And then you could write a union implementation of your liking.

I tend to think of AbstractRanges as Intervals with a step, so I'm beginning to have second thoughts about supporting a notion of "number of elements" within an interval. That said, from a mathematical standpoint there is nothing wrong about using a discrete set as the "world." I think when we designed this package we were implicitly assuming intervals on the Real line. I'm still mulling this over.

[tpapp]

I wrote DiscreteRanges.jl which at least clarifies the behavior that I want. It is different from IntervalSets, I tried to address this extensively in the README. You comments are welcome.

Also, feel free to revert this PR, it may not belong in this library.