It seems to me that this should work
r=1:Inf
r[2] # should give 2.0
but I get (in 0.5-dev)
julia> r[2]
ERROR: InexactError()
in indices at ./abstractarray.jl:45 [inlined]
in checkbounds at ./abstractarray.jl:180 [inlined]
in checkbounds at ./abstractarray.jl:194 [inlined]
in getindex(::FloatRange{Float64}, ::Int64) at ./range.jl:461
in eval(::Module, ::Any) at ./boot.jl:234
in macro expansion at ./REPL.jl:92 [inlined]
in (::Base.REPL.##1#2{Base.REPL.REPLBackend})() at ./event.jl:46
Is this intended, or is it just a bug? From the looks of it the error comes from somewhere in checkbounds, as the value of r[i] is simply (r.start + (i-1)*r.step)/r.divisor and it can be computed by hand without any errors.
Also, shouldn't pop! and similar functions be defined for Range? You could just modify the upper/lower bounds when removing elements from both ends.
shouldn't pop! and similar functions be defined for Range
No, ranges are immutable.
No, ranges are immutable.
It makes sense now, I didn't know that.
I don't think Ranges are designed to support infinite length. I would say 1:Inf and 1:NaN should be errors.
we have countfrom for this, though it doesn't implement indexing
@JeffBezanson is that because 1:Inf has undefined length? Is there any indexible alternative to an infinite list? @tkelman mentioned countfrom, but it isn't indexible, same with repeated. I think having `getindex for these wouldn't hurt.
I would say 1:Inf and 1:NaN should be errors.
Both now throw InexactErrors at construction time. Adding indexing to countfrom and repeated could be considered separately — see #15988 for an initial start.
should add tests accordingly
Most helpful comment
I don't think Ranges are designed to support infinite length. I would say
1:Infand1:NaNshould be errors.