-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace all full(X) calls with convert(Array, X) and migrate tests #18850
Conversation
Any reason not to use the compact |
Good catch! No reason. I wrote |
29dcbd8
to
51f2e80
Compare
Replaced |
@@ -38,7 +38,7 @@ Bidiagonal(dv::AbstractVector, ev::AbstractVector) = throw(ArgumentError("did yo | |||
Constructs an upper (`uplo='U'`) or lower (`uplo='L'`) bidiagonal matrix using the | |||
given diagonal (`dv`) and off-diagonal (`ev`) vectors. The result is of type `Bidiagonal` | |||
and provides efficient specialized linear solvers, but may be converted into a regular | |||
matrix with [`full`](:func:`full`). `ev`'s length must be one less than the length of `dv`. | |||
matrix with [`Array(_)`](:func:`convert`). `ev`'s length must be one less than the length of `dv`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
which should these be linking to?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
convert
? Would ...may be converted into a regular matrix with [
convert(Array, )](:func:
convert) (or
Array() for short)...
be better? Thoughts? Thanks!
A_mul_B!{T<:BlasFloat}(A::LQ{T}, B::QR{T}) = A[:L]*LAPACK.ormlq!('L','N',A.factors,A.τ,full(B)) | ||
A_mul_B!{T<:BlasFloat}(A::QR{T}, B::LQ{T}) = A_mul_B!(zeros(full(A)), full(A), full(B)) | ||
A_mul_B!{T<:BlasFloat}(A::LQ{T}, B::QR{T}) = A[:L]*LAPACK.ormlq!('L','N',A.factors,A.τ,Array(B)) | ||
A_mul_B!{T<:BlasFloat}(A::QR{T}, B::LQ{T}) = A_mul_B!(zeros(Array(A)), Array(A), Array(B)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wouldn't zeros(size(A))
be equivalent and allocate less?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good call. Fixed on push. Thanks!
(./)(A::Number, B::SparseMatrixCSC) = (./)(A, Array(B)) | ||
(./)(A::SparseMatrixCSC, B::Array) = (./)(Array(A), B) | ||
(./)(A::Array, B::SparseMatrixCSC) = (./)(A, Array(B)) | ||
(./)(A::SparseMatrixCSC, B::SparseMatrixCSC) = (./)(Array( A), Array(B)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
excess space in Array( A)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch. Fixed on push. Thanks!
@@ -119,7 +119,7 @@ for elty in (Float32, Float64, Complex64, Complex128, Int) | |||
invFsv = Fs\vv | |||
x = Ts\vv | |||
@test x ≈ invFsv | |||
@test full(full(Tldlt)) ≈ Fs | |||
@test Array(Array(Tldlt)) ≈ Fs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what's going on here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you asking why we have two full
calls? It's because the first full
goes LDLt -> Tridiagonal
, and the second goes Tridiagonal -> Matrix
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah right my "use a different name for..." issue. what type does Array(::LDLt)
return?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Derp is what's going on here. Fixed on push. (Array(::LDLt)
returns an Array
.) Thanks!
If it's consistent with the old API it should be one of Tridiagonal or On Wed, Oct 12, 2016, 11:41 AM Tony Kelman [email protected] wrote:
|
the return type of |
@tkelman probably better to open a new issue/find that old one for this, but... |
...or |
Are the factorizations themselves AbstractArrays? There's a bug here, the PR that reimplemented full in terms of convert did not do so correctly for the factorization types, and now this test change is not testing the original intent either. |
…ide base/sparse and base/linalg), apart from the no-op fallback for s in abstractarray.jl.
…and test/linalg. Migrate full to convert in some documentation.
In #12153 consensus was to replace julia> A = SymTridiagonal(2*ones(4), ones(3));
julia> FA = factorize(A)
Base.LinAlg.LDLt{Float64,SymTridiagonal{Float64}}([2.0 0.5 0.0 0.0; 0.5 1.5 0.666667 0.0; 0.0 0.666667 1.33333 0.75; 0.0 0.0 0.75 1.25])
julia> convert(AbstractMatrix, FA)
4×4 SymTridiagonal{Float64}:
2.0 1.0 ⋅ ⋅
1.0 2.0 1.0 ⋅
⋅ 1.0 2.0 1.0
⋅ ⋅ 1.0 2.0
julia> convert(Array, FA)
4×4 Array{Float64,2}:
2.0 1.0 0.0 0.0
1.0 2.0 1.0 0.0
0.0 1.0 2.0 1.0
0.0 0.0 1.0 2.0 but julia> full(FA)
4×4 Array{Float64,2}:
2.0 1.0 0.0 0.0
1.0 2.0 1.0 0.0
0.0 1.0 2.0 1.0
0.0 0.0 1.0 2.0 Having a look at that now (edit: found bug, PR forthcoming), but should be orthogonal to this PR. Thanks and best! |
#18938 indicates that some of the tests touched in this PR should be more strict. Similarly, some of the Additionally, we never resolved the Perhaps breaking this PR up into a series of smaller PRs would make this transition safer / smoother? (To decouple the simple, safe cases from the tricky ones?) Thoughts? Thanks and best! |
We are looking for a generic function that returns the wrapped array type with elements equal to the wrapper. That function used to be called An alternative solution would be to have a |
So far we've disambiguated two of
Yes, in #17066 we agreed that this approach to handling Seems we have consensus that something like Best! |
I don't question that a renaming was a good idea but I think there is a common pattern among the annotation types and the Thanks for reminding of #17066 (comment) in which I conclude that |
The series of pull requests listed just above should cover all files in which all instances of |
Could a way forward be to try to define a |
Sounds good, and shall do! Thanks! |
With #12153 on the 1.0 milestone, perhaps this PR should receive a 1.0 tag as well? |
In some cases would it make sense to convert to |
Absolutely! :) Replacing |
Closed by #24250 and the series of preceding pull requests. Best! |
This PR reconstitutes and rebases #17079. #17079 was reverted in #17564 due to JuliaStats/DataArrays.jl#208; the series of PRs associated with #17660 should prevent this PR from causing JuliaStats/DataArrays.jl#208 to reoccur (see also #12153 (comment)). Best!