UnitRange in 1.7-rc1, bug?

(1:5) .- 1/7 in 1.7-rc1 (Win64) gives 0.8571428571428572:1.0:3.857142857142857,
while 1.6.2 gives (the more reasonable) 0.8571428571428572:1.0:4.857142857142858

Can anyone confirm? If so, I’ll file an issue.

2 Likes
julia> collect((1:5) .- 1/7)
4-element Vector{Float64}:
 0.8571428571428572
 1.8571428571428572
 2.857142857142857
 3.857142857142857

julia> collect((1:5)) .- 1/7
5-element Vector{Float64}:
 0.8571428571428572
 1.8571428571428572
 2.857142857142857
 3.857142857142857
 4.857142857142857

likely a bug, I’m surprised we don’t have this consistency test (i.e. length should be the same).

On the other hand, in 1.6.2 if we wrote:

julia> 1 - 1/7 : 5 - 1/7
0.8571428571428572:1.0:3.857142857142857

That looked more inconsistent with the (1:5) .- 1/7 result.
The 1.7 results seem to be more self-consistent.

Simpler example:

julia> (1:5) .- 2
-1:3

From what I know of floating point numbers and Julia ranges, this sounds like an extremely difficult requirement. Never mind, I forgot that there is indeed an object with explicit length within these calculations.

(mostly guessing here since base/range.jl is a bit overwhelming). If the behaviour has changed (1.6->1.7) from (a) first do 1:5 then subtract 1/7 from each element to (b) do 1-1/7:5-1/7, then this should probably be documented.

For my immediate code, I’ll probably change everywhere to range(1,5,length=5) .- 1/7

There’s probably something more intricate going on here since

julia> length((1:5) .- 1/7) == length((1.0:5) .- 1/7)
false

length((1:5) .- 1/7) == 4 looks very wrong to me and 1.7.0-beta3 still gave the correct size of 5, please file a bug!

Done (UnitRange in 1.7-rc1 · Issue #42291 · JuliaLang/julia · GitHub)