Skip to content

Conversation

@Sacha0
Copy link
Member

@Sacha0 Sacha0 commented Nov 2, 2017

This pull request deprecates eye in favor of I and Matrix constructors (e.g. ... == I rather than ... == eye(...) and Matrix{T}(I, n) rather than eye(T, n)). Regarding the eye call rewrites in test/, the rewrites are for the most part conservative rather than potentially ideal (e.g. ... == eye(T, 3, 4) -> ... == Matrix(I, 3, 4) rather than ... == I); see JuliaLang/LinearAlgebra.jl#454. Addresses JuliaLang/LinearAlgebra.jl#454. Best!

(I expect a cascade of CI failures and subsequent iteration on this pull request, hence the WIP.)

@Sacha0 Sacha0 added arrays [a, r, r, a, y, s] deprecation This change introduces or involves a deprecation linear algebra Linear algebra needs news A NEWS entry is required for this change triage This should be discussed on a triage call labels Nov 2, 2017
@Sacha0 Sacha0 removed the needs news A NEWS entry is required for this change label Nov 2, 2017
@Sacha0 Sacha0 force-pushed the goodbeye branch 2 times, most recently from 8af3e9a to 02d2d38 Compare November 2, 2017 04:31

@deprecate eye(::Type{Diagonal{T}}, n::Int) where {T} Diagonal{T}(I, n)
## goodbeye, eye!
export eye
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In theory, I guess we also need

@eval Base.LinAlg import Base.eye
@eval Base.SparseArrays import Base.eye

if someone uses LinAlg.eye(...) or SparseArrays.eye() in their codes. I don't think we have done that before, but perhaps we should, since changes like this should not break code :)

# Examples
```jldoctest
julia> A = 2.7182818 * eye(2)
julia> A = Matrix(2.7182818I, 2)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The I looked like a 1 at first sight and I was confused... Perhaps add an explicit *? Matrix(2.7182818*I, 2)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Revised accordingly on push. Thanks!

- The subdiagonal part contains the reflectors ``v_i`` stored in a packed format where
``v_i`` is the ``i``th column of the matrix `V = eye(m,n) + tril(F.factors,-1)`.
``v_i`` is the ``i``th column of the matrix `V = I + tril(F.factors, -1)`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sizes m and n not needed? Same on the changes below.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Omitting the explicit m and n in this documentation seems preferable on this end, particularly if we relax addition with UniformScalings to behave generally as it does with sparse matrices (as discussed on triage).

## Low level interface
@test CHOLMOD.nnz(A1Sparse) == nnz(A1)
@test CHOLMOD.speye(5, 5, elty) == eye(elty, 5, 5)
@test CHOLMOD.speye(5, 5, elty) == Matrix(I, 5)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably does not matter, but perhaps Matrix{elty}(I, 5)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In ==, the Matrix(I, ...) on the right-hand-side lifts to the eltype of the left-hand-side, making the eltype specification on the right unnecessary :).

ilo, ihi, scale = LAPACK.gebal!('B', A) # modifies A
nA = norm(A, 1)
I = eye(T,n)
Inn = Matrix{T}(I, n)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great example why exporting single-character names is a bad idea :)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the other hand, in all recent work related to I I have found only two such collisions IIRC, indicating that in practice this issue is not so great :).

"constructors. For a direct replacement, consider `Matrix(1.0I, m)` or ",
"`Matrix{Float64}(I, m)`. If `Float64` element type is not necessary, ",
"consider the shorter `Matrix(I, m)` (with default `eltype(I)` `Bool`)."), :eye)
return Matrix{Float64}(I, m)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should be Matrix{Float64}(I, m, m).

@StefanKarpinski StefanKarpinski removed the triage This should be discussed on a triage call label Nov 2, 2017
@Sacha0 Sacha0 added this to the 1.0 milestone Nov 2, 2017
@Sacha0
Copy link
Member Author

Sacha0 commented Nov 2, 2017

Plan per triage: Remove the single-integer Matrix(I, ...) methods and merge. Best!

@Sacha0 Sacha0 force-pushed the goodbeye branch 2 times, most recently from c6e46ad to f48bf94 Compare November 5, 2017 19:32
@Sacha0
Copy link
Member Author

Sacha0 commented Nov 5, 2017

Rebased and revised per triage, removing all single-integer Matrix constructor calls.

Removing those calls strongly reaffirmed what I conveyed weakly in triage: Constructing a non-square identity matrix is the rare exception; eye(n)/speye(n) is far and away the most common invocation mode. Consequently, having to use the two-integer constructor form feels like a meaningful usability regression, results in noticeably more mistakes, and makes expressions like Matrix(1.0I, size(Q.factors, 1)) much less wieldy (as Matrix(1.0I, size(Q.factors, 1), size(Q.factors, 1)) or (sQf1 = size(Q.factors, 1); Matrix(1.0I, sQf1, sQf1)) where possible). In other words, having only the two-integer constructor form feels in practice like burdensome purism. We should consider again whether that real cost is worth avoiding the perceived risk. Best!

@kshyatt
Copy link
Member

kshyatt commented Nov 6, 2017

Why is this not titled "eye speye deprecated methods"?

Anyway looks great but could you rebase?

@Sacha0
Copy link
Member Author

Sacha0 commented Nov 6, 2017

Why is this not titled "eye speye deprecated methods"?

That's brilliant! #24356 now has a vastly superior title.

(Also https://media.giphy.com/media/DvtsYOKrqPZg4/giphy.gif :).)

@Sacha0 Sacha0 force-pushed the goodbeye branch 2 times, most recently from 7d86a5b to 220061d Compare November 18, 2017 22:26
@Sacha0
Copy link
Member Author

Sacha0 commented Nov 18, 2017

Rebased and (hopefully) fixed the test/sparse/sparse.jl, test/linalg/tridiag.jl, and test/linalg/uniformscaling.jl failures. Assuming CI approves and absent objections or requests for time, I plan to merge this pull request tomorrow. Best!

@Sacha0 Sacha0 changed the title [WIP] eye see deprecated methods eye see deprecated methods Nov 18, 2017
@Sacha0 Sacha0 merged commit 06a6afb into JuliaLang:master Nov 20, 2017
@Sacha0 Sacha0 deleted the goodbeye branch November 20, 2017 02:49
@Sacha0
Copy link
Member Author

Sacha0 commented Nov 20, 2017

Thanks all! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

arrays [a, r, r, a, y, s] deprecation This change introduces or involves a deprecation linear algebra Linear algebra

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants