# 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!