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