fix type stability in all norm variants #6101
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Continuing where JuliaLang/LinearAlgebra.jl#91 and #6057 left off, this makes all the
norm
functions type stable, both internally and externally.Previously, similar to JuliaLang/LinearAlgebra.jl#91,
norm(x, p)
was not type stable, in the sense that the norm of an integer matrix or scalar would return different types for differentp
. It was also not internally type stable, in that the reduction loop would change the type of the accumulator variable iftypeof(zero(T)) != typeof(zero(T)+zero(T))
, similar to #6069.Now, all matrix norms return a floating-point result, and accumulations are performed in at least double precision, similar to
vecnorm
.norm(x::Number, p)
returns a value with the same type asreal(x)
orabs(x)
, since adding the floating-point conversion there would have complicated the code for no useful purpose.I also made one or two other code cleanups. The
p
parameter is consistently declared to beReal
, and the dense vector norms overridevecnorm1
andvecnorm2
rather thanvecnorm
to exploit dispatch.