Fix #16519 by adding missing convert methods #17848
Conversation
This commit will allow a user to call: ```julia convert(Vector, my_abstractvector_of_eltype_Foo) convert(Matrix, my_abstractmatrix_of_eltype_Foo) ``` which is useful because - for the case that the variable is a subarray of the same dimensionality - for consistency with PR #17066 The same effect can (and could before this commit) also be achieved in the following manner. Note how the two last lines are unnecessarily verbose, because the eltype can be inferred ```julia convert(Array, my_abstractvector_of_eltype_Foo) convert(Array, my_abstractmatrix_of_eltype_Foo) convert(Vector{Foo}, my_abstractvector_of_eltype_Foo) convert(Matrix{Foo}, my_abstractmatrix_of_eltype_Foo) ```
|
cc: @Sacha0, @cstjean, @nalimilan |
|
Looks great! |
kshyatt
added
linear algebra
|
Nice! From your description, I should be able to do |
|
Yes, @kshyatt ! The two conditions for this to work now are basically I could add |
You might check out the tests in |
|
I shall do that soon! thanks for the pointers. |
|
Great! Please feel free to ask for help/explanations if you need them :) |
|
Conversions from matrix types for which there exist julia> convert(Matrix, Diagonal(ones(4)))
4×4 Array{Float64,2}:
1.0 0.0 0.0 0.0
0.0 1.0 0.0 0.0
0.0 0.0 1.0 0.0
0.0 0.0 0.0 1.0#17079 migrated |
|
Yes, so it looks like the special types are taken care of test-wise, no? I went through the PRs you posted and it seems that most of the types similar to I guess the question what subtypes of abstract array (aside subarrays) are not covered by @Sacha0 refactor then. |
Yes, but IMO if it's going to be too much of a pain to figure this out the PR as it stands is perfectly fine. |
|
Not sure how to proceed here. I did rebase on the latest master locally to see if there would be any apparent weird interactions with the related changes introduced by @Sacha0 and everything seems fine as far as I can tell. |
I'm with |
|
so that's a no then @KristofferC ? anything in particular that I messed up or could have done differently? a little context/feedback would help me improve |
|
That seems like it may have been a wrong-button mistake? |
|
Must have had the finger in the wrong place when scrolling on the phone. Sorry. I would never intentionally just close an ongoing PR without a good reason and a comment. |
|
Sorry we forgot this for so long. Since people supported this change for several weeks, I'll merge tomorrow if nobody objects. |
…7848) This commit will allow a user to call: convert(Vector, my_abstractvector_of_eltype_Foo) convert(Matrix, my_abstractmatrix_of_eltype_Foo) which is useful because - for the case that the variable is a subarray of the same dimensionality - for consistency with PR #17066 (cherry picked from commit bffeedb)
|
🎉 first PR! babysteps |
…liaLang#17848) This commit will allow a user to call: convert(Vector, my_abstractvector_of_eltype_Foo) convert(Matrix, my_abstractmatrix_of_eltype_Foo) which is useful because - for the case that the variable is a subarray of the same dimensionality - for consistency with PR JuliaLang#17066
Corresponding issue: #16519
This commit will allow a user to call:
which is useful because
The same effect can (and could before this commit) also be
achieved in the following manner. Note how the two last lines
are unnecessarily verbose, because the eltype can be inferred