Skip to content
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

Remove LinearAlgebra things from the base manual #25723

Merged
merged 1 commit into from
Jan 29, 2018

Conversation

fredrikekre
Copy link
Member

No description provided.

@fredrikekre fredrikekre added docs This change adds or pertains to documentation linear algebra Linear algebra labels Jan 24, 2018
@fredrikekre fredrikekre requested a review from Sacha0 January 24, 2018 08:03
@fredrikekre fredrikekre force-pushed the fe/no-more-linear-algebra branch from 5c20057 to f62b373 Compare January 24, 2018 09:24
@@ -140,7 +141,7 @@ julia> permutedims(X)
[5 6; 7 8] [13 14; 15 16]

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}}:
Copy link
Member

Choose a reason for hiding this comment

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

Will this doctest pass without a using LinearAlgebra prior to this call?

Copy link
Member Author

Choose a reason for hiding this comment

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

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?

Copy link
Member

Choose a reason for hiding this comment

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

I am more or less ambivalent :). Perhaps seek additional parties' opinions?

Copy link
Member Author

Choose a reason for hiding this comment

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

Lets keep this for now then.

@@ -173,7 +171,7 @@ julia> permutedims(V)
[1 2; 3 4] [5 6; 7 8]

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}}:
Copy link
Member

Choose a reason for hiding this comment

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

Same question here :).

```

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
Copy link
Member

Choose a reason for hiding this comment

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

Preexisting, but perhaps "that takes a {2D|two-dimensional} array as an argument"?

Copy link
Member Author

Choose a reason for hiding this comment

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

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" ?

Copy link
Member

Choose a reason for hiding this comment

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

Agreed; perhaps simplify these sentences accordingly then? :)

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
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.
Copy link
Member

Choose a reason for hiding this comment

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

Also preexisting, but perhaps this "parameter" should be "argument"? :)

"""
transpose(A::AbstractMatrix)
transpose(A::AbstractVecOrMat)
Copy link
Member

Choose a reason for hiding this comment

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

Hm, perhaps we should drop the type qualifications in these docstrings?

Copy link
Member Author

Choose a reason for hiding this comment

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

Sure, although they are attached to a method with that type qualification.

Copy link
Member

Choose a reason for hiding this comment

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

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?

Copy link
Member

@Sacha0 Sacha0 left a comment

Choose a reason for hiding this comment

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

Looks great modulo the minor questions/comments! Thanks @fredrikekre! :)

@fredrikekre fredrikekre force-pushed the fe/no-more-linear-algebra branch from f62b373 to d399a69 Compare January 25, 2018 14:34
@fredrikekre fredrikekre merged commit 6c59599 into JuliaLang:master Jan 29, 2018
@fredrikekre fredrikekre deleted the fe/no-more-linear-algebra branch January 29, 2018 07:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs This change adds or pertains to documentation linear algebra Linear algebra
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants