Why `eye` has been deprecated?

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:

2 Likes

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.

5 Likes

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.

2 Likes

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.

4 Likes

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

5 Likes

Based on the idea in the post above, how about something like

identity(Float64, n) 

Then you can specify the type and n, and you don’t have to type n twice.

Float64 is the default

But when are you actually using this? I haven’t seen a code that should be making a dense identity matrix in a very long time. Does something that shows up up once every few hundred thousand lines of code really need a special shortened syntax?

2 Likes

My comment was general, not specific.

But fwiw I regularly use speye

Why not treat it as rand()? That’s, eye(n) is the default, the second n is redundant, and A .+ eye() is similar to A .+ rand() and eye(Int8,n), eye(Int16,n),eye(Int32,n),eye(Int64,n), eye(Float32,n) all with their obvious meanings are similar to their rand([..,] <size>) counterparts.

It’s not a sin to use a well-known, easy to remember and type, function from language X in Julia unless it is too bad. Also I seems a pretty natural choice, only if used as eye() described above. When I first used Julia, Version 0.2 I think, It was so intuitive and easy that I understood every thing in 3 days. I even delivered some lectures to colleagues who are 99% MATLAB users and many of them were impressed. Now, if say there is no eye but Matrix{Float64}(I, n, n), no linspace but range(start, step=, stop=), etc., I imagine people saying Ughhh … Also dims =, why all these unnecessary changes, too much explicitness leads to verbosity and noise. If something is intuitive and frequently used keep it very short and memorable. If you had to add dims =, for example, why not just dim = as Fortran?

This is not to say that all latest changes are bad at all, in fact Julia has made very nice improvements lately, the ones I mentioned are only small examples that need more reexamination.

1 Like

Not sure if this can be avoided, but the update step of the Kalman filter requires an identity matrix:

Pu_k = (eye(n) - K_k*H_k)*Pp_k

Actually, it was when I coded a Kalman filter in v0.7 that I realized it was deprecated and then I started the original thread.

Why doesn’t

Pu_k = (I - K_k*H_k)*Pp_k

work?

2 Likes

There is no eye, but there is I.

Excellent! I just did not thought about it :smiley: Thanks. Will it work in every operation that uses identity?

I am seeing some problems here, but maybe it is just my ignorance:

julia> A = zeros(3,3)
3×3 Array{Float64,2}:
 0.0  0.0  0.0
 0.0  0.0  0.0
 0.0  0.0  0.0

julia> (I+A.+1)
3×3 Array{Float64,2}:
 2.0  1.0  1.0
 1.0  2.0  1.0
 1.0  1.0  2.0

julia> (I.+1+A)
┌ Warning: `a::Number + b::AbstractArray` is deprecated, use `a .+ b` instead.
│   caller = top-level scope at none:0
└ @ Core none:0
3×3 Array{Float64,2}:
 2.0  2.0  2.0
 2.0  2.0  2.0
 2.0  2.0  2.0

Is it expected?

I don’t know! :slightly_smiling_face:

Your example caught me by surprise. I’ve simplified it, and I think it’s weird:

julia> A = ones(2, 2)
2×2 Array{Float64,2}:
 1.0  1.0
 1.0  1.0

julia> A + I
2×2 Array{Float64,2}:
 2.0  1.0
 1.0  2.0

julia> A .+ I
2×2 Array{Float64,2}:
 2.0  2.0
 2.0  2.0
1 Like

Yes, that’s known and deprecated in 0.7 to make space for it operating correctly in 1.x.

3 Likes

I before E(ye) except after RC


here’s some cambridge graffiti to get you through the next couple days

2 Likes