StepRange{<:Integer} with non-integer step

[sostock]

It is possible to create a StepRange{<:Integer} with non-integer step:

julia> r = StepRange(1, 1//3, 2)
1:1//3:2

julia> r[2]
ERROR: InexactError: Int64(4//3)

Should the creation of such ranges throw an error?

There are methods which expect a StepRange{<:Integer} to have an integer step (quite reasonable IMO), and which return wrong results if this is not the case:

julia> intersect(StepRange(1, 1//3, 2), 1:5)
1//1:1//3:2//1

I would prefer the following behavior:

• StepRange{T,S}(start, step, stop) throws an error if T<:Integer and !isinteger(step)
• StepRange(start, step, stop) (constructor without type parameters) converts start and stop to promote_type(typeof(start), typeof(step), typeof(stop)), so that StepRange(1, 1//3, 2) yields a StepRange{Rational{Int},Rational{Int}}, but StepRange(1//2, 1, 5//2) still yields a StepRange{Rational{Int},Int}

[JeffBezanson]

• StepRange{T,S}(start, step, stop) throws an error if T<:Integer and !isinteger(step)

👍 Sounds good to me.

• converts start and stop to promote_type(typeof(start), typeof(step), typeof(stop))

This would be breaking, since the start and step don't need to be promotable. E.g. 'a':1:'z'.

[sostock]

This would be breaking, since the start and step don't need to be promotable. E.g. 'a':1:'z'.

Ah, I didn’t think about that. On second thought, I don’t like that idea of changing StepRange(start, step, stop) anyway. It would be unintuitive if StepRange(::T, ::S, ::T) did not create a StepRange{T,S} but did some conversion instead, and since ranges are usually constructed with the colon operator, it is not necessary.

[sostock]

* `StepRange{T,S}(start, step, stop)` throws an error if `T<:Integer` and `!isinteger(step)`

Technically, this would be a breaking change as well, since someone could have used these ranges. They work fine as long as their length is 0 or 1. One could think about only throwing an error if the length is >1.

[mbauman]

I think that's an appropriate "minor change" — yes, technically breaking so we should note it in NEWS.md, but unlikely to impact real code. And if it does appear in real code, it's likely a bug waiting to happen.

[rapus95]

I guess this and the related pull request can be closed.
Julia v1.3-rc3:

julia> StepRange(1,0.5,2)
ERROR: ArgumentError: StepRange should not be used with floating point
Stacktrace:
 [1] steprange_last(::Int64, ::Float64, ::Int64) at .\range.jl:209
 [2] StepRange{Int64,Float64}(::Int64, ::Float64, ::Int64) at .\range.jl:202
 [3] StepRange(::Int64, ::Float64, ::Int64) at .\range.jl:253
 [4] top-level scope at REPL[58]:1

though, now StepRangeLen has the problem:

julia> StepRangeLen{Int}(1, 0.5, 2)
Error showing value of type StepRangeLen{Int64,Int64,Float64}:
ERROR: InexactError: Int64(0.5)

but when omitting the types everything works:

julia> StepRangeLen(1,0.5,2)
1.0:0.5:1.5

And from using range(...) we don't get there anyway as far as I can tell.

[mbauman]

Actually, the original case still errors:

julia> r = StepRange(1, 1//3, 2)
1:1//3:2

julia> collect(r)
ERROR: InexactError: Int64(4//3)
Stacktrace:
 [1] Integer at ./rational.jl:88 [inlined]
 [2] convert at ./number.jl:7 [inlined]
 [3] iterate at ./range.jl:598 [inlined]
 [4] vcat(::StepRange{Int64,Rational{Int64}}) at ./range.jl:946
 [5] collect(::StepRange{Int64,Rational{Int64}}) at ./range.jl:952
 [6] top-level scope at REPL[2]:1

[sostock]

Since this affects StepRangeLen as well, I will update the PR to throw an error in that case, too.