Yes, this one will be changed in the future (1.0-DEV below):
julia> A .+ I
┌ Warning: broadcast will default to iterating over its arguments in the future. Wrap arguments of
│ type `x::UniformScaling{Bool}` with `Ref(x)` to ensure they broadcast as "scalar" elements.
│ caller = ip:0x0
└ @ Core :-1
2×2 Array{Float64,2}:
2.0 2.0
2.0 2.0
https://github.com/JuliaLang/julia/pull/28456/commits/3b84ab46d4ec1aab70ee537e0d1a704e0df84b10.
there was a really witty comment in ‘stdlib/LinearAlgebra/src/deprecated.jl’ (gone now too):
- ## goodbeye, eye!
- export eye
- function eye(m::Integer)
- depwarn(string( ...
- ...
Does this actually work in 1.0? I tried range(0, pi, length = 50) and I get
ERROR: MethodError: no method matching range(::Int64, ::Irrational{:π}; length=50)
Closest candidates are:
range(::Any; length, stop, step) at range.jl:76
Stacktrace:
[1] top-level scope at none:0
I actually really like the move to range for this, but don’t want to use stop 
1.0 was just removal of the deprecation. The possible features that can now be implemented are slated for 1.1.
Excellent to know that! I was thinking to submit v0.7 to openSUSE and wait sometimes so that the users can have the opportunity to fix everything. Now, I am really comfortable to do this
ouch this will be painful for my code 
I guess I will wait for 1.1
What is wrong with the new way of doing this?
range(0, stop = pi, length = 50)
The keyword stop is because there are other ways you could construct these. From the help
julia> range(1, length=100)
1:100
julia> range(1, stop=100)
1:100
julia> range(1, step=5, length=100)
1:5:496
julia> range(1, step=5, stop=100)
1:5:96
Don’t get me wrong, I get the design (very much like R’s seq) which I like. I just find, and in the early discussion of this thought 1.0 would have the stop default, that the linspace like behavior is the most common.
Having:
linspace(0.01, 22.3, 1000)
range(0.01, stop = 22.3, length = 1000)
range(0.01, 22.3, length = 1000)
Just feels so crazy verbose using the stop version. Heck julia smashes every possible word together for fear of a adding 1-3 _ this feels far worse for such a common operation.
Still I get the decisions, I just don’t want to change all my code to use the stop version, and then remove it all for 1.1.
Writing your own wrapper is trivial. Why don’t you do that?
personal taste. I really dislike making my own private Julia idioms … as I feel it makes all my code examples a hassle to share with others in my lab (they need to use the GabioVerse for all the things I want different if they are building on my examples etc.) and it makes a barrier for future connections with standard tutorials, stack exchange etc. It is the same reason I really dislike the .juliarc solutions, and wrapper packages to make julia look like other languages … reminds me of the old pain of using peoples Maple code with all the private imports, aliases, etc. I really like having a more python style of “one obvious way to do things” versus the, what I understand to be, the Lisp way of many private / custom languages.
I will come around, I just hoped I could move to 1.0 sooner. I just have too much Julia code at this point 
a good problem I guess, but I find it is making me more conservative these days. I am really excited for 1.0’s hopefully slowing down of major language changes!
I did that: https://github.com/mcreel/Econometrics.jl/blob/master/src/Utilities/eye.jl
It is pretty easy to personalize things this way. I do sympathize with the previous post, though, and I may not actually use this function much. It’s just to make sure old code doesn’t break.
TBH, this is one of the worst decisions Julia has made recently. In my opinion, there was no need at all for this, look at the following verbose, “ugly” constructs and their straightforward replacements, I hoped they had just replaced the word linspace with range.
julia> range(1, length=100)
julia> range(1, stop=100)
julia> range(1, step=5, length=100)
julia> range(1, step=5, stop=100)
vs.
julia> 1:100
julia> 1:100
julia> 1:5:5*100
julia> 1:5:100
I’m still full of hope, though, that these small annoyances will be resolved shortly by the vibrant Julia community.
But you can still use : to construct ranges, so I don’t see how that is troubling…
IMHO I prefer:
range(1,stop=2π,length=64)
to
1:((2π-1)/63):2π #did I get this right??
And what is wrong with range(1,2π,64)? Unless I’m missing something obvious, this is by far very concise and clean.
To clarify:
linspace(start, stop, length)
# becomes
range(start, stop, length)
# and
range(start, step, length)
# becomes
start:step:step*length
I thought all of these still work in 1.0, or at least they do for now… Of course, with floating points this is a little trickier since 1.0:0.6:2.0 returns something like 1.0:0.6:1.6, but that seems the right.
Yes, none of these have been deprecated. Might I suggest that people actually try things before complaining that they don’t work.
Yes, of course 1:5:100 etc. still works. It would create havoc for all indexing if those went away.
I will miss linspace though, since it’s such a convenience for interactive work, especially plotting.
Does there exist any popular package for interactive, REPL workflow things?
I don’t think @Seif_Shebl was arguing that the 1:5:100 wouldn’t work, but that the new range functionalities were not necessary since you could already build ranges in that way.
Personally putting all these functionalities in a single function and customising its behaviour via keywords arguments doesn’t strike me as very elegant, but maybe that’s the best we can do.
I’ll certainly have linspace and logspace defined in my loading script, since I’m using them all over the place (more than 500 occurences on my local codebase).
Bonus question, is there a way to do that: linspace(extrema(x)...,100)
OK, that might have been a misunderstanding. But the fact is that you cannot replace many range calls with simple a:b:c syntax; most obviously the ones that use the stop keyword, but range also does a lot of work to get numerical accuracy right, which a:b:c can skip right over.
I actually think that collecting the functionality in a single function is very elegant, but I also think it’s not very user-friendly in an interactive context.
There is an InteractiveUtils library now, which exports functions that are useful when using the REPL. Maybe there could be something similar for other productivity tools? Or maybe Plots.jl could export a linspace method?
My comment was not as negative as some people got it, I meant that Julia is sometimes too brave when adding or removing functionality. One great example that I liked so much was allowing atan to accept 2 arguments and dropping the well-known atan2 used by many older languages, that was an improvement and pretty natural. But in our case, they removed linspace without introducing a nice replacement. For interactive work, these kinds of functions are of utmost importance, one should think a million times before removing them. When people are constantly adding something to startup.jl, that’s a clear sign that Julia missed some obvious default.