InexactError(): using range with higher values than Int64

[peter1000]

Just played around and saw this:

Julia
Version 0.4.0-dev+3878 (2015-03-18 02:09 UTC)
Commit 17abcd9* (0 days old master)
x86_64-unknown-linux-gnu

Test code

# test1:
function test1()
    for i in 1:Int128(170141183460469231731687303715884105727)
    end
    println("Finished loop test1")
end

# test2: range
function test2()
    for i in range(1,Int128(170141183460469231731687303715884105727))
    end
    println("Finished loop test2:range()")
end

test1()
test2()

OUTPUT

Finished loop test1


ERROR: LoadError: InexactError()
 in convert at int.jl:157
 in test2 at /home/possible_error.jl:12
 in include at ./boot.jl:250
 in include_from_node1 at loading.jl:129
 in process_options at ./client.jl:318
 in _start at ./client.jl:402
while loading /home/possible_error.jl, in expression starting on line 18

Cheers
P

[nalimilan]

You don't even need to run loops to reproduce this:

julia> range(1,Int128(170141183460469231731687303715884105727))
ERROR: InexactError()
 in convert at int.jl:157

julia> 1:Int128(170141183460469231731687303715884105727)
1:170141183460469231731687303715884105727

[nalimilan]

Even clearer:

julia> UnitRange{Int64}(1, Int128(typemax(Int64)))
1:9223372036854775807

julia> UnitRange{Int64}(1, Int128(typemax(Int64))+1)
ERROR: InexactError()
 in convert at int.jl:157

range should probably choose better its type parameter. Currently it only takes into account the first argument.

[tkelman]

Should this line

julia/base/range.jl

Line 77 in 288ea08

range(a::Real, len::Integer) = UnitRange{typeof(a)}(a, a+len-1)

be changed to

range(a::Real, len::Integer) = UnitRange{promote_type(typeof(a),typeof(len))}(a, a+len-1)

?

[ivarne]

How would range(typemax(Int64), 3) work then?

I think the current behaviour is good enough, unless we decide to do a sensible checks for bounds, and add sensible errors when things overflow.

[tkelman]

How would range(typemax(Int64), 3) work then?

Right now that gives me 9223372036854775807:9223372036854775806, and I don't think adding promote_type would change anything for that case.

[ivarne]

That is a range with length of -1 (ie empty), when you would expect an error.

[tkelman]

I think the range function being smarter about checking whether a+len-1 is likely to overflow is a slightly separate issue from whether its type parameter should be determined just by the start point or by promotion of the start and length.

[mschauer]

Simple promotion will not do, one would expect range(0x1, 2) == 0x01:0x02, but range(promote(0x1, 2)...) == 1:2. This comes from the fact that if possible, length is measured as Int and the second parameter is a length-parameter. One could hardcode the cases where length is not Int maybe.