Strange inclusive range issue

Hi, folks.
Bumped into this today and it forced me to switch do degrees.

(0:(2π/101):2π)[end] # 6.283185307179586
(0:(2π/102):2π)[end] # 6.283185307179586
(0:(2π/100):2π)[end]# 6.220353454107791

Note that the last result is 2π-2π/100, meaning it’s as if the series does not include the last value.
I noticed this also for 50.
Is this a bug or some weird floating point artefact?
Thanks!
(Julia 1.5.3)

this parts make a float first, and then you just lose to float point error.

do this instead:

julia> range(0, stop=2pi, length=100)[end]
6.283185307179586

julia> range(0, stop=2pi, length=101)[end]
6.283185307179586

julia> range(0, stop=2pi, length=102)[end]
6.283185307179586
7 Likes

Thanks! I didn’t know that syntax.

You don’t need to write stop, and very soon length isn’t needed either.

1 Like

@DNF, there is already LinRange with such syntax.

you just mean that they don’t need to be keyword. But I can’t remember the combination of 4 pick 3 and what position means what, so I will keep writing so readers are clear of it too.

To me the order is so natural, I can’t wait to get rid of the ugly keywords.

Yes, I am very much aware. It always seemed like some internal hackery, though I know it’s documented now. It somehow seems wrong to use a type constructor to do a function’s job.