InfStepRange is not an ordinal range

[jishnub]

See JuliaArrays/FillArrays.jl#207

Currently, InfStepRange is too permissive:

julia> InfiniteArrays.InfStepRange(3, 2.5)
3:2.5:+∞

If this is an ordinal range, the step size should be limited to multiples of oneunit. Perhaps the current design is accidental, rather than the intention, and the start and step should be integers?

[putianyi889]

I'm trying to change the definition to

struct InfStepRange{T,S} <: AbstractRange{T}
    start::T
    step::S
end

Hopefully additional small fixes could pass all tests.

[jishnub]

Perhaps this should be an OrdinalRange after all, with checks on the step? This will be analogous to a StepRange.

[putianyi889]

For float input, as for how julia base works, it should return an InfStepRangeLen then. Julia base never generates a StepRange of float type.

But from the implementation perspective, StepRange and InfStepRange work in the same way as r[k]=start+step*(k-1), while StepRangeLen uses r[k]=start+(last-start)*(k-1)/(length-1).

[jishnub]

Yes, that might make sense for the colon constructor. Ideally, the infinite types should shadow the finite ones

[putianyi889]

The motivation of this issue is

julia> 1.0:∞
1.0:1.0:+∞

julia> float(1:∞)
1.0:∞

while

julia> 1.0:5
1.0:1.0:5.0

julia> float(1:5)
1.0:1.0:5.0

[putianyi889]

well maybe InfiniteArrays is correct while Julia base is not

[jishnub]

I don't think the types are considered a part of correctness. The resulting values are the same in each case, with the types in Base being chosen to ensure that the values are accurately represented. Something similar might be possible in this package, but the focus has perhaps not been on floating-point ranges as much as integer ones.

[dlfivefifty]

Infinite float ranges are definitely important, as operators are often float valued (think of even the Derivative operator for Chebyshev but on a mapped interval)