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

Improve docstrings for norm, vecnorm, normalize and normalize! #21611

Merged
merged 2 commits into from
May 7, 2017
Merged

Conversation

nalimilan
Copy link
Member

Add equations defining the norms, reorganize the docstrings by argument type,
and mention what "normalizing" means.

Somebody should really review the equations, as I'm not familiar with matrix norms.

@@ -73,6 +73,10 @@ Base.LinAlg.diagm
Base.LinAlg.scale!
Base.LinAlg.rank
Base.LinAlg.norm
Base.LinAlg.norm(::AbstractVector, ::Real)
Copy link
Member Author

Choose a reason for hiding this comment

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

Without these, the docstrings for specific methods do not appear at all in the manual, but with these the methods appear each in a separate box, contrary to what happens e.g. for vecnorm. I'm probably missing something. @MichaelHatherly

Copy link
Contributor

Choose a reason for hiding this comment

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

I hope Michael comes back, we miss you!

In the meantime if he's still traveling, maybe @mortenpi can give input on Documenter issues

Copy link
Contributor

Choose a reason for hiding this comment

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

As far as I can tell, it's the function norm end line to blame here -- then with Base.LinAlg.norm, Documenter only grabs the docstring attached to that particular declaration. Same behaviour in a simple example. I'm guessing because it's in this case an exact match.. but I am not at all familiar with the docsystem code (neither in Base nor in Documenter).

Not sure whether this should be considered to be a bug or not though. Without this there's no way to exactly match the function foo end docstring I believe, but on the other hand it conflicts with the "grab all docstrings" semantics.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, it would make sense to include all methods, and not only the function. I can't imagine a situation where you would like to include the docstring for the function, but not for the methods.

```
with ``a_{ij}`` the entries of ``A``, and ``m`` and ``n`` its dimensions.

When `p=2`, the matrix norm is the spectral norm, equal to largest singular value of `A`.
Copy link
Contributor

Choose a reason for hiding this comment

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

equal to the largest

norm(A, [p::Real=2])
norm(A::AbstractArray, p::Real=2)

Compute the `p`-norm of a vector or the operator norm of a matrix `A`,
Copy link
Member

Choose a reason for hiding this comment

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

Perhaps more precisely "the corresponding induced operator norm"?

Copy link
Member

@Sacha0 Sacha0 Apr 28, 2017

Choose a reason for hiding this comment

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

On second thought "induced operator norm" is redundant, so kindly ignore this comment. Either "corresponding induced norm" or "corresponding operator norm" seems best per your point below :).


Compute the `p`-norm of a vector or the operator norm of a matrix `A`, defaulting to the `p=2`-norm.
For vectors, this is equivalent to [`vecnorm`](@ref) and equal to:
Copy link
Member

Choose a reason for hiding this comment

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

Extra space between "and" and "equal"?

Copy link
Member

Choose a reason for hiding this comment

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

Missed this one? :)

norm(x::AbstractVector, p::Real=2) = vecnorm(x, p)

"""
norm(A::AbstractMatrix, p::Real=2)

For matrices, the matrix norm induced by the vector `p`-norm is used, where valid values of
Copy link
Member

Choose a reason for hiding this comment

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

Here the (more confined) term "matrix norm" appears rather than the (more general) "operator norm", whereas the opposite above. Perhaps use "matrix norm" or "operator norm" consistently? I suppose "matrix norm" is more precise where these methods are concerned.

Copy link
Member Author

Choose a reason for hiding this comment

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

As I said I'm not familiar with this, but reading the Wikipedia page I wouldn't think "matrix norm" is more precise than "operator norm", since there are several definitions for matrix norms.

Copy link
Member

Choose a reason for hiding this comment

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

You're absolutely correct! I had only induced matrix norms in mind. Either induced norm or operator norm seems more precise than matrix norm for these methods. Thanks for setting me right! :)


Normalize the vector `v` in-place with respect to the `p`-norm.
See also [`vecnorm`](@ref) and [`normalize`](@ref).
Normalize the vector `v` in-place so that its `p`-norm is equal to unity,
Copy link
Member

@Sacha0 Sacha0 Apr 28, 2017

Choose a reason for hiding this comment

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

Perhaps simplify "is equal to unity" to "equals unity"? (Edit: Also could nix "the vector" as redundant with the immediately preceding signature?)


Normalize the vector `v` with respect to the `p`-norm.
Normalize the vector `v` so that its `p`-norm is equal to unity,
Copy link
Member

Choose a reason for hiding this comment

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

Likewise here, perhaps simplify "is equal to unity" to "equals unity"? And could nix "the vector" given redundancy with the immediately preceding signature?

Copy link
Member Author

Choose a reason for hiding this comment

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

Actually I'd rather keep "the vector", it's not that long and it's a useful information if you jump directly to the description without looking precisely at the signature.

Copy link
Member

Choose a reason for hiding this comment

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

Though I would be happy either way, the documentation on documentation (specifically the third numbered convention) advises against repeating information shown in the method signature (and particularly type information) in the method description proper. Best!

@kshyatt kshyatt added docs This change adds or pertains to documentation linear algebra Linear algebra labels Apr 28, 2017
When `p=2`, the matrix norm is the spectral norm, equal to the largest
singular value of `A`.

When `p=Inf`, the matrix norm is the the maximum absolute row sum of `A`:
Copy link
Contributor

Choose a reason for hiding this comment

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

duplicate "the"


Takes the q-norm of a `RowVector`, which is equivalent to the p-norm with
For row vectors, return the ``q``-norm of `A` , which is equivalent to the p-norm with
Copy link
Contributor

Choose a reason for hiding this comment

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

unnecessary space between A and comma

@kshyatt
Copy link
Contributor

kshyatt commented May 2, 2017

@nalimilan do you have time to update this? I'd love to see it go in soon.

Add equations defining the norms, reorganize the docstrings by argument type,
and mention what "normalizing" means.

[av skip]
@nalimilan
Copy link
Member Author

I've just pushed an updated commit. Unfortunately, I'm not sure what to do about the Documenter issue.

@nalimilan
Copy link
Member Author

I've added a commit which puts the generic description of norm in the docstring for the first method (the one for AbstractVector) to work around the Documenter issue. This is an improvement over the current situation anyway, and should allow moving forward without waiting for a more general solution.

(There's currently a bug in the way Documenter renders inline equations though, see JuliaDocs/Documenter.jl#479.)

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.

lgtm for the workaround commit! :) (Absent objections, requests for time, or someone beating me to it, I plan to merge this tomorrow morning.)

@Sacha0 Sacha0 merged commit e257ef4 into master May 7, 2017
@tkelman tkelman deleted the nl/norms branch May 7, 2017 19:54
tkelman pushed a commit that referenced this pull request May 14, 2017
* Improve docstrings for norm, vecnorm, normalize and normalize!

Add equations defining the norms, reorganize the docstrings by argument type,
and mention what "normalizing" means.

* Remove docstring for the norm() function

(cherry picked from commit e257ef4)
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.

5 participants