I think much of the problem is that many necessary packages (e.g. for
plotting) don’t currently allow Range/AbstractVector, and many functions in
Base are slower for ranges than for vectors. These are probably just teething
problems, but until they are resolved “collect” ends up needing to be used a
lot.
> On 22 Oct 2015, at 7:00 AM, Art Kuo <arthurd...@gmail.com> wrote:
>
> I don't think there is much to argue about, except perhaps names.
> `linspace` returns a range, but is otherwise a drop-in replacement for an
> array, and should act as one for any naive user, other than sometimes being
> faster and taking less memory. This is not hidden from the user, yet they
> need not be concerned about it. It just works. (The array might be better in
> some cases, I suspect rarely.)
> One might expect a `linspace` to show an array when typed into the REPL. With
> #13615
> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2FJuliaLang%2Fjulia%2Fpull%2F13615&sa=D&sntz=1&usg=AFQjCNESdEGtUlN_sTr8NTxWkldQaBZhYg>,
> post-0.4 the user will see that it is a range and also "what they expect."
> It is true that `logspace` is an array and `linspace` is a range, and this is
> ugly. Perhaps there should be a `logrange` to go with `linrange`, or
> `logspace` should be modified to be a range. I do agree with these complaints.
> The name `logspace` probably comes from Matlab, but otherwise has no
> significance and is not a great name. Perhaps it's worth keeping around for
> that reason; perhaps it should be stashed into a Matlab module.
> As much as I was attracted here by the Matlab-alikeness, that can be a
> detriment. For example, Matlab overloads `diag` so you get two very different
> things for two different inputs. Whereas Mathematica has long, clear names,
> and `DiagonalMatrix` and `Diagonal` give a better clue what will happen. And
> as much as I love `eye`, `IdentityMatrix` is clearer. Other Matlab-isms:
> `tril`, `pcg`, `alim`, `shg`.
>
>
> On Wednesday, October 21, 2015 at 3:16:58 PM UTC-4, Stefan Karpinski wrote:
> This thread is tragically long on opinions and short on arguments backing
> them up. It occurs to me that we can write specialized methods for
> collect(::LinSpace) that generate the collected version more efficiently than
> generic iteration does, which eliminates one of the potential arguments for
> just generating an array.
>
> On Wednesday, October 21, 2015, Gabriel Gellner <gabriel...@gmail.com
> <javascript:>> wrote:
> I agree with this downvote so much it hurts. The logspace/linspace is
> painfully ugly. linrange is the right name in my find for the iterator
> version.
>
> On Wednesday, 30 September 2015 10:31:55 UTC-7, Alex Ames wrote:
> Another downvote on linspace returning a range object. It seems odd for
> linspace and logspace to return different types, and linrange provides the
> low-memory option where needed. Numpy's `linspace` also returns an array
> object.
> I ran into errors when trying to plot a function over a linspace of x
> values, since plotting libs currently expect vectors as arguments, not range
> objects. Easily fixed if you know Julia well, but Matlab/Python converts may
> be stymied.
>
> On Wednesday, September 30, 2015 at 12:19:22 PM UTC-5, J Luis wrote:
> I want to add my voice to the dislikers. Those are the type of surprises that
> are not welcome mainly for matlab users.
>
> quarta-feira, 30 de Setembro de 2015 às 16:53:57 UTC+1, Christoph Ortner
> escreveu:
> I also strongly dislike the `linspace` change; I like the idea though of
> having `linspace` and `linrange`, where the former should give the array.
> Christoph
>
>
> On Wednesday, 30 September 2015 10:21:36 UTC+1, Michele Zaffalon wrote:
> I just realize that the thread is about 0.3.11 and I am showing output for
> 0.4.0-rc2. Sorry for the noise.
>
> On Wed, Sep 30, 2015 at 11:17 AM, Michele Zaffalon <michele....@gmail.com <>>
> wrote:
>
> On Wed, Sep 30, 2015 at 9:50 AM, Milan Bouchet-Valat <nali...@club.fr <>>
> wrote:
> Le mercredi 30 septembre 2015 à 08:55 +0200, Michele Zaffalon a écrit :
> > Just curious: linspace returns a Range object, but logspace returns a
> > vector because there is no much use case for a LogRange object?
> >
> > @feza: I have also seen the deprecation warning going away after a
> > couple of calls, but I am not sure why. If you restart Julia, the
> > deprecations reappear.
> Deprecation warnings are only printed once for each call place. The
> idea is that once you're aware of it, there's no point in nagging you.
>
> Anyway, that warning is most probably not related to linspace at all,
> but rather to the array concatenation syntax resulting in an effect
> equivalent to collect(). If you show us a piece of code that prints the
> warning, we can give you more details.
>
>
> Regards
>
> Sorry, you are right, I was referring to the concatenation.
> It prints it exaclty twice if I type it in the REPL, it always prints it if I
> define it within a function e.g. a() = [1:3].
>
> C:\Users\michele.zaffalon>julia
> _
> _ _ _(_)_ | A fresh approach to technical computing
> (_) | (_) (_) | Documentation: http://docs.julialang.org
> <http://docs.julialang.org/>
> _ _ _| |_ __ _ | Type "?help" for help.
> | | | | | | |/ _` | |
> | | |_| | | | (_| | | Version 0.4.0-rc2 (2015-09-18 17:51 UTC)
> _/ |\__'_|_|_|\__'_| | Official http://julialang.org/
> <http://julialang.org/> release
> |__/ | x86_64-w64-mingw32
>
> julia> [1:3]
> WARNING: [a] concatenation is deprecated; use collect(a) instead
> in depwarn at deprecated.jl:73
> in oldstyle_vcat_warning at abstractarray.jl:29
> in vect at abstractarray.jl:32
> while loading no file, in expression starting on line 0
> 3-element Array{Int64,1}:
> 1
> 2
> 3
>
> julia> [1:3]
> WARNING: [a] concatenation is deprecated; use collect(a) instead
> in depwarn at deprecated.jl:73
> in oldstyle_vcat_warning at abstractarray.jl:29
> in vect at abstractarray.jl:32
> while loading no file, in expression starting on line 0
> 3-element Array{Int64,1}:
> 1
> 2
> 3
>
> julia> [1:3]
> 3-element Array{Int64,1}:
> 1
> 2
> 3
>
> julia> a() = [1:3]
> a (generic function with 1 method)
>
> julia> a()
> WARNING: [a] concatenation is deprecated; use collect(a) instead
> in depwarn at deprecated.jl:73
> in oldstyle_vcat_warning at abstractarray.jl:29
> in a at none:1
> while loading no file, in expression starting on line 0
> 3-element Array{Int64,1}:
> 1
> 2
> 3
>
> julia> a()
> WARNING: [a] concatenation is deprecated; use collect(a) instead
> in depwarn at deprecated.jl:73
> in oldstyle_vcat_warning at abstractarray.jl:29
> in a at none:1
> while loading no file, in expression starting on line 0
> 3-element Array{Int64,1}:
> 1
> 2
> 3
>
> julia> a()
> WARNING: [a] concatenation is deprecated; use collect(a) instead
> in depwarn at deprecated.jl:73
> in oldstyle_vcat_warning at abstractarray.jl:29
> in a at none:1
> while loading no file, in expression starting on line 0
> 3-element Array{Int64,1}:
> 1
> 2
> 3
>
>
> > On Wed, Sep 30, 2015 at 5:40 AM, feza <moham...@gmail.com <>> wrote:
> > > Strange it *was* giving me an error saying deprecated and that I
> > > should use collect, but now it's fine.
> > >
> > >
> > > On Tuesday, September 29, 2015 at 10:28:12 PM UTC-4, Sheehan Olver
> > > wrote:
> > > > fez, I'm pretty sure the code works fine without the collect:
> > > > when exp is called on linspace it converts it to a vector.
> > > > Though the returned t will be linspace object.
> > > >
> > > > On Wednesday, September 30, 2015 at 12:10:55 PM UTC+10, feza
> > > > wrote:
> > > > > Here's the code I was using where I needed to use collect (I've
> > > > > been playing around with Julia, so any suggestions on this code
> > > > > for perf is welcome ;) ) . In general linspace (or the :
> > > > > notation) is also used commonly to lay a grid in space for
> > > > > solving a PDE for some other use cases.
> > > > >
> > > > > function gp(n)
> > > > > n = convert(Int,n)
> > > > > t0 = 0
> > > > > tf = 5
> > > > > t = collect( linspace(t0, tf, n+1) )
> > > > > sigma = exp( -(t - t[1]) )
> > > > >
> > > > > c = [sigma; sigma[(end-1):-1:2]]
> > > > > lambda = fft(c)
> > > > > eta = sqrt(lambda./(2*n))
> > > > >
> > > > > Z = randn(2*n) + im*randn(2*n)
> > > > > x = real( fft( Z.*eta ) )
> > > > > return (x, t)
> > > > > end
> > > > >
> > > > >
> > > > > On Tuesday, September 29, 2015 at 8:59:52 PM UTC-4, Stefan
> > > > > Karpinski wrote:
> > > > > > I'm curious why you need a vector rather than an object. Do
> > > > > > you mutate it after creating it? Having linspace return an
> > > > > > object instead of a vector was a bit of a unclear judgement
> > > > > > call so getting feedback would be good.
> > > > > >
> > > > > > On Tuesday, September 29, 2015, Patrick Kofod Mogensen <
> > > > > > patrick....@gmail.com <>> wrote:
> > > > > > > No:
> > > > > > >
> > > > > > > julia> logspace(0,3,5)
> > > > > > > 5-element Array{Float64,1}:
> > > > > > > 1.0
> > > > > > > 5.62341
> > > > > > > 31.6228
> > > > > > > 177.828
> > > > > > > 1000.0
> > > > > > >
> > > > > > > On Tuesday, September 29, 2015 at 8:50:47 PM UTC-4, Luke
> > > > > > > Stagner wrote:
> > > > > > > > Thats interesting. Does logspace also return a range?
> > > > > > > >
> > > > > > > > On Tuesday, September 29, 2015 at 5:43:28 PM UTC-7, Chris
> > > > > > > > wrote:
> > > > > > > > > In 0.4 the linspace function returns a range object,
> > > > > > > > > and you need to use collect() to expand it. I'm also
> > > > > > > > > interested in nicer syntax.
>
>
