Why `eye` has been deprecated?

I don’t think there is anything wrong with being a janitor, and I have in fact often heard that title used in a respectful way about people who do a lot of important, low-profile work.

While I agree with much of your post, I didn’t see any devaluation of “janitorial tasks” in @stillyslalom’s post.


In finance and econometrics, there’s often a fair number of I_n (eye(n)) floating around in the papers/texts. Since I like my programs to stick closely to the “theory,” this carries over to my attempts to code.

In the run up to 0.7, I spent some time purging eye from all my code for my lecture notes (and using I instead). In line with Stefan’s forecast, I had 95% luck. I believe that the only remaining case that I still have is a couple of kron(X,I) where X is a square matrix. However, I suspect it qualifies as an anti pattern.


This is temporarily worse than it will be in the future. With the deprecation removed in 1.0-dev, we can now have a pull-request to allow range(0, pi, length=50).

Moderator’s note: I’ve split this thread as best I could.


Ok so maybe rather than just my specific suggestions of contributing to the Wikibook and working on a MatlabToJulia.jl (or modernizing MatlabCompat.jl) is anyone interested in forming some sort of MATLAB/Julia users SIG which can do these sorts of things (including others’ probably better ideas than mine) in a coordinated way? This could just be a sub-forum here on Discourse (and, if people insist, a Slack channel, but ugh, Slack :slight_smile: ).

I think individually we probably are very busy and have little time but collectively we can do a lot to turn some of the kinds of discussion we have on threads like these into some concrete solutions that build on the (1.0) core language.


Count on me! 99,99% of the engineers at INPE (National Institute for Space Research) use MATLAB and an easy update path is required :slight_smile:

I think MatlabCompat is fine. But we need to make it come back to life.


I’m sorry, my tone was a bit sharp. Most of the small handful of contributions I’ve made to the language and ecosystem have been docs-related, I’ve worked as an actual janitor, and I really do appreciate well-written documentation. I’m just looking forward to the ecosystem documentation/blogs/examples catching up to the language (and ready to help once 1.0 and major peripheral packages are stable).

Re: Matlab, I don’t think we need to copy the syntax, per se, but I’d like a Batteries.jl or KitchenSink.jl package that just reexports other packages to provide functionality on par with what’s built into Matlab. (FFTW, SpecialFunctions, Plots, LinearAlgebra, Images, DataFrames, Interpolations, Roots, Random, LsqFit, QuadGK, DifferentialEquations, ???)


Frankly I feel that Matlab developers have made a number of questionable choices over the years, and very rarely they made the effort to correct them. Consistency and obviousness is a great advantage of Julia!


@StefanKarpinski could we get perhaps a subcategory of Development?

https://github.com/ChrisRackauckas/Cuddle.jl ? :troll:


I’m not Stefan, but I’m also a moderator here — why don’t you start with a new thread and if there’s sufficient interest/traffic we can expand it out to a subcategory. Really, though, I think this would be best coordinated around a specific repository (like MatlabCompat) and discussion within issues there.


On a related note, could someone post a one-liner that creates a dense Float64 identity matrix in both 0.6 and 0.7 with no deprecation warnings? Here is what I using now:

   eye1 = zeros(n,n)
   for i = 1 : n
        eye1[i,i] = 1.0

With Compat you can use

Matrix{Float64}(I, n, n)

on both versions.


I didn’t say that being a janitor was bad, or something that is offensive to be compared to. I said that the comparison wasn’t fair, and the following text was supposed to explain why…

A janitor does important work, but it is routine work: cleaning, moving stuff around, and maybe doing some small repairs - but nothing that requires specialized, skilled (licensed) work. What I’m saying is that proper documentation and testing is not routine work. If you’ve ever had to document or test a program you did not write yourself you’ll know what I mean. It requires lots of knowledge and ability to read and understand code to do this well.

Anyway, since I don’t think there were any ill intentions I don’t think we should continue this sub-thread beyond this message. I think we’re all on the same page :slight_smile:


Count me too. MatlabCompat has the right name but I would prefer a package without the dependencies it has.

Maybe you want to make MatlabCombat a metapackage, which reexports. This way the package which implements eye and similar won’t have any dependencies.

But at some point you just start doing Matrix(1.0I,n,n)

1 Like

Frankly, I don’t think that relying on idioms from other languages in parallel with Julia’s own is a good idea. I understand that people miss eye and similar, but they were removed for a reason. IMO just learning idiomatic Julia and keeping up with the changes is a better solution in the long run.

For example, I recently brought a library of mine up to date with v0.7, and had to rewrite a lot of uses of diagm & friends. A lot of time time this involved much more than simple replacement (thinking about what the deprecation message suggests, and reshaping it to my use case), but now the resulting code is much cleaner.


I use kron(X,I) all the time as well for quantum gates, and in S & R-matrices of quantum integrable models. Having a space-efficient solution for tensor products of different kinds of matrices in general would be very nice.


I agree: creating lazy kron types would be awesome for saving memory. Going down the route to better exploit the type system for efficiency is much more fruitful than trying to just make unnecessary matrices.


That’s all fine for library development but don’t underestimate the additional mental effort in parsing Matrix(1.0I, n, n) vs eye(n)

Edit: though I(n) would be nice I guess