Remove LinearAlgebra things from the base manual#25723
Remove LinearAlgebra things from the base manual#25723fredrikekre merged 1 commit intoJuliaLang:masterfrom
Conversation
fredrikekre
added
docs
fredrikekre
force-pushed
the
fe/no-more-linear-algebra
branch
from
5c20057 to
f62b373
Compare
|
|
||
| julia> transpose(X) | ||
| 2×2 Array{Array{Int64,2},2}: | ||
| 2×2 LinearAlgebra.Transpose{LinearAlgebra.Transpose{Int64,Array{Int64,2}},Array{Array{Int64,2},2}}: |
There was a problem hiding this comment.
Will this doctest pass without a using LinearAlgebra prior to this call?
There was a problem hiding this comment.
Yes, at least for now, since transpose is Base.transpose and LinearAlgebra is required in sysimg.jl. But I am not sure how informative this example actually is and would be happy to remove the showcasing of transpose from the permutedims examples. Would you, or anyone else, object to such a removal?
There was a problem hiding this comment.
I am more or less ambivalent :). Perhaps seek additional parties' opinions?
There was a problem hiding this comment.
Lets keep this for now then.
|
|
||
| julia> transpose(V) | ||
| 1×2 Transpose{Transpose{Int64,Array{Int64,2}},Array{Array{Int64,2},1}}: | ||
| 1×2 LinearAlgebra.Transpose{LinearAlgebra.Transpose{Int64,Array{Int64,2}},Array{Array{Int64,2},1}}: |
|
|
||
| In this case [`norm`](@ref) is a function that takes 2D array as a parameter, and MUST be defined in | ||
| the remote process. You could use any function other than `norm` as long as it is defined in the remote | ||
| In this case [`sum`](@ref) is a function that takes 2D array as a parameter, and MUST be defined in |
There was a problem hiding this comment.
Preexisting, but perhaps "that takes a {2D|two-dimensional} array as an argument"?
There was a problem hiding this comment.
It is unclear to me why that even matters, is it not enough to say "In this case the function sum MUST be defined in the remote process" ?
There was a problem hiding this comment.
Agreed; perhaps simplify these sentences accordingly then? :)
| the remote process. You could use any function other than `norm` as long as it is defined in the remote | ||
| In this case [`sum`](@ref) is a function that takes 2D array as a parameter, and MUST be defined in | ||
| the remote process. You could use any function other than `sum` as long as it is defined in the remote | ||
| process and accepts the appropriate parameter. |
There was a problem hiding this comment.
Also preexisting, but perhaps this "parameter" should be "argument"? :)
|
|
||
| """ | ||
| transpose(A::AbstractMatrix) | ||
| transpose(A::AbstractVecOrMat) |
There was a problem hiding this comment.
Hm, perhaps we should drop the type qualifications in these docstrings?
There was a problem hiding this comment.
Sure, although they are attached to a method with that type qualification.
There was a problem hiding this comment.
Regarding docstrings that apply to a function broadly and yet are attached to an appropriate, relatively general method, do we typically place the method's type qualifications in the docstring?
Sacha0
left a comment
Sacha0
left a comment
There was a problem hiding this comment.
Looks great modulo the minor questions/comments! Thanks @fredrikekre! :)
fredrikekre
force-pushed
the
fe/no-more-linear-algebra
branch
from
f62b373 to
d399a69
Compare
2 participants
No description provided.