ControlSystems.jl icon indicating copy to clipboard operation
ControlSystems.jl copied to clipboard

Deprecate `norm`?

Open olof3 opened this issue 3 years ago • 7 comments

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.

olof3 avatar Jun 29 '21 12:06 olof3

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

mfalt avatar Jun 29 '21 12:06 mfalt

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.

olof3 avatar Jun 29 '21 12:06 olof3

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

baggepinnen avatar Jun 29 '21 12:06 baggepinnen

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).

olof3 avatar Jun 29 '21 12:06 olof3

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.

mfalt avatar Jun 29 '21 13:06 mfalt

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.

baggepinnen avatar Jun 29 '21 13:06 baggepinnen

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.

olof3 avatar Jun 29 '21 13:06 olof3