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

Deprecate norm? #543

Open
olof3 opened this issue Jun 29, 2021 · 7 comments
Open

Deprecate norm? #543

olof3 opened this issue Jun 29, 2021 · 7 comments
Labels
v1 Issues to resolve before releasing v1

Comments

@olof3
Copy link
Contributor

olof3 commented Jun 29, 2021

Currently, norm(sys, inf) (alternativey, hinfnorm(sys)) corresponds to the Base.opnorm. It seems inconsistent that these can be used with norm(sys, inf). I suggest that we remove norm altogether and instead add h2norm.

@mfalt
Copy link
Member

mfalt commented Jun 29, 2021

I haven't thought about this too much so please correct me where I'm wrong, I have probably missed something with L/H

Are they not both valid norms and operator norms?
Why don't we want to use the existing interface opnorm?
I think that they should probably be invoked by opnorm(sys, p=2). But it can also be very useful to have a norm defined (for example when working with vectors of systems). I don't see why we can't let norm(sys,p) = opnorm(sys,p)?

@olof3
Copy link
Contributor Author

olof3 commented Jun 29, 2021

Are they not both valid norms and operator norms?
I think that they should probably be invoked by opnorm(sys, p=2)

The system 2-norms aren't induced norms (and not submultiplicative), it could be seen as similar to Base.norm, although I am not sure that the analogy is good enough to warrant the definition `Base.norm(sys) = h2norm(sys).

I guess is quite rare (but very occasionally useful) to use system L norms in a control context. I don't think that we currently have a way to compute the L2 norm of a system (?).

Why don't we want to use the existing interface opnorm?

It would definitely make sense to have opnorm(sys) = hinfnorm(sys). For clarity I think it would be better to avoid this and just use hinfnorm explicitly. I would say that we would like to keep hinfnorm around regardless.

@baggepinnen
Copy link
Member

Matlab understands norm(G), norm(G,2) and norm(G, inf) which is what we currently have..

@olof3
Copy link
Contributor Author

olof3 commented Jun 29, 2021

Matlab understands norm(G), norm(G,2) and norm(G, inf) which is what we currently have..

This is certainly something to take into consideration, but I don't think we should give it very much weight. The usage is inconsistent with Base.opnorm/Base.norm.

I opted to give the function it's own name, partly because I do not like to have a ladder with if-elseif statements in a huge function that dispatches using a string argument (like c2d or matlabs canon).

@mfalt
Copy link
Member

mfalt commented Jun 29, 2021

I think that we should follow the interface defined here:
https://docs.julialang.org/en/v1/stdlib/LinearAlgebra/#LinearAlgebra.norm
https://docs.julialang.org/en/v1/stdlib/LinearAlgebra/#LinearAlgebra.opnorm
wherever it makes sense.

Edit: It doesn't stop us from also giving useful names to some of the commonly used versions though.

@baggepinnen
Copy link
Member

LinearAlgebra is quite vague of what the interface really is, e.g., the following

The second argument p is not necessarily a part of the interface for norm, i.e. a custom type may only implement norm(A) without second argument.
Use opnorm to compute the operator norm of a matrix.

@olof3
Copy link
Contributor Author

olof3 commented Jun 29, 2021

I think that we should follow the interface defined here:
https://docs.julialang.org/en/v1/stdlib/LinearAlgebra/#LinearAlgebra.norm
https://docs.julialang.org/en/v1/stdlib/LinearAlgebra/#LinearAlgebra.opnorm
wherever it makes sense

"For any iterable container A (including arrays of any dimension) of numbers (or any element type for which norm is defined), compute the p-norm (defaulting to p=2) as if A were a vector of the corresponding length"

This could with some good will be interpreted as the 2-norm of a system, but definitely not as an hinf-norm. I think that h2norm should be preferred for clarity in almost all cases, but we could define norm(sys) = h2norm(sys) as some kind of measure of the magnitude of the system.

@baggepinnen baggepinnen added the v1 Issues to resolve before releasing v1 label Oct 21, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
v1 Issues to resolve before releasing v1
Projects
None yet
Development

No branches or pull requests

3 participants