It is not a shocker to me. The problem is that Floating point numbers represent binary fractions, and there is no way for linrange() to actually get equidistant values you are looking for. It has to do approximations, and thus it will sometimes miss closest possible value. That means equality checks on floating point numbers should be used with extreme care.
Our implementation reuses the old step size when indexing a FloatRange with a range, but we could probably do better if we tried to keep the last point equal. I reopened https://github.com/JuliaLang/julia/issues/7420 to keep track of this issue. Ivar kl. 07:07:25 UTC+2 onsdag 2. juli 2014 skrev Peter Simon følgende: > > The final result below seems really strange to me. A bug? > > julia> x = linrange(1,10,20) > 1.0:0.47368421052631576:10.0 > > > julia> 10 .<= x # Gives expected result > 20-element BitArray{1}: > false > false > false > false > false > false > false > false > false > false > false > false > false > false > false > false > false > false > false > true > > julia> 10 .<= x[end] # Gives expected result > true > > julia> 10 .<= x[2:end] # The last entry in this result is a shocker to > me! > 19-element BitArray{1}: > false > false > false > false > false > false > false > false > false > false > false > false > false > false > false > false > false > false > false > > > > Here is the version info: > > > julia> versioninfo() > Julia Version 0.3.0-prerelease+3987 > Commit 7dd97fa (2014-06-30 23:12 UTC) > Platform Info: > System: Windows (x86_64-w64-mingw32) > CPU: Intel(R) Core(TM) i7 CPU 860 @ 2.80GHz > WORD_SIZE: 64 > BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY) > LAPACK: libopenblas > LIBM: libopenlibm > >
