Thanks for pointing this out. Briefly skimming over the doc had me confusing 'length' with the expected 'stop' argument.
Am Sonntag, 6. Dezember 2015 08:56:11 UTC+1 schrieb Gabor: > > I am also surprised at this behaviour, but it is certainly not a bug. > Have a look at the help: > > help?> range > range(start, [step], length) > Construct a range by length, given a starting value and optional step > (defaults to 1). > > help?> colon > .. \:(start, [step], stop) > Range operator. ``a:b`` constructs a range from ``a`` to ``b`` with a > step size of 1, > and ``a:s:b`` is similar but uses a step size of ``s``. > These syntaxes call the function ``colon``. > The colon is also used in indexing to select whole dimensions. > colon(start, [step], stop) > Called by : syntax for constructing ranges. > > > On Sunday, December 6, 2015 at 8:41:34 AM UTC+1, Jürgen Bohnert wrote: >> >> >> >> Hi everyone, >> >> I found some really strange behaviour of the 'range' function >> >> range(1,5) >> > 1:5 >> everything is OK >> >> range(2,5) >> > 2:6 >> NOT OK! >> >> range(10,20) >> > 10:29 >> NOT OK! >> >> However, if I define the range like so >> 10:20 >> > 10:20 >> OK and obviously works for all you guys as well. >> >> Am I missing some syntax or is this a bug? >> >> >> >> Also: is there a way to redefine the default behaviour of the >> range-syntax? It's really annoying having to 'Int' everything when I'm just >> specifying limits that get coerced to 'Float' because of division but are >> otherwise 'X.0' >> N=2^3 -1 >> > 7 >> imid = (N+1)/2 >> > 4.0 >> range(imid-2, imid+2) >> > ERROR: MethodError: 'range' has no method matching range(::Float64, :: >> Float64) >> >> Thanks for helping, >> Juergen >> >> julia build: >> Version 0.4.1 (2015-11-08 10:33 UTC) >> both: >> >> - x86_64-w64-mingw32 >> - x86_64-linux-gnu >> >> >> >> >> >> >> >>
