Phew! Heady stuff. So under that PR we would have Base.mightalias(m, m) == false? (I might be missing the point altogether, this is a bit too advanced for me :-D)
My main takeaway from all of this is ājust use a for loopā 
4 Likes
Thatās very true for every piece of Julia code, but itās quite frustrating when one is forced to write nested loops to keep performance or use weird @views, copyto!, getindex, etc., instead of a simple m[:,1:2] = m[:,2:3] as in Fortran or MATLAB. Sometimes when I port some Fortran code to Julia with a lot of operations on array slices and vectorized functions, I end up with a more complex Julia code to achieve the same performance. Iām not sure if this is a very tough problem, e.g. because of using a GC or itās the design of dynamic languages in general, but Iām sure that Julia is improving day after day. Can I expect this to be solved in a near major release, or am I too optimistic?
2 Likes
Iām not saying that people should just use a for loop because itās faster in this caseāthere are view-based solutions of utility functions that are just as efficient. In this case I just think a for loop is easier to understand. Otherwise I have to look up the copyto! function to know how it works.
The way I see it Julia allows you to reason about what actually happens when you do m[:,1:2] = m[:,2:3]. It teaches you to think about the possible pitfall of overwriting what you want to copy. Other languages will isolate you from these pitfalls by making a copy always, so that you donāt shoot yourself in the foot. In Julia you actually have different options, which allow you to achieve much higher performance. Actually you can do m[:,1:2] = m[:,2:3] in Julia. It will make a copy, and work like in MATLAB or Mathematica. However Julians will not consider that an optimal choice simply because you have better, non-allocating options, as discussed here, unlike in many other high-level languages. Freedom is never bad!
2 Likes